Многопоточная производительность сравнения файлов

Question

Я только что наткнулся на этот ТАК вопрос и задавался вопросом, будет ли какое-либо улучшение производительности, если:

1. Файл сравнивался в блоках, не превышающих размер сектора жесткого диска (1 / 2КБ, 2КБ или 4КБ)
2. И сравнение было сделано многопоточным (или, может быть, даже с параллельным .NET 4)

Я представляю, что существует 2 потока: один, который читает с начала файла, и другой, который читает с конца, пока они не встретятся в середине.

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

Конечно, другие факторы также могут играть роль, например, один против нескольких процессоров / ядер или SSD против не-SSD, но с теми, кто в стороне; Непреодолима ли скорость ввода-вывода диска + возможность совместного использования времени процессора? Или, возможно, моя концепция компьютерной теории совершенно не соответствует действительности ...

Answer 1

Если вы сравниваете два файла на одном диске, единственное преимущество, которое вы можете получить от многопоточности, - это чтение одного потока, заполнение следующих буферов, в то время как другой поток сравнивает ранее прочитанноебуферов.

Если сравниваемые файлы находятся на разных физических дисках, вы можете одновременно выполнять два асинхронных чтения - по одному на каждый диск.

Но ваша идея иметь один потокчтение с начала и другое чтение с конца сделают вещи медленнее, потому что время поиска убьет вас.Головки дисковода будут постоянно искать от одного конца файла до другого.Подумайте об этом следующим образом: считаете ли вы, что будет быстрее читать файл последовательно с самого начала, или будет быстрее читать 64 КБ спереди, затем читать 64 КБ с конца, а затем вернуться к началу файлачитать следующие 64K и т. д.

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

Помните, что типичный дисковод может удовлетворить только один запрос ввода-вывода за раз.

Создание одного-секторное чтение, вероятно, замедлит ход событий.В моих тестах скорости ввода / вывода .NET чтение 32K за раз было значительно быстрее (от 10 до 20 процентов), чем чтение 4K за раз.Как я помню (с тех пор, как я это сделал), на моей машине в то время оптимальный размер буфера для последовательного чтения составлял 256 КБ.Это, несомненно, будет отличаться для каждой машины в зависимости от скорости процессора, контроллера диска, жесткого диска и версии операционной системы.