Apache vs. Apache2.

Дело не столько в производительности, сколько в модели программирования.

P.S. желаю тем, кто использует термин «поток» в смысле «нить», быстрой, но мучительной смерти.

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

Ты даже не догадываешься, насколько нити в модели 1x1 Threading (одна нить на один процесс) вместо N:M Threading улучшают масштабируемость и интерактивность приложения.

Так, Apache... Можно теперь как-нибудь поконкретнее? Т.е. по сути, это сервер, который отвечает на HTTP запросы, так? Или имеется в виду более сложное применение? Можно выделить характерный режим использования сервера, когда наиболее ярко проявляется преимущество pthreads перед традиционными процессами, например, когда происходит большой наплыв клиентов, или даже если количество запросов и соединений равномерно распределено во времени, уже проявляется преимущество. Какой именно из параметров производительности показывает преимущество, общее число запросов, обработанных в единицу времени и/или время реакции запрос-ответ для отдельных соединений?

PostgreSQL вроде бы использует процессы, а не треды. Тормозным бы я его не назвал. Так что тут скорее разница в подходах, а не тупо «хорошо/плохо».

mysql

>Дело не столько в производительности, сколько в модели программирования.

Не очень понял идею... дело в архитектуре ПО?

В линуксе нет потоков

А что в нём есть? Задачи?

Если что, «поток» в моём понимании - это независимая единица планирования, обладающая общим адресным пространством с другими «потоками» (за исключением стека).

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

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

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

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

Эти параметры прямо связаны между собой: меньшее кол-во запросов может система обрабатывать одновременно -> больше очередь на обслуживание -> увеличение времени отклика. В простой модели увеличивается время ожидания в очереди, но с уменьшением свободной памяти будет так же увеличиваться и время обработки каждого запроса.

стек там тоже общий. Если наловчиться.

В линуксе нет потоков

Что, правда что ли? O_o

легковесные процессы

> P.S. желаю тем, кто использует термин «поток» в смысле «нить», быстрой, но мучительной смерти.

Желаю велико-русским программистам перестать проявлять национальную щизу и заменять устоявшиеся термины на великорусские. Вы ещё «словарь Великаго Рускаго языка» вспомните и грамматику тех времён.

POSIX Threads реализованы в UNIX™, Unix, псевдо-Unix и даже в Windows.

> а вот создание нового процесса в Unix, традиционно, ничего не стоит

А что такого есть в юникс-лайк системах, что традиционно делает создания процессов «лёгкой и быстрой» операцией, которая «ничего не стоит», a?

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

Ага... тогда ясно.

> POSIX Threads реализованы в ... Windows.

это ты про обертку pthreads-win32, которая умудряется течь на ровном месте и заброшена годы назад?

Нет, я про NPTL.

> Нет, я про NPTL.

смешно

чисто гипотетически - главное преимущество нитей vs процессы
в том что при нитях - ВСЯ память и все ресурсы доступны одновременно всем нитям - они просто общие

в этом главное преимущество и главный недостаток


нити лучше там где нужно очень большое обшение между ними - или резделяемость ресурсов (тех же сетевых сокетов)

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

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

А что такого есть в юникс-лайк системах, что традиционно делает создания процессов «лёгкой и быстрой» операцией, которая «ничего не стоит», a?

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

В Windows изоляция процессов происходит с учётом семантики нитей — диспетчеризация квантов процессорного времени идёт на уровне нитей, а не процессов. Синхронизация нитей и памяти выполняется гораздо дольше.

Да, как раз это хотел сказать, опередили :)

Давно интересует вопрос

Не буду создавать новую тему, вопрос по-моему хорошо вписывается в эту.

Все же в линуксе треды (потоки/нити/какхотите) - это некоторая независимая сущность или суть процесс? Специализированную литературу по ядру мне осилить очень сложно (пытался, завис на первой главе; может поумнею, прочитаю), а в разных статейках и форумных баталиях высказываются диаметрально противоположные утверждения.

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

Что же все таки происходит на самом деле?

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

... или процесс изоляции «размазывается» по времени выполнения порождённого процесса...

>стек там тоже общий. Если наловчиться.

???

Что же все таки происходит на самом деле?

Из научпопа могу посоветовать книги: Ю. Вахалия «UNIX изнутри»; Э. Таненбаум «Современные операционные системы».

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

Ты путаешь тёплое и мягкое. COW и аналоги всё равно имеют затраты на управляющие структуры, описывающие адресное простанство процесса и маппинг. По твоей логике создание треда должно быть вообще мгновенным (а это не так).

>>Что же все таки происходит на самом деле?

Из научпопа могу посоветовать книги: Ю. Вахалия «UNIX изнутри»; Э. Таненбаум «Современные операционные системы».

Это хорошие книги, но что из них можно узнать о реализации нитей в ядре Linux?

«Understanding the Linux Kernel» - вот правильная книга.

> обладающая общим адресным пространством с другими «потоками» (за исключением стека).

Их стеки тоже лежат в общем пространстве.

> Ты путаешь тёплое и мягкое. COW и аналоги всё равно имеют затраты на управляющие структуры, описывающие адресное простанство процесса и маппинг.

Как раз именно об этом и хотел написать.

Почему никто не сказал о надежности?

В линуксе нить/поток — это процесс, не имеющий собственного адресного пространства (а использующий чужое). Других отличий между нитями и процессами нет, они создаются одним и тем же системным вызовом clone(2), только с разными флагами. Та же история в большинстве других юниксов. Так что выбор между этими вариантами, действительно, должен производиться на основе ответа на вопрос — обеспечит ли IPC достаточную производительность для обмена данными между процессами в данной задаче.

Была такая тема уже в Talks, поищи, намного больше интересного узнаешь.

мы ей тампакс вставляли, очень жаль что забросили её.

в линуксе нет слова «нить», это набежавшие виндузятники его с собой принесли, и размахивают им.

в линуксе нет слова «нить»

Смирись с тем, что слово «нить» стало общеупотребительным термином, вне зависимости от операционной системы.

> В основном расширение системы типов + небезопасные функции работы со строками, памятью, файловый ввод/вывод да немного математики.

Где стало? Почему я не слышал это про это, кроме как на rsdn и местами на лоре? Хватит фантазироватьI

Где стало? Почему я не слышал это про это, кроме как на rsdn и местами на лоре? Хватит фантазировать!

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

> P.S. желаю тем, кто использует термин «поток» в смысле «нить», быстрой, но мучительной смерти.

Мицгол, ты?

А теперь замени в запросе нить на поток и сравни.

Многие из них уже.

Их работы выходили в 70-ых, так что тем, кто остался должно быть за 60.


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

:3

rfork(RF_PROC|RF_MEM); Не?

А теперь замени в запросе нить на поток и сравни.

Во всем виноваты вантузятники :)

Да хоть как назови, какая разница как они там изнутри реализованы.

«нить» - ублюдочная калька, «поток» - полноценная русская замена.

> Ты даже не догадываешься, насколько нити в модели 1x1 Threading (одна нить на один процесс) вместо N:M Threading улучшают масштабируемость и интерактивность приложения.

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