☰

Параллельная обработка медленнее последовательной?

tag-icon • tag-icon linux terminal performance imagemagick parallel-processing
Параллельная обработка медленнее последовательной?

EDIT: Для тех, кто наткнется на это в будущем: Imagemagick использует библиотеку MP. Использовать доступные ядра быстрее, если они есть, но если у вас есть параллельные задания, это бесполезно.

Выполните одно из следующих действий:

  • выполняйте свою работу последовательно (с Imagemagick в параллельном режиме)
  • установите MAGICK_THREAD_LIMIT=1 для вызова соответствующего двоичного файла imagemagick.

Заставив Imagemagick использовать только один поток, я снизил скорость работы в своих тестовых случаях на 20–30%, но при этом смог без проблем запустить по одному заданию на ядро, что значительно повысило общую производительность.

Исходный вопрос:

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

Итак, у нас есть эта демонстрация.

  • Четырехъядерный (AMD Athalon X4, 2,6 ГГц)
  • Работает полностью на tempfs (всего 16 г ОЗУ; без подкачки)
  • Никаких других крупных нагрузок.

Полученные результаты:

/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 1 convert -auto-level

real        0m3.784s
user        0m2.240s
sys         0m0.230s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 2 convert -auto-level

real        0m9.097s
user        0m28.020s
sys         0m0.910s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 10 convert -auto-level

real        0m9.844s
user        0m33.200s
sys         0m1.270s

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

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

EDIT: При работе с файлами 1000x 769 КБ производительность соответствует ожидаемой. Интересно.

/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 1 convert -auto-level

real    3m37.679s
user    5m6.980s
sys 0m6.340s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 1 convert -auto-level

real    3m37.152s
user    5m6.140s
sys 0m6.530s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 2 convert -auto-level

real    2m7.578s
user    5m35.410s
sys     0m6.050s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 4 convert -auto-level

real    1m36.959s
user    5m48.900s
sys     0m6.350s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 10 convert -auto-level

real    1m36.392s
user    5m54.840s
sys     0m5.650s

решение1

Насколько велики файлы, которые вы хотите преобразовать, по сравнению с вашим кэшем L1? Вашим кэшем L2?

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

Смотрите такжеэтот ответ я дал на Stack Overflow.

Связанный контент