Как заставить Perl

http://perldoc.perl.org/threads.html

Почему остальные три ядра шлангуют

Потому, что внутренняя архитектура Perl была придумана в далеком 1987 году еще без учета только-только появившейся тогда потребительской многопоточности в лице i80386.

и как их тоже заставить работать?

Забить либо на Perl, либо на многопоточность.

xargs -P

http://perldoc.perl.org/threads.html

Ну, это значит самому изголяться с кодом, а хотелось, чтобы система сама умела распределять нагрузку в многоядерных системах

Потому, что внутренняя архитектура Perl была придумана в далеком 1987 году еще без учета только-только появившейся тогда потребительской многопоточности в лице i80386.

Т.е. с тех и до сих пор ваятель Пёрла почесывает себя на лобке, почивая на лаврах? :))

xargs -P

Если правильно понял, это ручной запуск нескольких копий/потоков задач? Если да, то мне сойдет, и можно поподробнее, с простейшим примерчиком?

Ну, это значит самому изголяться с кодом

Ога и так везде.

сооружаешь очередь из твоих данных и запускаешь 4-5 процессов perl скрипта. Каждый процесс будет брать из твоей очереди строчку и работать с ней

а так читаем маны: http://search.cpan.org/~rjbs/perl-5.16.0/lib/Thread.pm

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

Если perl грузит ядро на 100%, то это уже неправильное его использование imho, можно начинать смотреть в сторону компилируемых языков с поддержкой многопоточности, хотя бы pthreads.

придется все равно переделывать?

А с каким языком вы сравниваете?

Ну, это значит самому изголяться с кодом

Ога и так везде.

В Erlang не так.

Т.е. с тех и до сих пор ваятель Пёрла почесывает себя на лобке, почивая на лаврах? :))

Подробностей не знаю, но именно такой она у него и получилась.

Лично мне перл совсем не нравится. Но хаять и одновременно просить помочь - моветон. Или вы мелочно рассчитываете на то, что все любители перла побегут вас переубеждать?

Ну вот helios процедил ссылку, а так мог подробнее написать.

А чего тут писать подробно то? Если программируешь что-то многопоточное, то готовься к pthread_create, pthread_join и прочим радостям (кои описаны по ссылке)...

Разве что для данного вопроса ещё можно дать http://perldoc.perl.org/threads/shared.html для удобства.

В erlang всё не так. И «не такие» потоки. ФП может дать много полезных бонусов. Но в случае перла и многих других языков многие вещи нужно прописывать явно.

PS ЕМНИП, в java, c#, c и прочих «быдлоязыках» также как и в perl.

Ситуацию уяснил, всем неравнодушным к проблеме спасибо :)

Забить либо на Perl, либо на многопоточность.

perl это не питон, в нем потоки правильные

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

Алгоритм на языке пишешь сам, однако BEAM (Bogdan/Björn’s Erlang Abstract Machine) будет пытаться самостоятельно распараллелить твои вычисления наилучшим образом с точки зрения самой BEAM.

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

Да, срача erlang vs perl на лоре пожалуй ещё не было.

Соорудил некий скрипт на Пёрдле, который парсит некие данные.

а ты уверен в том, что время обработки больше времени чтения? Иными словами, ты уверен в том, что узкое место в скрипте именно при вычислениях, а не в IO? Если это так, то скорее всего тебе нужно просто поменять алгоритм на более оптимальный, что-бы скорость обработки строки была не больше скорости чтения с диска, тогда скорость будет как у простого чтения без обработки => максимально возможная.

Разбивать задачу на процессы имеет смысл разве что если алгоритм сложный и оптимальный. Но если оно так, то используй более другие ЯП. Многопоточность в перловке это как молоток, для забивания 8 гвоздей одновременно.

Да, срача erlang vs perl на лоре пожалуй ещё не было.

Да это не срач никакой вовсе. Просто возражение против необоснованных обобщений («Ога и так везде») — пример языка и целой платформы, где распараллеливание исполняемого кода продумано и местами даже автоматизировано довольно основательно. В рассматриваемом Перле такого нет и вряд ли когда-либо будет.

fork()

Но «Ога и так везде» - это почти правда. Erlang, некоторые си-компиляторы, разворачивающие циклы openmp, что ещё?

Да и на erlang-e тоже далеко не всё прозрачно параллелится. Взять тот же map/pmap...

Ну и зачем тогда было писать скрипт на perl'е и сейчас что-то спрашивать, если есть такой крутой erlang, который делает всё сам и сразу?

perl это не питон, в нем потоки правильные

а ещё он, наверное, и мёд правильный несёт

Ну и зачем тогда было писать скрипт на perl'е и сейчас что-то спрашивать, если есть такой крутой erlang,

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