Параллельный файл. Читать быстрее, чем последовательное чтение? - PullRequest
6 голосов
/ 13 июля 2010

Мне просто интересно, параллельно 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));
}

Причина, по которой я спрашиваю об этом, заключается в том, что я думал, что чтение файлов связано с вводом-выводом, поэтому параллельное выполнение не поможет, я прав?

Ответы [ 7 ]

6 голосов
/ 13 июля 2010

Это зависит.

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

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

1 голос
/ 13 июля 2010

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

0 голосов
/ 13 июля 2010

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

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

Также обработка, которую вы выполняете над контентом, может выполняться параллельно с чтением файлов.Так что вам нужно профилировать и тестировать перед отправкой.

0 голосов
/ 13 июля 2010

Я думаю, что вы в значительной степени ударили гвоздь по голове здесь.

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

Джефф Этвуд написал в Твиттере интересный график, который я добавлю к этому позже, показывая уменьшающуюся отдачу от многоядерных процессоров с многопоточным окружением. Конечно, это не совсем то же самое. Но давайте посмотрим на это с мыслью, что даже если у вас есть 100 файлов на 100 жестких дисках, то где-то, что ввод-вывод возвращается вниз по одному каналу, что приведет к некоторому уменьшению увеличения чтения.

То, что я в основном пытаюсь сказать, - это просто запустить что-то параллельно, это не значит, что оно будет значительно ускорено, важно рассмотреть, как на самом деле выполняются параллельные процессы.

0 голосов
/ 13 июля 2010

Вы не совсем делаете параллельный File.Read, вы делаете несколько параллельных File.Reads. Если файлы находятся в разных шпинделях, вы получите улучшенную пропускную способность, просто используя несколько шпинделей одновременно.

Вы также можете почувствовать улучшение производительности, даже если вы используете один шпиндель, если за каждым чтением следует обработка с привязкой к ЦП, хотя в этом случае было бы намного лучше планировать объекты задач. В этом случае у вас могут быть некоторые задачи по загрузке данных из файлов, в то время как другие используют уже загруженные данные для выполнения тяжелой обработки.

0 голосов
/ 13 июля 2010

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

Может быть немного быстрее, если все файлы будут кэшированы (так как вы можете использовать несколько ядер).

Лучше всего, конечно, провести несколько тестов.

0 голосов
/ 13 июля 2010

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

Это может помочь.

http://www.microsoft.com/downloads/details.aspx?FamilyID=86b3d32b-ad26-4bb8-a3ae-c1637026c3ee&displaylang=en

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...