Подскажите пожалуйста, куда копать) Есть задача. Надо читать файл блоками заданного

размера, делать что-то с ними (например crc посчитать) и записывать в том же порядке результат в другой файл. Надо сделать так, чтобы по максимуму использовать многопроцессорную обработку. Файл может быть больше чем оперативка.

Пока идея такова. Читать последовательно блок T*B где T = (число потоков -1), B - размер блока. Класть в очередь. Потоками брать из очереди и обрабатывать, Результат складывать в буфер, когда дочитаем до конца файла, основной поток переключиться на запись в файл и запишет туда буфер.

Отталкиваюсь от гипотезы, что чтение-запись долгие процессы. Или может есть способы читать один файл в несколько потоков и также писать? Например, как всякие download манеджеры, они как бы по частям файл качают и пишут тоже, или фикция и под капотом иначе?

Думаю моя проблема в слабом понимании работы с файлами под капотом. ОС не оговорена, так что ОС зависимые штуки не использую.

Порекомендуйте куда копнуть)

из опыта работы с файлами в win7 - читай последовательно обычным read в буфера в одном потоке и складывай в очередь, обрабатывай в N=num_hardware_threads потоках, пиши прямо в файл, запись - это просто memcpy MMF при последовательном чтении работает чуть медленней если данных ещё нет в ОЗУ (вероятно, из-за pagefaults на каждой 4КБ странице), при непоследовательном если у тебя HDD - может быть вообще сумрак запись можно сделать в mmf, но в моём опыте винда не скидывала кеш пока не закроешь mapping. хотя это кажись ещё в xp было

ну и собственное главное. даже сделав идеальный код с MMF (а у нас пока есть только вариант для win10), ты выиграешь ровно одно memcpy. стоит ли эта экономия всех усилий - зависит от ваших задач

у меня к слову есть одна утилита, которая до нескольких гиг в сек обрабатывает в многопотоке. вот у неё есть два режима работы - через MMF и read. первый режим используется для бенчей когда файл уже загнан в кеш. а второй работает быстрее если файла в кеше ещё нет :)) это на win7 тесты

В разработке драйверов-фильтров, сканирующих содержимое файла, если негласное правило использовать преимущественно MMF, считая, что файл будет использоваться приложением не в noncached-режиме. Это может сильно повлиять на результаты бенчмарков "в полях" :)

а можно немного не по теме вопрос? при использовании noncached из юзерспейса, DMA трансферы идут прямо в пользовательский буфер?

если запинить - почему бы и нет?

Не совсем понял, к чему именно придирка. В статье много специфичных для фильтров вещей вроде обхода IO-стека с верхушки и т.д., но касательно конкретного вопроса - идея в том, что FsRtlCreateSectionForDataScan() создаёт секцию с довольно агресивными флагами кеширования, и поскольку пользовательские операции обычно cached/MMF, пресловутые pf либо "переедут" в kernel space (сканирование в create), либо вообще маловероятны (сканирование в close + кто-то потом откроет файл, а он уже почти весь в кэше)

возможно для kernel space эти page faults дёшевы и в этом вся разница

в ядрах обычно page faults запрещены