Зависит от задачи. Если, например, нужно сделать дамп базы postgres, то можно pg_dump запустить с опциями -j [thread count] -F d (directory format), при восстановлении аналогично.

335… bash параллельное выполнение

См. также https://github.com/danielgtaylor/jpeg-archive/blob/master/jpeg-archive

Ну да. Только wait это часть. Такой сценарий может быть под строго определенное количество ядер.

Никак, если требуется производительность, то баш идёт мимо, и никакая многоядерность ему не поможет.

Никак

Как вы пишете сценарий на bash для многоядерных процессоров? (комментарий)

Ты ничего не понял.

GNU/parallel

Никак, если требуется производительность, то баш идёт мимо, и никакая многоядерность ему не поможет.

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

Решаю задачу, делая максимально возможно осмысленное количество операций за каждый пайп, например вместе

tar -cfdir.tar dir
gzip fdir.tar
md5sum fdir.tar.gz > fdir.tar.gz.md5

делаю

tar -c dir | gzip | tee dir.tar.gz | md5sum > fdir.tar.gz.md5

Если какой-то компонент конвеера имеет многопоточный вариант - использую его (gzip–>pigz, bzip2->pbzip), если нет - запускаю параллельно сам. Впрочем, часто задачи упираются в ввод/вывод и параллелить нет смысла.

Почему вы сначала делаете tar, а пото gz? Почему вариант с tar -czvf не лучше?

Насколько я знаю способов управления потоками в bash нет, но можно сделать

nohup команда &

Во-первых, мне лень помнить все ключи тар, связанные со сжатием. Во-вторых, чтобы тар использовал pigz нужно отдельный ключ ему передать. В третьих, архив дальше по конвееру идёт, а не в файл. Шифруется, передаётся на сервера. В чётвертых, мне так больше нравится. Всё равно tar внутри через пайп всё так же делает.

GNU/parallel но это надо только если есть необходимость запуска нескольких однопоточных тяжелых внешних утилит.

Если у тебя стоит вопрос распараллеливания, то bash - не подходящий инструмент. Не то, чтобы там невозможно это было сделать, но просто он для этого не затачивался.

А что до решения конкретной задачи - bash имеет смысл рассматривать как запускалку внешних утилит. А те уже в свою очередь написаны на C или других ЯП. И вот те утилиты уже и должны озаботиться оптимизацией своей работы на многоядерных процессорах. Если у тебя узким местом оказывается именно логика написанная на bash - меняй bash на что-то другое, например python.

Пример с тар бессмысленный, конечно. Надеюсь, впопыхах приведенный. Где тар и где производительность! Это чудо антагонист производительности, тк не содержит индекса.

Продолжение с чексуммой годное. А pbzip2 вообще чуть ли не единственный имеет параллельный декомпрессор.

упоминание gzip стоит выкинуть тоже, что бы не плодить антипаттерны и антисоветы.

не содержит индекса.

Нахрена здесь индекс?

«Не смешивайте мягкое с тёплым, получается говно.»

неправильный вопрос. Нахрена здесь магнитная лента?

Нахрена здесь магнитная лента?

Опять неправильный вопрос. Правильный: Нахрена здесь бред сумасшедшего.

Нет такого «вопроса распараллеливания». Решают какую-то задачу, и начинает нехватать производительности, а всё остальное это уже их потуги это как-то решить.

сценарии, как я посмотрю, как были на одно ядро, то по сей день на одном ядре

Не всякая задача может быть распараллелена.
Не каждый набор действий может быть распараллелен.
А параллелить отдельные действия баш не мешает ничуть.

Не всякая задача может быть распараллелена. Не каждый набор действий может быть распараллелен.

