Linux быстрее в создании процессов и потоков(нитей)

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

А еще мы танцевать можем ... быстрее

Интересно, а где есть сборник всех тестов которые проводились относительно вин2000 ХР и линукс ?

2anonymous (*) (2002-02-14 07:46:12.0): "Кто бы сомневался. Скучно.
Вот если бы наоборот было... Вот бы мы все повеселились :) Гы."
Начинай веселится: http://www.interex.org/hpworldnews/hpw202/01lab.html из трех тестов в двух линукс конкретно сосет, в одном он практически равен xp

Кстати мне все такие синтетические тесты напоминают ситуацию с Майнкрафтовскими тестами, когда все линуксоиды тоже думали что линукс крут, а как только протестировали так срочно начали ядро переделывать.

Все эти тесты очень далеки от реальной жизни. Однако факт того, что бесплатный Linux всерьёз сравнивается с супер пупер новейшей коммерческой XP не может не радовать!

Насчет нитей не скажу, но есть у меня один интересный опыт: как-то раз мы с одним знакомым тестировали простеньку программу (там всех дествий было прочесть 18-ти метровый текстовый файл и проделать над данными простейшие действия). При прочих равных Линукс выигрывал у виндов примерно 20% производительности. Был проведен и еще один тест: под виндами для чтения данных использовали "быстрые" функции типа fgets, а под линуксом "медленные" - например, fscanf. В результате Линуксовая программа все равно оказалась быстрее на 10%. Естественно, виндовая программа была собрана без дебага, с оптимизацией на скорость и т.п.

Ну и понятно, что собирали мы ее на MSVC-шным компилятором...

Скорость создания нитей менее важна нежели скорость переключения между ними.

Все это очень хорошо, только одно НО. Создание потока в Линуксе требует выделения для него памяти ручками. А что, если я не знаю, даже примерно, сколько памяти этот поток захапает ?

>Скорость создания нитей менее важна нежели скорость переключения
>между ними.

Золотые слова. А народ все больше с Оргом собачится, а по теме ни пары с уст.

А про нити, про скорость переключения - самое в точку. Насчет
процессов у меня особых сомнений насчет линуксового превосходства
нет, а вот насчет нитей (thread)...... Тут разные истории подходы и
сложившиеся стереотипы разработке систем. В старом-добром юникс-стиле
все как-то больше форкаться принято. Thread в моду входят
постепенно,а вот Windows скорее наоборот, разработчики предпочитают
лучше породить нить(thread) чем запускать еще один экземпляр
прикладухи, да и с точки зрения здравого смысла thread правильнее
будут, гибче. А в этом случае - СКОРОСТЬ ПЕРЕКЛЮЧЕНИЯ между нитями
для производительности системы ВАЖНЕЕ чем СКОРОСТЬ СОЗДАНИЯ нитей.

2lenin: ты хоть сам-то понял что сказал ?

2lb "ты хоть сам-то понял что сказал ?" Понял, понял.

Parameters to clone() system call:
[skip]
%ecx - new stack pointer for cloned chil
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Вот энто, скромно названное "stack pointer" - есть ничто иное, 
как указатель на память для потока, которую надо вручную
выделять. А сколько ее выделять-то, если не занешь, сколько
потоку этой памяти-то надобно ?

2lenin: я тебя как програмист програмиста спрошу, ты програмироваль умееш? Процедура создания трэда в линухе ИДЕНТИЧНА процедуре создания оного в виндях. разница ТОЛЬКО в именах функций

А всеж интересно ......

Так ли непринципиальна скорость создания нитей ???
А если вспомнить то-же www сделать апачь на нитях
насколько быстрее он станет откликатся вместо форка ?

А скорость переключения нитей довольно сложный вопрос.
Ниток в Linux как я помню две штуки первая это каждая нитка как
отдельный процес только с общей памятью. И вторая это когда все нити
в одном процессе и кванты выделенные на процесс распределяются
между этими нитками.

