Параллель GNU может выполнить больше параллельных процессов?

Вы хотите

  • Рекурсивно вызовите в весь PDFs:

    1. Включите globstar, с shopt -s globstar.
    2. Используйте его для генерации списка весь *.pdf файлы под текущим каталогом: **/*.pdf
    3. Создайте цикл, который выполняет итерации по упомянутым файлам:

      for filename in **/*.pdf
      do
          something
      done
      
  • Теперь, Вы хотите сделать что-то на файлах: что-то convert -thumbnail x80 95.pdf[0] thumb_95.png. Существует несколько путей: Я обычно использую basename, в этом случае Вам было бы нужно $(dirname $filename)/$(basename $filename .pdf).png, но другой интересный (и более простой) подход должен использовать инструменты обработки строк удара:

    1. Удалить .pdf от конца имени файла: ${filename%.pdf}
    2. Добавить .png: ${filename%.pdf}.png

Наконец, мы можем склеить все это (не забывайте, что это требует globstar, shopt -s globstar):

for filename in **/*.pdf
do
    convert -thumbnail x80 $filename[0] ${filename%.pdf}.png
done

6
12.09.2017, 05:04
2 ответа
[1131246] Не понимаю, почему это невозможно - система, конечно, может жонглировать 200 параллельными задачами.[12153] Однако, это почти наверняка не желательно, если только нет какой-то конкретной причины, по которой нужно такое точное количество задач, выполняемых параллельно. Это кажется маловероятным; единственная причина, которую я вижу, это то, что они нужны вам все существующие одновременно, потому что они нужны для обмена информацией, или для обмена информацией с чем-то другим хаотичным и неопределенным (например, для тестирования серверной программы).[12154]Причина, по которой это не желательно, заключается в том, что идеальное состояние, с точки зрения эффективности, заключается в том, что система может запускать несколько процессов, равное количеству доступных процессорных ядер. Поскольку процессы в той или иной степени часто содержат узкие места за пределами процессора - например, дисковый ввод/вывод - это обобщенное идеальное число колеблется, на взгляд, от числа ядер + 1 до числа ядер * 2.[12155]Причина, по которой эффективность идеального состояния является мудрой, заключается в том, что если сама задача потребляет 1 миллион единиц процессорного времени, то выполнение одной и той же задачи 10 раз подряд будет потреблять 10 миллионов единиц, а выполнение одной и той же задачи параллельно будет потреблять 10 миллионов единиц. Однако в последнем случае, если в системе меньше 10 процессоров, то [1131723] возникает дополнительная стоимость [1131724], так как система должна постоянно переключаться с одной задачи на другую. [12156] Именно поэтому [1131725] в целом [1131726] система с 2 х 2 ГГц ядрами быстрее системы с 4 х 1 ГГц ядрами. Основная причина эволюции многоядерных систем заключается в том, что производство все более быстрых процессоров становится все более сложным, и за пределами определенной относительно низкой точки, это невозможно. Следовательно, решение заключается в производстве систем с большим количеством процессорных ядер.[12157]Короче говоря, если вам нужно сделать 20 вещей как можно быстрее и у вас есть 4 ядра, то самый быстрый способ сделать это - это сделать их в 5 наборах по 4, или в 4 наборах по 5, чтобы обеспечить время простоя в ожидании ввода/вывода. [1131727]parallel[1131728] позволяет подавать ему список неопределенной длины, но при этом ограничивать количество одновременно выполняемых заданий (и обратите внимание, что по умолчанию для этого числа используется количество ядер).[12158]Существует своего рода исключение из этого правила, хотя обычно оно относится к некоторым видам единичных многопоточных программ (т.е. не кучке отдельных программ, а к одной программе, занимающей несколько ядер). Это происходит потому, что когда программа может что-то делать, делая это с относительно независимыми ветвями, которые нужно координировать только время от времени ("время от времени" все равно может быть 10 или 20 раз в секунду), гораздо проще, а часто и гибче, спроектировать программу так, чтобы она делала это в независимых потоках, чем спроектировать ее так, чтобы она могла произвольно (асихронно) циклировать задачи. К этой категории относятся графически насыщенные и/или интерактивные программы, такие как видеоигры и CAD-системы. [1131259]
2
27.01.2020, 20:24

Это не только возможно, но и рекомендуется в некоторых ситуациях.

GNU Parallel занимает около 10 мс на выполнение задания. Таким образом, если у вас есть 8 ядер, а запущенные задания занимают менее 70 мс, то вы увидите, что GNU Parallel использует 100% одного ядра, и все же будет время простоя на других ядрах. Таким образом, вы не будете использовать 100% всех ядер.

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

Однако, использование 2 списков не является рекомендуемым способом разделения заданий. Рекомендуемый способ - использовать GNU Parallel для вызова GNU Parallel:

cat list0 | parallel -j20 --pipe parallel -j100

Это приведет к параллельному выполнению 2000 заданий. Чтобы запустить больше настроек -j. Рекомендуется, чтобы внешнее (20) количество ядер было как минимум таким, чтобы на каждом ядре был хотя бы один параллельный процесс GNU.

Используя эту технику, у вас не должно возникнуть проблем с запуском 20000 параллельных рабочих мест; когда вы получите более 32000 процессов, все начнет работать.

.
8
27.01.2020, 20:24

Теги

Похожие вопросы