И всё же не помешает добавить «нуждается в параллельности». По многим причинам. Вот скажем, пусть у нас будет «make» блокировать текущую цель и следующий параллельный вызов будет делать следующую цель. Есть ли смысл менять make -jN на параллельный вызов нескольких таких чуть измененных make 1 & make 2 & ? Для сложных проектов, скажем сборки ядра, когда make думает перед запуском задачи может оказаться, что внешний параллельный вызов будет только дольше, чем просто одиночный make, который один раз распарсит свой makefile, а потом будет будет запускать задачи по одной. Есть ещё и время на написание скрипта и его отладку. На декстопе и вообще неплохо отдавать процессор на отзывчивость хоть тем же X-ам и прочим фоновым процессам.

А параллелить отдельные действия баш не мешает ничуть.

Он толстый и тормозной, для true параллельности не доделан.. Потому мешает. Без него, когда действительно очень надо — получается правильно и хорошо. Но когда не очень-очень надо, то можно, но именно через parallel, так как bash до сих пор не понимает wait any - то есть ожидать завершения какого-то одного любого процесса.

Относительно компрессоров и параллельности - стоит проверить lrzip от анестезиолога.

make сам прекрасно разбирается где что параллелить
Я в этом много раз убеждался.

На декстопе и вообще неплохо отдавать процессор на отзывчивость хоть тем же X-ам и прочим фоновым процессам.

Это никак к скриптам и параллельности не относится.
Ты можешь заренайсить процесс, привязать его к определённому процессу, выписать ему лимиты и т.д. Но он так и будет одним процессом.

Он толстый и тормозной, для true параллельности не доделан..

Что ты там параллелить-то собрался? Ты можешь объяснить? Давай на примере. Пайпы итак по процессам раскидывает. Parallel умеет делать то, что действительно можно сделать параллельно. Но, если тебе надо гнуплотом например сгенерировать картинку, а потом её воткнуть в письмо и его отправить, то что ты здесь параллелить собрался?

так как bash до сих пор не понимает wait any - то есть ожидать завершения какого-то одного любого процесса.

Какую именно задачу ты решаешь? Конкретнее.

make сам прекрасно разбирается где что параллелить

Слабо вчитываться перед комментированием? Я в курсе, и потому взят пример, понятный по проделываемой работе, но с допущением «пусть будет» и далее по тексту.

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

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

Что ты там параллелить-то собрался?

Да ну вас к чёрту. Вникать в написанное влом, но похамить зудит?

Слабо вчитываться перед комментированием?

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

О чём и была речь.

А ещё о чём-то была?

Да ну вас к чёрту.

Давай взаимно зафрендим друг друга.

Вникать в написанное влом, но похамить зудит?

Тремя строками выше я уже всё написал.
И всё-таки я пожалуй подожду нешизофренического примера, где нужно во что бы то ни стало параллелить скриптоту в баше.

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

Просто поразительно. Ну, то что тут больше двух предложений скипают и не вникают, это не новость. Но то, что даже первое короткое «И всё же не помешает добавить «нуждается в параллельности».» не распарсили совсем удручает. Как можно это понять как «во что бы то ни стало параллелить скриптоту в баше.»? Если речь о том, что как раз большой вопрос - а нужно ли?

Тебе уже всё написали про то как задействовать много ядер процессора. Теперь перестань вилять жопой.

Тебе уже всё написали про то как задействовать много ядер процессора. Теперь перестань вилять жопой.

Дядя, проснись и пой. Четвёртый раз говорю — мне не надо и я рассказываю, почему когда возникает надо, то это что-то скорее делается не так.

Если тебе не надо, то зачем ты мне отвечал?
Как вы пишете сценарий на bash для многоядерных процессоров? (комментарий)
Ну и расскажи заодно

Он толстый и тормозной, для true параллельности не доделан.. Потому мешает. Без него, когда действительно очень надо — получается правильно и хорошо. Но когда не очень-очень надо, то можно, но именно через parallel, так как bash до сих пор не понимает wait any - то есть ожидать завершения какого-то одного любого процесса.