Судя повсему чаще используют нити как отдельный процесс.
Собственно насколько велика разница между переключением процессов и
нитей ?

А, еще небольшое отступление, чтоб совсем в тему было. Я как-то ради эксперимента запустил смотрелку в параллель к собирающейся Мозилле. Хоть бы икнула, показывала ровненько...

Эта... Напомните, сколько времени занимало переключение контекста на машинах первого поколения?

На машинах первого поколения не было контекста.

То есть, типа, он был, но переключать его не надо было...:)

В зависимости от расстояния до шкафа перфокартами. ;-)

2lenin (*) (2002-02-14 13:24:14.0):

> Parameters to clone() system call ....

1. Никогда не пользуйся clone, ибо он - низкоуровневый непереносимый
сисколл.

2. stack pointer - не "указатель на память для потока", а ...
указатель на стек! (кто б мог подумать! :)
Да будет тебе известно, что обычно под стек вообще выделяется некое
неконтролируемое кол-во памяти, и - ничего, работает.

Переключение контекста на 2.4.17 0,00025 секунды.
Переключение провелялось на нитях в JVM

с созданием процессов и нитей все уже давно ясно исравнивать мастдай и Линукс помоему уже давно не нужно.Нужно сравнивать между собой конкретные дистрибутивы Линукс. Например стек протокола TCP/IP или туже скорость создания и переключения между процессами и нитями. Сравнение двух разных по сути осей (Пингвина и Винды) уже не то что надоело, а и не к чему оно. Пингвин и так уже пошел и рекламировать его дальше, тем более сравнивая с продуктами МелкоМягких, практически не нужно. Пользователи Линукс и так знают чем он лучше и удобней чем Винда. А еще лучше сравнили бы лучше по всем критичным параметрам с другими *nix'ами, а тут Линукс может и отстать от других осей и очень очень сильно.А Гейтс и команда пусть делают что хотят и как хотят. И желаю им чтобы приговор суда был не в их пользу. Или я не прав? :-)

Вообще, эта тема избита и замусолена околопрограммерами в этом форуме.Тем неменее, мне, как win программеру было-бы интерестно услышать мнение linux спецов по поводу следующих вопросов: 1) Существует ли в линуксе достаточно "прямой" thread management ? 2) Насколько он (thread management) поддерживается ядром? 3) Приведите пример достаточно известных многотредовых линукс программ.

>Пользователи Линукс и так знают чем он лучше и удобней чем

------------------------------->чем же ?

>Винда.


> А еще лучше сравнили бы лучше по всем критичным параметрам с другими *nix'ами, а тут Линукс может и отстать от других осей и очень
>очень сильно.

И где же ?


PS: Про тесты, точнее про их корректность ....

Приведенные в топике тесты отосятся к ядру 2.4.2 как я понял
ogr же приводил ссылку на тесты сделанные на ядре 2.4.10

ни для кого не секрет что скорость тех или иных операций
к примеру на 2.0.39
2.2.19
2.4.5
2.4.9
2.4.18
2.5.4

это 6 больших разниц и данные по их тестам положенные
на один график НУ НИЧЕГО бы не сказали о реальной производительности
ядра Linux ВООБЩЕ

>1) Существует ли в линуксе достаточно "прямой" thread management ?

IMHO НЕТ (про косяки с сигналами постинг вроде бы уже пролетал)

>2) Насколько он(thread management) поддерживается ядром?
Ну ... с учетом вышесказанного поддерживается

>3) Приведите пример достаточно известных многотредовых линукс программ.

Из из болтающегося сейчас в памяти
1) oops
2) Mozilla
3) Java

фигня. Вопервых это только стек. Во вторых - выдели 10 мегабайт и за бей (или больше), благодаря COW память ен расходуется впустую.

