Исправление vodz, (текущая версия) :
Не всякая задача может быть распараллелена. Не каждый набор действий может быть распараллелен.
И всё же не помешает добавить «нуждается в параллельности». По многим причинам. Вот скажем, пусть у нас будет «make» блокировать текущую цель и следующий параллельный вызов будет делать следующую цель. Есть ли смысл менять make -jN на параллельный вызов нескольких таких чуть измененных make 1 & make 2 & ? Для сложных проектов, скажем сборки ядра, когда make думает перед запуском задачи может оказаться, что внешний параллельный вызов будет только дольше, чем просто одиночный make, который один раз распарсит свой makefile, а потом будет будет запускать задачи по одной. Есть ещё и время на написание скрипта и его отладку. На декстопе и вообще неплохо отдавать процессор на отзывчивость хоть тем же X-ам и прочим фоновым процессам.
А параллелить отдельные действия баш не мешает ничуть.
Он толстый и тормозной, для true параллельности не доделан.. Потому мешает. Без него, когда действительно очень надо — получается правильно и хорошо. Но когда не очень-очень надо, то можно, но именно через parallel, так как bash до сих пор не понимает wait any - то есть ожидать завершения какого-то одного любого процесса.
Исправление vodz, :
Не всякая задача может быть распараллелена. Не каждый набор действий может быть распараллелен.
И всё же не помешает добавить «нуждается в параллельности». По многим причинам. Вот скажем, пусть у нас будет «make» блокировать текущую цель и следующий параллельный вызов будет делать следующую цель. Есть ли смысл менять make -jN на параллельный вызов нескольких таких чуть измененных make 1 & make 2 & ? Для сложных проектов, скажем сборки ядра, когда make думает перед запуском задачи может оказаться, что внешний параллельный вызов будет только дольше, чем просто одиночный make, который один раз распарсит свой makefile, а потом будет будет запускать задачи по одной. Есть ещё и время на написание скрипта и его отладку. На декстопе и вообще неплохо отдавать процессор на отзывчивость хоть тем же X-ам и прочим фоновым процессам.
А параллелить отдельные действия баш не мешает ничуть.
Он толстый и тормозной, для tru параллельности не доделан.. Потому мешает. Без него, когда действительно очень надо — получается правильно и хорошо. Но когда не очень-очень надо, то можно, но именно через parallel, так как bash до сих пор не понимает wait any - то есть ожидать завершения какого-то одного любого процесса.
Исходная версия vodz, :
Не всякая задача может быть распараллелена. Не каждый набор действий может быть распараллелен.
И всё же не помешает добавить «нуждается в параллельности». По многим причинам. Вот скажем, пусть у нас будет «make» блокировать текущую цель и следующий параллельный вызов будет делать следующую цель. Есть ли смысл менять make -jN на параллельный вызов нескольких таких чуть измененных make 1 & make 2 & ? Для сложных проектов, скажем сборки ядра, когда make думает перед запуском задачи может оказаться, что внешний параллельный вызов будет только дольше, чем просто одиночный make, который один раз распарсит свой makefile, а потом будет будет запускать задачи по одной. Есть ещё и время на написание скрипта и его отладку. На декстопе и вообще неплохо отдавать процессор на отзывчивость хоть тем же X-ам и прочим фоновым процессам.
А параллелить отдельные действия баш не мешает ничуть.
Он толстый и тормозной. Потому мешает. Без него, когда действительно очень надо — получается правильно и хорошо. Но когда не очень-очень надо, то можно, но именно через parallel, так как bash до сих пор не понимает wait any - то есть ожидать завершения какого-то одного любого процесса.