что ты понимаешь под true и с какими целями что именно надо доделывать. И что именно мешает тоже так между делом объясни, без выпендрёжа.

Если тебе не надо, то зачем ты мне отвечал?

Я добавил к вашим 3 пунктам еще один: не всякая задача должна решаться распараллеливанием, и тем более на bash.

что ты понимаешь под true и с какими целями что именно надо доделывать.

Вот мой скрипт, который решает задачу распараллеливание на чистом bash без утилиты parallel. Как видите, я это умею и знаю о чём говорю. У этого скрипта есть плюс: он не вызывает на каждую команду в пареллель по копии bash, как это делает parallel со всеми вытекающими удобствами: локальные переменные и функции работают и не тормозит. Но есть недостаток тоже, у wait нет опции ждать завершение любой параллельной задачи, приходится держать в фоне сам цикл со sleep. parallel этого недостатка не имеет, но зато не имеет локального одного окружения.

ок бумер

Вот за такое сообщение и нужны минусы\плюсы на лоре. «-» тебе, ты не понял на что отвечаешь, да еще и усрался споря ниочем с vodz. Нахрен вообще отвечать на сообщение, смысла которого ты не осилил?

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

Так архиватор будет кормить компрессор одним большим и длинным файлом и работа компрессора будет эффективнее.

Ну чё, как обычно

Спросил об одном, ответили о другом, но зато нафлудили...

Где вы узрели здесь perl? Я про bash вообще-то.

which wait
which: no wait in...
type -a wait
wait — это встроенная команда bash
head -1 `which parallel`
#!/usr/bin/env perl

Только wait это часть. Такой сценарий может быть под строго определенное количество ядер.

Из чего делаю вывод, дальше однострочников дело идет на костылях.

Вопрос остается открытым.

Допустим, вам нужно опросить 100500 компьютеров в сети по сценарию. При определенных условиях выполнить действие.

Вопрос: как долго будете ждать в последовательном исполнении, если один из компьютеров завис?

так ведь «tar -czvf» работает точно так же - запускается процесс компрессора, которому скармливаются tared-данные. Это лишь вкусовщина и кому как проще запомнить. Вариант с пайпом гибче, т.к. мерзкий тар можно заменить на что-то получше.

Пишите

Пишете. «Пишите» – повелительное наклонение. Сравни: «Пишете? Ну, пишите-пишите!»

Да я уже импортный язык лучше знаю, чем русский. Извиняй. Сейчас исправлю.

Как вы пишите сценарий на bash для многоядерных процессоров?

Не на баше.

/thread

А ты вообще кто?

Допустим, вам нужно опросить 100500 компьютеров в сети по сценарию.

Сценарий один и тот же? Это хорошо параллелится. Ты наверное в курсе про & и parallels?

При определенных условиях выполнить действие.

Не вижу проблем.

Вопрос: как долго будете ждать в последовательном исполнении, если один из компьютеров завис?

Ровно столько, сколько отрабатывает таймаут соединения.

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

Ну ты дай пример задачи-то.

Не на баше.

А на чём ты пишешь шелл-скрипты?

Давно не пишу шелл-скрипты. На шелле только однострочники, вся скриптота на перле/раку.

На шелле только однострочники

Полностью поддерживаю. А чтобы ощутить всю «мощь» однострочников, пользую https://github.com/dvorka/hstr .

parallels это perl. Сколько раз повторять?

Поддержка многоядерности в баш из коробки, пользоваться нужно так:

command1 | command2 | command3

Несложно видеть что все команды работают параллельно и каждая на своём ядре (добавьте колонку PROCESSOR в htop).

/thrend

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

Допустим, вам нужно опросить 100500 компьютеров в сети по сценарию. При определенных условиях выполнить действие. Вопрос: как долго будете ждать в последовательном исполнении, если один из компьютеров завис?

Это совсем другая задача, для которой многопроцессорность параллельна, хех, вот такой каламбур.