2 green
Я тут подумал что надо бы перевести COW на русский, для непосвещенных -
копирование при записи (КПЗ).. :) Мда, лучше уж не переводить..
Пусть уж будет американская корова. :)

Интересно, про ядро 2.4.2 в RH7.2 это опечатка или хитроумный замысел автора? Ведь в дистриб входит 2.4.7

"Интересно, про ядро 2.4.2 в RH7.2 это опечатка или хитроумный замысел автора? Ведь в дистриб входит 2.4.7"

Читать сначало надо статью, а уж потом высказывать свое мнение.

p.s. у меня Slack 8.0, так что у меня ядрo 2.2 ?

>1) Существует ли в линуксе достаточно "прямой" thread management ?

И "да" и "нет", и даже кривизна рук тут не при чём :)

>2) Насколько он(thread management) поддерживается ядром?

??? В смысле?

>3) Приведите пример достаточно известных многотредовых линукс программ.

Qt и КДЕ (в 3-х версиях этих продуктов - определённо, во 2-х были проблемы), хотя умельцы и без мультитридинга собирают...

Интересно было-бы и в самом деле тест провести на переключения тридов, особенно в рамках одного контекста

И если не работаешь от root и настроены limits, то система не позволит создать больше допустимого количества процессов.

Так ли в действительности важно время переключение между процессами для не realtime ОС?

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

>А ты в люниксе напиши ка

>while (true) { fork(); }

>и подожди несколько секунд.. и ты поймёшь, что тебе не помогают твои единственно
>известные 3 пальца...

))))))))))))))) НАПИСАЛ и ЧТО ?
я даж ничего неделал оно само его прибило ))

Странно и окошки работают и консоль тоже )

Дело не в количестве форков а в прямых руках.

2 anonymous (*) (2002-02-15 02:47:38.0)

1 user for(;;) fork();
2 user while [ 1 = 1 ];do
./bomb
done
одновременно запустились
и ничего тормоза конечно есть (машинка слаба WinIdt200) но вроде
ничего, работать можно
для прикола еще
3 user for(;;) m=(char*)malloc(0xffff);bzero(m);
прибило..
И вообще марш в сад ulimit изучать
З.Ы.
попробуй запустить под 9х
что-то вроде
:1
exec bomb.bat
goto 1
только сохранись сначала:) 3 пальца не помогут, если и помогут значит
реакция хорошая

2всем глумящимся над 98-ми: нет там лимитов и юзер только рут, чего сравнивать то? логинтесь под рутом и глумитесь над линуксом так же. да и к времени переключеиния между нитями/процессами это не имеет никакого отношения.

а не легче Mozill'u на каком то .. ээ .. 120Mhz процессоре пустить и посмотреть где она бестрее загрузится :) Имхо Win в этом привосходит Linux :) правда это к потокам не относится, но можно более комплексно той же Мозиллой :) или че то еще, чем реально пользуешся а не выдумываеть полезные но столь малой достоверностьи тесты .. хотя .. это же IBM :) Я Linux пользую не первый год, и считаю что производительность это его не самое главное привосходство.

Последнему анониму:

Когда поставишь WinXP или хотя бы Win2000 на P120, тогда и будем сравнивать.

Кто бы мне показал придурка, который пишет так, что скорость рождения нитки критична? Обычно нитки генерятся сразу, и в threads pool ожидают, когда их кто заюзает.

А ты не радуйся. Считай, что бесплатный хрюних - это reference implementation. Ну, типа, как бесплатный Tomcat, который говно говном, если с коммерческими енжинами сравнивать, но при этом reference implementation, на который все крутые коммерческие реализации равняются.

2Antichrist (*) (2002-02-15 17:50:37.0):
> Обычно нитки генерятся сразу, и в threads pool ожидают, когда
> их кто заюзает.
Такой подход, я слышал, в Яве часто используется - типа, иначе она вообще
не работоспособной будет.

А, вообще, насколько такой подход распространен? Не подбросишь ссылочек на
дискуссии/описание реализаций, или просто свои мысли, если не лень?

