Параллельные расширения

Question

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

Я строю эту программу как однопоточную. Работает за 2 минуты.

Я собрал другую версию этой программы с расширениями Parallel и использую Task, который также работает почти через 2 минуты.

Другими словами, я не видел увеличения производительности при использовании Parallels из-за интенсивного ввода-вывода.

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

Блейд-серверы обрабатывают ввод-вывод быстрее / по нескольким каналам, чем моя рабочая станция?

Нет смысла использовать Parallels с приложениями, связанными с вводом-выводом?

Answer 1

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

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

Следующий код сжимает загрузку файлов последовательно, а затем параллельно.Я получаю следующее время на i7 920 и на твердотельном накопителе Intel X25, сжимающем 329 изображений JPG общим объемом данных 800 Мб.* Код сжатия см. Как: Сжатие файлов

Answer 2

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

Вы можете увидеть небольшое улучшение производительности с параллельным кодом, если ваш дисковый контроллер реализует «Лифт»ищет "," scatter-collect "или другие неупорядоченные операции, но разница в производительности будет относительно небольшой.

Где вы найдете более выгодную разницу в производительности для файлового ввода-вывода, когда выПеремещаете файлы между множеством разных физических устройств.Вы должны быть в состоянии переместить или скопировать файл на диске A в другое место на диске A, а также скопировать файл с диска B на диск C. На многих физических устройствах не хватает всех параллельных запросов, ожидающиходно устройство для выполнения всех запросов.

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

Answer 3

У меня есть приложение, реализованное в WinForms, которое обрабатывает ~ 7800 URL-адресов примерно за 5 минут (загружает URL-адрес, анализирует контент, ищет определенные фрагменты данных и, если находит то, что ищет, выполняет некоторую дополнительную обработку этого данные.

Это конкретное приложение раньше работало от 26 до 30 минут, но, изменив код на TPL (Task Parallel Library в .NET v4.0), оно выполняется всего за 5. Компьютер представляет собой рабочую станцию ​​Dell T7500 с двухъядерные процессоры Xeon (3 ГГц), работающие с 24 ГБ ОЗУ, и 64-разрядная версия Windows 7 Ultimate.

Хотя, это не совсем то же самое, что и ваша ситуация, это тоже очень интенсивно. Документация по TPL гласит, что она изначально была задумана для проблемных наборов, связанных с процессором, но это не исключает ее использования в ситуациях ввода-вывода (как показывает мое приложение). Если у вас есть как минимум 4 ядра, и вы не видите значительного сокращения времени обработки, возможно, у вас есть другие проблемы с реализацией, которые не позволяют TPL быть действительно эффективным (блокировки, элементы жесткого диска и т. Д.). Книга «Параллельное программирование в Microsoft .NET» действительно помогла мне понять, «как» нужно изменить ваш код, чтобы действительно использовать все эти возможности.

Стоит взглянуть на мой взгляд.

Answer 4

Все зависит от того, привязаны ли вы к процессору или IO. Я бы посоветовал провести тестирование производительности, чтобы увидеть, где вы находитесь.

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

Надеюсь, это поможет.

Answer 5

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