Параллельный файл. Читать быстрее, чем последовательное чтение?
Я просто задаюсь вопросом, параллельно File.Read использование PLINQ/Parallel может быть быстрее? Мой код следующим образом (.Net 4.0):
public static void ReadFileParallel(List<string> fileName)
{
Parallel.Foreach(fileName, file=>File.Read(file));
}
public static void ReadFilePLINQ(List<string> fileName)
{
fileName.AsParallel().foreach(file=>File.Read(file));
}
Причина я спрашиваю это, состоит в том, потому что я думал, что чтение файла является связанным IO, так выполнение параллели не поможет, действительно ли я прав?
7 ответов
Это зависит от ситуации.
Если ваши файлы находятся в разных местах, на разных сетевых ресурсах или на разных физических жестких дисках, то да, параллельная загрузка, вероятно, поможет. Если они находятся на одном вращающемся жестком диске, параллельное чтение файлов, вероятно, значительно снизит производительность из-за дополнительного времени поиска, которое, вероятно, будет затрачено на параллельное чтение.
Если файлы находятся на SSD, производительность, вероятно, будет немного ниже, но это зависит от того, сколько файлов вы читаете параллельно и каков их размер. Я полагаю, что при определенном пороговом размере файла и количестве параллельных чтений производительность значительно упадет. Трудно сказать без экспериментов.
Существует отличный PDF-файл от MSFT, в котором подробно описаны возможности параллельного и многопоточного управления.
Это может помочь.
В первом приближении это поможет, если файлы находятся на разных дисках, и замедлит работу в противном случае (из-за увеличения времени поиска).
Это может быть немного быстрее, если все файлы кэшируются (так как вы можете использовать несколько ядер).
Лучше всего, конечно, провести несколько сравнительных тестов.
Это непростое дело. Если вы сделаете это неправильно, головка диска будет двигаться вперед-назад, пытаясь прочитать два файла одновременно. Это особенно актуально для больших файлов.
Однако, если вы читаете много маленьких файлов параллельно, вы можете немного выиграть, потому что дисковая подсистема может выбрать чтение файлов в другом порядке, чем вы просили. Однако я не видел этого эффекта в реальной жизни.
Также обработка содержимого может выполняться параллельно с чтением файлов. Поэтому перед отправкой вам нужно провести профилирование и бенчмаркинг.
Я думаю, что вы попали в самую точку.
Параллельные операции в целом всегда сдерживаются точкой, в которой у вас заканчиваются ресурсы для параллельного выполнения операций, но даже тогда вы все равно получаете убывающую отдачу при увеличении количества параллельных потоков.
Джефф Этвуд опубликовал в Твиттере интересный график, который я добавлю к этому позже, показывающий убывающую отдачу от многоядерных процессоров с многопоточной средой. Конечно, это не совсем то же самое. Но давайте посмотрим на это с той точки зрения, что даже если у вас есть 100 файлов на 100 жестких дисках, где-то этот ввод-вывод попадает обратно в один канал, что приведет к некоторому снижению прироста чтения.
По сути, я пытаюсь сказать, что просто параллельное выполнение чего-то не означает, что это будет значительно ускорено, важно учитывать, как на самом деле выполняются параллельные процессы.
Вы не совсем выполняете параллельное File.Read, вы выполняете несколько File.Read параллельно. Если файлы находятся на разных шпинделях, вы ощутите повышение производительности, просто используя несколько шпинделей одновременно.
Вы также можете ощутить повышенную производительность, даже если вы используете один шпиндель, если за каждым чтением следует обработка, привязанная к процессору, хотя в этом случае было бы намного лучше запланировать объекты задач.В этом случае у вас могут быть одни задачи, загружающие данные из файлов, в то время как другие используют уже загруженные данные для выполнения некоторой тяжелой обработки.
Можно так подумать, но измерения показывают другое. Когда файловый ввод-вывод имеет значительную задержку, особенно по сети, выполнение его параллельно может сохранить заполненность трубы.