Кажется, ещё и Oops так устроен, но я не уверен.

Вообще, технология примитивная: заводится N тредов, каждому приписана прикрытая кондишеном переменная, указующая на коллбэк, и у каждого функция-обработчик в цикле ждёт освобождения кондишена, дёргает коллбэк и отдаёт дескриптор текущего треда обратно в очередь, прикрыв кондишен. Когда нужно заюзать тред, из головы очереди достаём дескриптор, кладём коллбэк на функцию, которую надо исполнить, отпускаем кондишен. Всё очень легковесно, "вызов" треда почти ничего не стоит (хотя, конечно, зависит от реализации кондишенов). В случае, если тредов не хватает, всегда можно создать новый и воткнуть в очередь.

Кстати, особо красиво это смотрится на всякой функциональщине, вроде Ocaml, поскольку там можно closure передавать (high-order functions). У меня реализация пула тредов занимает ~80 строк с комментариями, никаких глобальных переменных, примитивный интерфейс вызова...

2Antichrist (*) (2002-02-16 00:56:44.0):

Thanks.

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

Я вот сейчас тебя прочел, и сдается мне, что тебе оно в первую очередь
нравится тем, что на "функциональщину" ложится (только не заводись). А, BTW,
я уже с ходу (i.e., не подумав ;)) замечаю спорное место: а как с практической
точки зрения организовать сосуществование многих idle процессов, даже не
кушающих память? Появятся трудности, IMHO, ежели этим по-настоящему
злоупотребить.

Дык ведь нитки ресурсов почти и не кушают. Ждущий на мутексе или кондишене тред не получит ни единого слайса времени, пока держащий его мутекс не отпустят. Ну а closures весьма легко эмулируются и в императивных языках (я не зря про коллбэки написал).

Для чего я использую такую схему: система строится на обмене сообщениями, состоит из некоторого количества "серверов", которые что-то там делают, и кидают друг в друга коротенькими сообщениями-запросами. Многие "сервера" могут работать одновременно, для чего сообщение кидается в очередь, в ней независимые сообщения сортируются, и вываливаются в пул тредов, где вешаются на "сервер"-обработчик. Такая схема работает и с тредами, и с соединёнными через сокеты процессами (только в этом случае требуется ещё сериализовать те данные, которые для тредов были бы в общей памяти), и, соответственно, всё нехило масштабируется как на SMP, так и на кластер, и при этом для написания самих "серверов" ничего такого особенного в голове держать не надо - все плюшки автоматом получаются.

2Antichrist (*) (2002-02-16 01:36:48.0):

> Дык ведь нитки ресурсов почти и не кушают.
Кушают. Стек.

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

Как это разрешается?

Зачем же большое количество? Выжранными реально будут только те страницы, которые будут использованны. Так что тут никакого оверхеда от десятка-двух тредов не будет.

2Antichrist (*) (2002-02-16 01:36:48.0):

Еще соображения.

Да, кстати, я, действительно, не эксперт в этом. Просто, сейчас время есть
подумать над этим (просто для общего развития; мне пока это все не актуально).
Если тебе не охота просвещать меня более, то просто скажи, но не матерись ;).

> Такая схема работает и с тредами, и с соединёнными через сокеты процессами
> (только в этом случае требуется ещё сериализовать те данные, которые для
> тредов были бы в общей памяти)
Я так понимаю, что сериализацию данных ты (логически) объединяешь с процессами
(вместо нитей) для масштабирования на кластер.
А, между прочим, с тем же успехом можно использовать процессы вместо тредов и
для SMP, расшарить память вручную и сажать ожидание на семафоры. Непонятно, в
чем бенефит тредов vs. процессов? СОЗДАНИЕ треда быстрее, ок, но если мы, один
хрен, в пул их коллектим? Сложнее - ну, ты так лихо предлагаешь видоизменение
схемы на кластер, что подразумевает фактически "ручную" реализацию расшаривания
памяти через сериализацию, т.е. аргумент "сложно" выглядит несерьезно ;) В конце
концов, можно раз и навсегда написАть стандартный враппер.
А бенефит (юзания процессов вместо ниток) очевиден - надежность, один процесс
не сможет грохнуть все остальное.

