Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
А если чуть ближе к жизни?? ОС линукс. Предполагаемое время жизни дочернего потока/процесса 1с. количество потоков/процессов около 10. решаемые задачи - получение результатов от внешних прог.
Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
Нить стартует значительно быстрее. Но, один хрен, лучше юзать
пул (то есть стартовать дочек в самом начале, а потом с ними общаться). Тогда разницы в скорости нет.
Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
Собственно говоря, разница в скорости в реальных задачах определяется не
накладными расходами на создание процесса/треда (как было правильно замечено, в любом случае лучше всего делать пул), а затратами на взаимодействие между процессами resp. тредами. А здесь все не совсем просто. С одной стороны, затраты на синхронизацию тредов (не говоря уже
о передаче данных) меньше. С другой стороны, синхронизация должна выполняться чаще -- в частности, любой вызов malloc -- это неявный mutex
(по очевидным причинам). И так далее. Поэтому если логически потоки управления слабо взаимодействуют, то лучше использовать процессы. Если же
потоки управления сильно взаимодействуют, то в большинстве случаев это
свидетельствует о неправильном дизайне ;)
Кроме того, надо иметь в виду, что треды могут хуже масштабироваться, чем
потоки.
Кроме того (это не имеет прямого отношения к вопросу), программирование с
использованием тредов намного в большей степени error-prone, поэтому я бы
рекомендовал процессы в любом (стандартном) случае.
Re: Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
>Кроме того (это не имеет прямого отношения к вопросу), программирование с использованием тредов намного в большей степени error-prone, поэтому я бы рекомендовал процессы в любом (стандартном) случае.
Поддерживаю. В glibc хватает функций, использующих статический буфер, хотя бы поэтому можно получить неплохое число трудно определимых ошибок. Я предпочитаю процессы + shared memmory только для нужных данных.
Вот только у меня такой вопрос. Насколько синхронизация процессов (семафоры) и синхронизация тредов (мьютексы) отличаются по скорости?
Re: Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
>Насколько я догадываюсь запуск 10 child процессов будет длится ~100 мс. А сколько будет длится запуск 10 нитей???
>тоесть меня интересуют реальные цифры, если можно конечно
может стоит самому поэксперементировать?
Тут еще многое зависит от реализации тредов.
Считается, что реализация nptl в 2.6, запускает треды намного быстрее чем 2.4.
Re: Re: Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
>Вот только у меня такой вопрос. Насколько синхронизация процессов (семафоры) и синхронизация тредов (мьютексы) отличаются по скорости?
Насколько я знаю при синхронизации процессов основные задержки обьясняются переключением контекстов которые ещё иногда сопровождаются гейтом в ядро(тоже тормоз)
Re: Re: Re: Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
cvv (18.10.2004 15:36:30):
> Насколько я знаю при синхронизации процессов основные задержки обьясняются переключением контекстов
которые ещё иногда сопровождаются гейтом в ядро(тоже тормоз)
Чем переключение контекстов ниток отличается от оного для процессов?
Re: Re: Re: Re: Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
Свои пять копеек вставлю :)
Ведь даже в kernel 2.4 создание потока намного быстрее создания
процесса. Там треды - легковесные процессы, разделяющие все пространство.
А fork создает новое пространство, да еще копирует код и данные
родителя... Ну а NPTL еще быстрее.
Re: Re: Re: Re: Re: Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
> А fork создает новое пространство, да еще копирует код и данные родителя...
fork никогда НЕ копирует код. fork не копирует и данные, они будут
копироваться только при попытке записи в страницу. Это называется
COW (copy-on-write) и во всех нормальных POSIX-системах именно так
все и обстоит, начиная, по-моему с начала 80-x
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
2 Die-Hard:
> Чем переключение контекстов ниток отличается от оного для процессов?
не производится переключения mm в случае потоков. само переключение
занимает считанные такты, но имеет "отложенный эффект" - сбрасывается
tlb cache. это дорого. если L1/L2 virtual indexed - то и они.
> Самая дорогая операция при форке -- пометить страницы для COWа. В
> остальном старт нити не накладнее форка.
это верно. но. во-первых - это все-таки (сравнительно) дорогая операция,
во-вторых и parent, и child наказываются в дальнейшем page faults при
записи.
тем не менее, я с вами полностью согласен. процессы проще и надежнее,
выигрыша заметного в производительности можно добиться в очень редких
случаях, лично я бы 100 раз подумал, прежде чем связываться с потоками.
Re: Re: Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
> Зависит от ядра/реализации. Надо самому померить, простейший же тест!
Как померять ?
Linux - не ОС реального времени, начит если закладываться на
показание часов то это не будет точно.
А как мерять ?
Если делать с выходом на аппаратуру и осциллографом, но тогда
может быть больше погрешность.
Если создавать большое количество и замерять среднее ?
Будет ли это точно и будет ли это отражать действительность ?
Может не прав, конечно.
Но самому интересно, что скажите ?
Re: Re: Re: Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
anonymous (*) (18.10.2004 20:22:28):
>> Зависит от ядра/реализации. Надо самому померить, простейший же тест!
> Как померять ?
Ну -- берешь и меряешь!
> Если создавать большое количество и замерять среднее ?
Точно!
Запоминаешь время (через gettimeofday(), разумеется -- никак не через clock() или
getrusage()!), стартуешь n-е кол-во НА ПУСТОМ КОПЬЮТЕРЕ (без других юзеров/задач),
вычитаешь запомненное время из вновь полученного и делишь на n.
Лучше всего это делать "в динамике", т.е. несколько раз вызывать из скрипта,
перемежая "конкурентными" задачами, и откидывать самые плохие и хорошие
результаты.
Re: Re: Re: Re: Re: Re: Насколько реально прога сделанная на потоках быстрее чем прога на процесах???
WFrag:
>>Кроме того, надо иметь в виду, что треды могут хуже масштабироваться, чем потоки.
>Кстати, почему?
Например, в NUMA доступ к "далекой" памяти в разы дольше, чем к "своей".
Если все адресное пространство, аффинное к процессору 0, делится тредами,
которуе "живут" на процессорах с 15 по 31...