Насколько реально прога сделанная на потоках быстрее чем прога на процесах???

Чисто реально чувак быстрее.

А если серьезно, то все зависит от ОС, задачи и т.д.

А если чуть ближе к жизни?? ОС линукс. Предполагаемое время жизни дочернего потока/процесса 1с. количество потоков/процессов около 10. решаемые задачи - получение результатов от внешних прог.

Вопрос производительности уже встал? :)

Premature optimization is the root of all evil -- CarHoare

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

Собственно говоря, разница в скорости в реальных задачах определяется не накладными расходами на создание процесса/треда (как было правильно замечено, в любом случае лучше всего делать пул), а затратами на взаимодействие между процессами resp. тредами. А здесь все не совсем просто. С одной стороны, затраты на синхронизацию тредов (не говоря уже о передаче данных) меньше. С другой стороны, синхронизация должна выполняться чаще -- в частности, любой вызов malloc -- это неявный mutex (по очевидным причинам). И так далее. Поэтому если логически потоки управления слабо взаимодействуют, то лучше использовать процессы. Если же потоки управления сильно взаимодействуют, то в большинстве случаев это свидетельствует о неправильном дизайне ;)

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

Кроме того (это не имеет прямого отношения к вопросу), программирование с использованием тредов намного в большей степени error-prone, поэтому я бы рекомендовал процессы в любом (стандартном) случае.

>Нить стартует значительно быстрее

Насколько я догадываюсь запуск 10 child процессов будет длится ~100 мс. А сколько будет длится запуск 10 нитей???

тоесть меня интересуют реальные цифры, если можно конечно

>Кроме того (это не имеет прямого отношения к вопросу), программирование с использованием тредов намного в большей степени error-prone, поэтому я бы рекомендовал процессы в любом (стандартном) случае.

Поддерживаю. В glibc хватает функций, использующих статический буфер, хотя бы поэтому можно получить неплохое число трудно определимых ошибок. Я предпочитаю процессы + shared memmory только для нужных данных. Вот только у меня такой вопрос. Насколько синхронизация процессов (семафоры) и синхронизация тредов (мьютексы) отличаются по скорости?

>Насколько я догадываюсь запуск 10 child процессов будет длится ~100 мс. А сколько будет длится запуск 10 нитей???

>тоесть меня интересуют реальные цифры, если можно конечно

может стоит самому поэксперементировать?
Тут еще многое зависит от реализации тредов.
Считается, что реализация nptl в 2.6, запускает треды намного быстрее чем 2.4.

>Вот только у меня такой вопрос. Насколько синхронизация процессов (семафоры) и синхронизация тредов (мьютексы) отличаются по скорости?

Насколько я знаю при синхронизации процессов основные задержки обьясняются переключением контекстов которые ещё иногда сопровождаются гейтом в ядро(тоже тормоз)

кстати общие соображения. Лично я синхронизировал процессы только при помощи файловых блокировок

cvv :

> Насколько я догадываюсь запуск 10 child процессов будет длится ~100 мс. А сколько будет длится запуск 10 нитей???

Зависит от ядра/реализации. Надо самому померить, простейший же тест!

cvv (18.10.2004 15:36:30):

> Насколько я знаю при синхронизации процессов основные задержки обьясняются переключением контекстов которые ещё иногда сопровождаются гейтом в ядро(тоже тормоз)

Чем переключение контекстов ниток отличается от оного для процессов?

Свои пять копеек вставлю :) Ведь даже в kernel 2.4 создание потока намного быстрее создания процесса. Там треды - легковесные процессы, разделяющие все пространство. А fork создает новое пространство, да еще копирует код и данные родителя... Ну а NPTL еще быстрее.

> А fork создает новое пространство, да еще копирует код и данные родителя...

fork никогда НЕ копирует код. fork не копирует и данные, они будут копироваться только при попытке записи в страницу. Это называется COW (copy-on-write) и во всех нормальных POSIX-системах именно так все и обстоит, начиная, по-моему с начала 80-x

http://www.uinc.ru/articles/34/#analysis

jek_ (*) (18.10.2004 16:58:03):

> Ведь даже в kernel 2.4 создание потока намного быстрее создания процесса.

Верно (правда, без "даже"). А все остальное - неверно. То есть, совершенно все не так.

Самая дорогая операция при форке -- пометить страницы для COWа. В остальном старт нити не накладнее форка.

2 Die-Hard:

> Чем переключение контекстов ниток отличается от оного для процессов?

не производится переключения mm в случае потоков. само переключение
занимает считанные такты, но имеет "отложенный эффект" - сбрасывается
tlb cache. это дорого. если L1/L2 virtual indexed - то и они.

> Самая дорогая операция при форке -- пометить страницы для COWа. В
> остальном старт нити не накладнее форка.

это верно. но. во-первых - это все-таки (сравнительно) дорогая операция,
во-вторых и parent, и child наказываются в дальнейшем page faults при
записи.

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

> Зависит от ядра/реализации. Надо самому померить, простейший же тест! 

Как померять ?
Linux - не ОС реального времени, начит если закладываться на 
показание часов то это не будет точно.
А как мерять ? 
Если делать с выходом на аппаратуру и осциллографом, но тогда 
может быть больше погрешность.
Если создавать большое количество и замерять среднее ?
Будет ли это точно и будет ли это отражать действительность ?
Может не прав, конечно. 
Но самому интересно, что скажите ?

anonymous (*) (18.10.2004 20:22:28):

>> Зависит от ядра/реализации. Надо самому померить, простейший же тест!

> Как померять ?

Ну -- берешь и меряешь!

> Если создавать большое количество и замерять среднее ?

Точно!

Запоминаешь время (через gettimeofday(), разумеется -- никак не через clock() или getrusage()!), стартуешь n-е кол-во НА ПУСТОМ КОПЬЮТЕРЕ (без других юзеров/задач), вычитаешь запомненное время из вновь полученного и делишь на n.

Лучше всего это делать "в динамике", т.е. несколько раз вызывать из скрипта, перемежая "конкурентными" задачами, и откидывать самые плохие и хорошие результаты.

2Die-Hard & aa5779 & idle: Большое спасибо за информацию. У меня, значит, было совсем искаженное понимание...

>Кроме того, надо иметь в виду, что треды могут хуже масштабироваться, чем потоки.

Кстати, почему?

WFrag:

>>Кроме того, надо иметь в виду, что треды могут хуже масштабироваться, чем потоки.

>Кстати, почему?

Например, в NUMA доступ к "далекой" памяти в разы дольше, чем к "своей". Если все адресное пространство, аффинное к процессору 0, делится тредами, которуе "живут" на процессорах с 15 по 31...