Конечно, в win32 такой номер не пройдет, там fork'а нет - но под Позиксом
я не вижу преимущества тредов с точки зрения пула.

Далее, я не совсем понимаю мелькнувшее противопоставление SMP vs. Claster,
в том смысле, что IMHO описанная технология (пул ниток) никакого отношения к SMP
не имеет. Прикинь, количество тредов в очереди должно примерно соответствовать
(ожидаемой пиковой нагрузке) * (характерное время реакции сервера). Но НИКАК не
связано с количеством процессоров! Речь не о масштабируемости, а об уменьшении
latency, связанной с поднятием дежурного треда; просто во избежании частого
порождения/убивания контекстов.

Теперь можем вернуться к проблеме стека.

Дальнейшее изложение - несколько утрировано и преследует цель показать, что
пока я не увидел реальной идеи за пулом тредов.

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

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

Как только припоминаем про асинхронность, сразу возникает проблема фрагментации.
Однако, припомнив про вышеописанную независимость идеи тред пула от SMP, соображаем,
что разумно (по крайней мере, на одном процессоре) пренебречь параллелизмом и
организовать нечто вроде cooperative thread.

И замечаем, что получившаяся конструкция СИЛЬНО напоминает нечто до боли знакомое.
Именно, обычный вызов подпрограммы.

Итак, в своем стремлении последовательной реализации идеи тред пула мы
"изобрели велосипед".

Any comments?

2Antichrist (*) (2002-02-17 21:53:51.0):
> Выжранными реально будут только те страницы, которые будут
> использованны.
До первого вызова.

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

> Так что тут никакого оверхеда от десятка-двух тредов не будет.
Ну, от "десятка-двух" не будет. Я предполагал масштабирование на тысячи.

По поводу сериализации - фишка в том и заключается, что в случае с тредами её не надо, и делается она только если получатель сообщения живёт в другом процессе. Что весьма ценно для производительности. Кроме того, для некоторых типов сообщений сериализация вообще запрещена, и тогда система не позволит в разных контекстах завести обработчиков, которые могут такие сообщения друг другу слать.

SMP тут совершенно при деле - обработчики могут юзать шаренную память (немутабельную, естественно), и щёлкать одновременно, то есть, при хорошо разпараллеливаемой задаче у нас почти линейный выигрышь на SMP без оверхеда на сериализацию и вообще message-passing.

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

На фиг нужен пул из тысячи тредов? Обычно на параллельное исполнение имеет смысл посылать не более десятка обработчиков, или не более N тяжёлых процесорожрущих обработчиков, где N - число процессоров.

Die-Hard:

> > Выжранными реально будут только те страницы, которые будут
> > использованны.
> До первого вызова.

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

В винде по CreateThread коммитится одна страница памяти, т.е. 4к. Только если потоку этого не хватит, добавится еще одна и т.д. до 1 мегабайта вроде.

Я уверен, что на других аппаратных платформах это тоже есть.

2Havoc (*) (2002-02-18 12:48:37.0):
Thanks, не знал. интересно. Если есть ссылка под руками, pls. ее сюда,
если нет, то сам поищу на досуге.

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

Или контроль стека реализУем каким-нибудь хитрым механизмом, типа
pagefaults?

И еще - все равно, костыль. Антихрист уже указывал, что даже без этого
механизма реально память будет отдаваться тогда, когда ее реально попросят.
Проблема в том, что она не будет освобождаться. Т.е., весь пул будет
быстро распухать до размеров (самый толстый коллбэк)*(кол-во тредов)