в библиотеке
Про AnyEvent там же.  Думаю что вам лучше будет про него почитать - он попроще.

Многопоточность необходимо использовать при приложениях, например, клиент - сервер, где идет постоянное "общение", в то же время как fork - более "легкий" позволяет разгрузить один процес, создав несколько копий, с рановмерным или неравномерным распределением выполняемых задач.

А вообще, попросил бы тебя быть повежливее. Если бы ты понимал в чем разница между многопоточностью и ветвлением, то должен был бы осознавать, что выбор "инструмента" в данном случае в первую очередь зависит не от потребляемой памяти, а от того какие задачи нужно решать...

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

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

Я бы отметил, что это относится только к перлу. И еще на *nix подобных ОС они работают, как оказалось, получше, чем на Windows.


А я так и не померил все сам. Есть ссылочка на готовые замеры?

Да, речь только о perl. 
На windows - при запуске ~ 30 потоков я получал креш в 50 % случаев. Печально

Очень любопытно было-бы посметреть на такие замеры, у меня как не проведу замеры каждый раз fork меньше памяти потребляет =)

Проблема перла в том, что в нём нет потоков. Забудьте о threads. Это полноценные процессы, создание которых занимает значительное время, и потребляет памяти больше, чем fork  в *nix cистемах (в windows - одинаково). Нет нормальной разделяемой памяти (threads::shared - это чёрная магия, никакой разделяемой памяти). 

Если ваша задача упирается в cpu - используйте fork. Сначала загрузить все модули и данные в память, а потом форкаться. Память будет дублироваться только для изменённых данных. Если упирается в ожидание ввода/вывода - я бы посоветовал Coro. Или AnyEvent::EV. Или IO::Lambda. Но не POE ;)

Это сообщение отредактировал(а) DurRandir - 15.11.2009, 16:22

Достаточно посмотреть в исходники, чтобы убедиться, что вы не правы.

Товарищ не так уж далек от истины.. В том плане, что в перле на каждый поток создается свой интерпретатор, с полной копией данных. 
А уж потом некоторые данные делаются общими (с помощью shared переменных).
Так что выигрыш в памяти может быть незаметным.

OC скопирует нужные (и только нужные, и только при необходимости) страницы данных в новом процессе быстрее и эффективнее, чем копирование вручную всего интерпретатора заранее, пусть даже и внутри одного процесса. Перловые threads потоки в том смысле, что они используют общее адресное пространство (добавляя много весёлого при работе с XS модулями). Но они не потоки в том смысле, который обычно подразумевается - достаточно дешёвый объект, использующий полностью разделяемую память при обращении к данным и имеющий выделенный стек. Перловые потоки - это бекпорт на *nix програмной эмуляции fork на win-системах.

PS: да, ещё один модуль вспомнил - forks.

Это сообщение отредактировал(а) DurRandir - 16.11.2009, 14:48

Я в курсе. Читал сорцы наискосок. Тем не менее, в ОС в которых доступна библиотека pthread будут нормальные потоки (если конечно специально не отключить эту возможность при сборке). Да, с интерпретатором внутри. Но потоки.

Немного отсутпая от темы: если вас волнует скорость и обилие системных вызовов, устройство потоков и подобные вещи, то пора переходить на Си.

Добавлено @ 14:58

Два раза прочитал, но не уверен, что понял правильно. Да, в windows потоки эмулируются через fork, который тоже в свою очередь эмулируется через что-то. Это имелось в виду?

Это сообщение отредактировал(а) KSURi - 16.11.2009, 14:58

Потоки в *nix используют код, похожий на тот, что используется в win для эмуляции fork (там он эмулируется как-раз через виндовые потоки).


Меня волнует бесцельное разбазаривание ресурсов  У меня есть форкающийся демон, при соотношение vss/rss 75mb/35mb реальный расход памяти на 1 экземпляр - 10мб. А с потоками было бы под 25-30 (я не уверен, сколько именно займёт клон интерпретатора).

Потоки в *nix используют POSIX threads (ака pthreads) по умолчанию, а в win* - функции предоставляемые ядром ОС (CreateThread) (не уверен на 100%, подсказали). В каком смысле они "похожи"?
Таким образом, по крайней мере на nix* ОС мы имеем полноценные потоки, пусть они и жрут память.


Откуда информация? Она перекрывает одно из преимуществ потоков - легковесность по сравнению с процессами.

Это стандартный механизм Copy-on-Write. Точно применяется при форке в Linux & Freebsd.

Почему быстрее? Потому что этим сразу занимается ОС. 
Почему эффективнее? Потому что копируется только то, что меняется (название метода). А клонирование интерпретатора - это копирование всей памяти заранее, не зная, надо это или нет. А с форком приложению ни о чём не надо беспокоиться.


Что делаем в win для эмуляции форка? 
1. Нам надо создать копию приложения - создаём новый поток
2. Но все данные (пока) общие, поэтому клонируемся, делая все данные приватными
3. Мы получили поток, но с изолированной памятью - по сути, процесс, что и требовалось

Теперь в nix:
1. Нам надо создать поток - создаём его
2. Клонируемся, делая все данные приватными, не трогая ::shared (или тоже клонируем, но не суть)
3. Получили перловый поток. Но чем он отличается от win-"процесса"?

А теперь по легковесности - я даже тредовый перл собрал на тестовой машинке 

use <many modules>;
for (1..2000){
  if (fork){
    next;
  }else{
    exit 0;
  }
}
runtime: 11.7451310157776

А теперь

for (1..2000){
  threads->create(sub{
    return 1;
  })->detach();
}

Out of memory! Сам скрипт занимает ~10мб в памяти. Убираем немного модулей...segmentation fault! Добро пожаловать в мир несовместимостей) Оставляю только Time::HiRes.
runtime: 13.0303740501404

А если ждать завершения каждого потока? Меняем detach->join
runtime: 9.81970191001892

Ну и чтобы убедиться, что потоки съедают память на ура - добавляем и для потоков, и для процессов sleep 5.

Created thread #883
Thread creation failed: pthread_create returned 35 at ./threads.pl line 33.

Упираемся в ограничение 512res для процесса.

Для процессов: Mem: 730M Active по сравнению с Mem: 559M Active в обычном состоянии. Дельта - 171мб. На все 2000 процессов.