[sisyphus] Как ускорить работу с потоками?

[sisyphus] Как ускорить работу с потоками?

[Boronin Sergey]

Всем добрый день.

Я занимаюсь созданием на Kylix 2 Ent. кроссплатформенного ПО для VRG.
Все создаваемое ПО должно быть многопоточным и работать асинхронно.
Пришлось создать класс обеспечивающий потокобезопасное разруливание
блокировок для чтения и записи, причем читать из любого расшаренного
ресурса может одновременно множество потоков, а записывать, только один,
и то, только поле того, как завершаться все читающие потоки, этакий
аналог TMultiReadExclusiveWriteSynchronizer, но с поддержкой вложенных
блокировок(может вкладываться несколько блокировока на чение и только
одна на запись).
Наткнулся на следующую проблему:
В виндах скорость работы потоков в 1000 раз (да именно 10^3 раз) быстрее
чем в линуксе.
Вопрос: «Почему так и как это побороть?»

Дистрибутив:
ALT Linux Master 2.0 (листемные либы не апдейтил) – ядро 2.4.18 (по
умолчанию)
Kylix 2 Enterprise установлен в папку обычного пользователя (не под
рутом, поэтому либы не подменял)

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

С уважением,
Боронин Сергей

Re: [sisyphus] Как ускорить работу с потоками?

[Serge Ryabchun]

В сообщении от понеділок, 30-сер-2004 14:29 Boronin Sergey написал(a):
> Всем добрый день.
>
> Я занимаюсь созданием на Kylix 2 Ent. кроссплатформенного ПО для VRG.
> Все создаваемое ПО должно быть многопоточным и работать асинхронно.
> Пришлось создать класс обеспечивающий потокобезопасное разруливание
> блокировок для чтения и записи, причем читать из любого расшаренного
> ресурса может одновременно множество потоков, а записывать, только один,
> и то, только поле того, как завершаться все читающие потоки, этакий
> аналог TMultiReadExclusiveWriteSynchronizer, но с поддержкой вложенных
> блокировок(может вкладываться несколько блокировока на чение и только
> одна на запись).
> Наткнулся на следующую проблему:
> В виндах скорость работы потоков в 1000 раз (да именно 10^3 раз) быстрее
> чем в линуксе.
> Вопрос: «Почему так и как это побороть?»
>

Запускать не из под ide?

Re: [sisyphus] Как ускорить работу с потоками?

[Gleb Kulikov]

В сообщении от Понедельник 30 Август 2004 18:29 Boronin Sergey написал:

> и то, только поле того, как завершаться все читающие потоки, этакий
> аналог TMultiReadExclusiveWriteSynchronizer, но с поддержкой вложенных
> блокировок(может вкладываться несколько блокировока на чение и только

> Вопрос: «Почему так и как это побороть?»

Поподробнее, как реализована блокировка? 
-- 
						Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
netmail: 2:5005/78

RE: [sisyphus] Как ускорить работу с потоками?

[Boronin Sergey]

Спасибо, я уже сам нашел причину проблемы. Я использовал в основе своего
класса для разруливания блокировок кроссплатформенную версию
TMultiReadExclusiveWriteSynchronizer, которая по-разному работает в
виндах и линуксе. В виндах BeginRead, работает так, как следует из его
названия, а в линуксе, реализации BeginRead и BeginWrite одинаковы и
используют _phtread_mutex (из библиотеки libc), отсюда и разность в
поведении. После того, как я это учел, все заработало нормально и с
нормальной скоростью, так что это была моя ошибка.

Так что проблема решена, спасибо.

Интересная особенность, что при попытке создания 1015 потоков в линуксе,
выдается exception, при том, что в винде и 8000 потоков нормально
отрабатывали, хотя и медленно. Не знаете с чем это может быть связано?


С уважением,
Боронин Сергей

-----Original Message-----
From: Gleb Kulikov [mailto:glebus@asd.iao.ru] 
Sent: Monday, August 30, 2004 9:07 PM
To: analisys@quality.s2.ru; ALT Linux Sisyphus discussion list
Subject: Re: [sisyphus] Как ускорить работу с потоками?

В сообщении от Понедельник 30 Август 2004 18:29 Boronin Sergey написал:

> и то, только поле того, как завершаться все читающие потоки, этакий
> аналог TMultiReadExclusiveWriteSynchronizer, но с поддержкой вложенных
> блокировок(может вкладываться несколько блокировока на чение и только

> Вопрос: «Почему так и как это побороть?»

Поподробнее, как реализована блокировка? 
-- 
						Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
netmail: 2:5005/78

Re: [sisyphus] Как ускорить работу с потоками?

[Sviataslau Svirydau]

Boronin Sergey wrote:

>...
>Интересная особенность, что при попытке создания 1015 потоков в линуксе,
>выдается exception, при том, что в винде и 8000 потоков нормально
>отрабатывали, хотя и медленно. Не знаете с чем это может быть связано?
>  
>

ulimit -u?

-- 
Regards,
Sviataslau Svirydau <Sviataslau_Svirydau at epam.com>
phone:  +375 17 210 1662, ext. 1302
mobile: +375 29 641 4214
-- 
Prejudice:
	A vagrant opinion without visible means of support.
		-- Ambrose Bierce

RE: [sisyphus] Как ускорить работу с потоками?

[Boronin Sergey]

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

С уважением,
Боронин Сергей

-----Original Message-----
From: sisyphus-bounces@altlinux.ru [mailto:sisyphus-bounces@altlinux.ru]
On Behalf Of Boronin Sergey
Sent: Tuesday, August 31, 2004 11:33 AM
To: sisyphus@altlinux.ru
Subject: RE: [sisyphus] Как ускорить работу с потоками?

Спасибо, я уже сам нашел причину проблемы. Я использовал в основе своего
класса для разруливания блокировок кроссплатформенную версию
TMultiReadExclusiveWriteSynchronizer, которая по-разному работает в
виндах и линуксе. В виндах BeginRead, работает так, как следует из его
названия, а в линуксе, реализации BeginRead и BeginWrite одинаковы и
используют _phtread_mutex (из библиотеки libc), отсюда и разность в
поведении. После того, как я это учел, все заработало нормально и с
нормальной скоростью, так что это была моя ошибка.

Так что проблема решена, спасибо.

Интересная особенность, что при попытке создания 1015 потоков в линуксе,
выдается exception, при том, что в винде и 8000 потоков нормально
отрабатывали, хотя и медленно. Не знаете с чем это может быть связано?


С уважением,
Боронин Сергей

-----Original Message-----
From: Gleb Kulikov [mailto:glebus@asd.iao.ru] 
Sent: Monday, August 30, 2004 9:07 PM
To: analisys@quality.s2.ru; ALT Linux Sisyphus discussion list
Subject: Re: [sisyphus] Как ускорить работу с потоками?

В сообщении от Понедельник 30 Август 2004 18:29 Boronin Sergey написал:

> и то, только поле того, как завершаться все читающие потоки, этакий
> аналог TMultiReadExclusiveWriteSynchronizer, но с поддержкой вложенных
> блокировок(может вкладываться несколько блокировока на чение и только

> Вопрос: «Почему так и как это побороть?»

Поподробнее, как реализована блокировка? 
-- 
						Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
netmail: 2:5005/78

RE: [sisyphus] Как ускорить работу с потоками?

[Boronin Sergey]

>ulimit -u?
>

128 процессов на одного пользователя. Если учеть что потоки
обрабатываются ядром по аналогии с процессами у меня должно было
запуститься всего 100 с небольшим потоков, а спокойно запускается 1012,
и валится на 1015 потоках.
А вот число одновременно открытых файлов -1024 на одного пользователя,
не может это быть как-то связано, не создается ли для каждого потока
файловый дескриптор для /proc?

Система:
ALT Linux Master 2.0 (ядро 2.4.18 дефолтное)
Kylix 2 Enterprise


С уважением,
Боронин Сергей

-----Original Message-----
From: Sviataslau Svirydau [mailto:Sviataslau_Svirydau@epam.com] 
Sent: Tuesday, August 31, 2004 11:44 AM
To: analisys@quality.s2.ru; ALT Linux Sisyphus discussion list
Subject: Re: [sisyphus] Как ускорить работу с потоками?

Boronin Sergey wrote:

>...
>Интересная особенность, что при попытке создания 1015 потоков в
линуксе,
>выдается exception, при том, что в винде и 8000 потоков нормально
>отрабатывали, хотя и медленно. Не знаете с чем это может быть связано?
>  
>

ulimit -u?

-- 
Regards,
Sviataslau Svirydau <Sviataslau_Svirydau at epam.com>
phone:  +375 17 210 1662, ext. 1302
mobile: +375 29 641 4214
-- 
Prejudice:
	A vagrant opinion without visible means of support.
		-- Ambrose Bierce

Re: [sisyphus] Как ускорить работу с потоками?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

On Tue, Aug 31, 2004 at 11:58:35AM +0400, Boronin Sergey wrote:
> Сорри за формулировку, насчет создания больше чем 1015 потоков проблем
> нет, проблемы начинаются если все эти потоки натравить на один общий
> ресурс, из которого они все хотят читать и в который все хотят писать.

Извините, а сколько у вас процессоров?

См. http://sources.redhat.com/ml/libc-alpha/2001-12/msg00112.html


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: [sisyphus] Как ускорить работу с потоками?

[Boronin Sergey]

>Извините, а сколько у вас процессоров?
>

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

>См. http://sources.redhat.com/ml/libc-alpha/2001-12/msg00112.html
>

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

Просто мне показалось странным, что винды легко держат и 8000 потоков, а
у линукса их 1024, причем доступны 1021, а с учетом запущенных программ
и получается, что реально можно использовать 1000-1012.

Зато теперь разобрался почему так а не иначе, спасибо всем, кто принял
участие в дискуссии.

С уважением,
Боронин Сергей

-----Original Message-----
From: sisyphus-bounces@altlinux.ru [mailto:sisyphus-bounces@altlinux.ru]
On Behalf Of Dmitry V. Levin
Sent: Tuesday, August 31, 2004 1:40 PM
To: 'ALT Linux Sisyphus discussion list'
Subject: Re: [sisyphus] Как ускорить работу с потоками?


On Tue, Aug 31, 2004 at 11:58:35AM +0400, Boronin Sergey wrote:
> Сорри за формулировку, насчет создания больше чем 1015 потоков проблем
> нет, проблемы начинаются если все эти потоки натравить на один общий
> ресурс, из которого они все хотят читать и в который все хотят писать.

Извините, а сколько у вас процессоров?

См. http://sources.redhat.com/ml/libc-alpha/2001-12/msg00112.html


-- 
ldv

Re: [sisyphus] Как ускорить работу с потоками?

[Vadim Gorodisky]

On Tue, 31 Aug 2004 11:32:51 +0400
"Boronin Sergey" <analisys@quality.s2.ru> wrote:

> Интересная особенность, что при попытке создания 1015 потоков в линуксе,
> выдается exception, при том, что в винде и 8000 потоков нормально
> отрабатывали, хотя и медленно. Не знаете с чем это может быть связано?
Как-то давно с этим сталкивался, помню, полечилось тем,
что новые треды содавались после того, как им устанавливали

pthread_attr_setdetachstate(thr->attr, PTHREAD_CREATE_DETACHED);

Удачи,
=========================================
Vadim Gorodisky  (VG22-RIPE)
mailto:vg@odessa.net jid:gor@jabber.od.ua
http://nexus.odessa.ua/authors/vadim
___LL===inux_____________________________

= This game will never be the same =

RE: [sisyphus] Как ускорить работу с потоками?

[Boronin Sergey]

Спасибо, обязательно попробую.

С уважением,
Боронин Сергей

-----Original Message-----
From: Vadim Gorodisky [mailto:vg@altlinux.ru] 
Sent: Tuesday, September 07, 2004 5:43 PM
To: analisys@quality.s2.ru; ALT Linux Sisyphus discussion list
Subject: Re: [sisyphus] Как ускорить работу с потоками?

On Tue, 31 Aug 2004 11:32:51 +0400
"Boronin Sergey" <analisys@quality.s2.ru> wrote:

> Интересная особенность, что при попытке создания 1015 потоков в
линуксе,
> выдается exception, при том, что в винде и 8000 потоков нормально
> отрабатывали, хотя и медленно. Не знаете с чем это может быть связано?
Как-то давно с этим сталкивался, помню, полечилось тем,
что новые треды содавались после того, как им устанавливали

pthread_attr_setdetachstate(thr->attr, PTHREAD_CREATE_DETACHED);

Удачи,
=========================================
Vadim Gorodisky  (VG22-RIPE)
mailto:vg@odessa.net jid:gor@jabber.od.ua
http://nexus.odessa.ua/authors/vadim
___LL===inux_____________________________

= This game will never be the same =

Re: [sisyphus] Как ускорить работу с потоками?

[Ildar Mulyukov]

Vadim Gorodisky wrote:

>On Tue, 31 Aug 2004 11:32:51 +0400
>"Boronin Sergey" <analisys@quality.s2.ru> wrote:
>
>  
>
>>Интересная особенность, что при попытке создания 1015 потоков в линуксе,
>>выдается exception, при том, что в винде и 8000 потоков нормально
>>отрабатывали, хотя и медленно. Не знаете с чем это может быть связано?
>>    
>>
>Как-то давно с этим сталкивался, помню, полечилось тем,
>что новые треды содавались после того, как им устанавливали
>
>pthread_attr_setdetachstate(thr->attr, PTHREAD_CREATE_DETACHED);
>  
>
Не совсем. Это полечит только следующую ситуацию: в программе Вы 
создаёте потоки, которые после завершения оставляют код завершения, но 
этот код завершения, к сожалению, никто не считывает. Из-за этого 
остаются "зомби", которые ждут, что их считают. Но, хуже того, остаются 
занятыми дескрипторы нитей. Это, вместе с ограничением кол-ва 
дескрипторов в ядре, препятствует созданию новых нитей.
Есть простые спрособы увеличить это количество - поищите на opennet.ru - 
там точно есть. Но нужно пересобирать ядро.

С уважением, Ильдар

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

RE: [sisyphus] Как ускорить работу с потоками?

[Boronin Sergey]

>Есть простые спрособы увеличить это количество - поищите на opennet.ru
- 
>там точно есть. Но нужно пересобирать ядро.
>

Спасибо, но мне это не подходит, т.к. одним из требований к софту,
является то, что он (софт) должен нормально работать на нормальных,
"стандартных" (мейнстримовых) ядрах c kernel.org, RH 7.2+, SUSE 8.x+,
Mandrake 8.2+, а также на популярных Debian, ALTLinux, ASPLinux.

С уважением,
Боронин Сергей

-----Original Message-----
From: sisyphus-bounces@altlinux.ru [mailto:sisyphus-bounces@altlinux.ru]
On Behalf Of Ildar Mulyukov
Sent: Tuesday, September 07, 2004 6:25 PM
To: ALT Linux Sisyphus discussion list
Subject: Re: [sisyphus] Как ускорить работу с потоками?

Vadim Gorodisky wrote:

>On Tue, 31 Aug 2004 11:32:51 +0400
>"Boronin Sergey" <analisys@quality.s2.ru> wrote:
>
>  
>
>>Интересная особенность, что при попытке создания 1015 потоков в
линуксе,
>>выдается exception, при том, что в винде и 8000 потоков нормально
>>отрабатывали, хотя и медленно. Не знаете с чем это может быть связано?
>>    
>>
>Как-то давно с этим сталкивался, помню, полечилось тем,
>что новые треды содавались после того, как им устанавливали
>
>pthread_attr_setdetachstate(thr->attr, PTHREAD_CREATE_DETACHED);
>  
>
Не совсем. Это полечит только следующую ситуацию: в программе Вы 
создаёте потоки, которые после завершения оставляют код завершения, но 
этот код завершения, к сожалению, никто не считывает. Из-за этого 
остаются "зомби", которые ждут, что их считают. Но, хуже того, остаются 
занятыми дескрипторы нитей. Это, вместе с ограничением кол-ва 
дескрипторов в ядре, препятствует созданию новых нитей.
Есть простые спрособы увеличить это количество - поищите на opennet.ru -

там точно есть. Но нужно пересобирать ядро.

С уважением, Ильдар

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

_______________________________________________
Sisyphus mailing list
Sisyphus@altlinux.ru
https://lists.altlinux.ru/mailman/listinfo/sisyphus

Re: [sisyphus] Как ускорить работу с потоками?

[Денис Смирнов]

On Tue, Sep 07, 2004 at 07:37:42PM +0400, Boronin Sergey wrote:

 BS> Спасибо, но мне это не подходит, т.к. одним из требований к софту,
 BS> является то, что он (софт) должен нормально работать на нормальных,
 BS> "стандартных" (мейнстримовых) ядрах c kernel.org, RH 7.2+, SUSE 8.x+,
 BS> Mandrake 8.2+, а также на популярных Debian, ALTLinux, ASPLinux.

Думаю что одним из требований к софту должна быть производительность.
Несколько тысяч тредов и производительность несовместимы друг с другам на
x86 с 1-2 процессорами.

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Как ускорить работу с потоками?

[Denis Smirnov]

On Wed, Sep 08, 2004 at 12:39:21PM +0400, Boronin Sergey wrote:

 BS> Смотря чем эти потоки занимаются. На x86 с 1-2 процессорами число
 BS> потоков вряд ли превысит 300, но расчет идет не только на 1-2
 BS> процессорные сервера, а с переходом на ZML и не только на x86, т.е.
 BS> будем двигаться в направлении кластерных
 BS> <http://www.vrg.ru/index.html?url=_1_2_2>  систем.

Ссылочку сейчас посмотреть не могу, но если речь именно о _кластерных_
системах, то причём тут лимит нитей на одной машине? Если NUMA всякая и
прочая многпроцессорная радость, это я ещё хоть как-то понимаю. А в случае
кластеров на MPI смотреть надобно. Обычно если нагрузка создаваемая нитями
более-менее равномерна, то больше нескольких нитей на процессор делать
смысла я не вижу.
 
-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Как ускорить работу с потоками?

[Serge Pavlovsky]

On Втр, 2004-09-07 at 21:36 +0400, Денис Смирнов wrote:
> On Tue, Sep 07, 2004 at 07:37:42PM +0400, Boronin Sergey wrote:
> 
>  BS> Спасибо, но мне это не подходит, т.к. одним из требований к софту,
>  BS> является то, что он (софт) должен нормально работать на нормальных,
>  BS> "стандартных" (мейнстримовых) ядрах c kernel.org, RH 7.2+, SUSE 8.x+,
>  BS> Mandrake 8.2+, а также на популярных Debian, ALTLinux, ASPLinux.
> 
> Думаю что одним из требований к софту должна быть производительность.
> Несколько тысяч тредов и производительность несовместимы друг с другам на
> x86 с 1-2 процессорами.

зря вы fud распространяете. в некоторых случаях и 100 тысяч совместимы.
как всегда, все зависит от применения и прямоты рук ;)

[sisyphus] Re: Как ускорить работу с потоками?

[Денис Смирнов]

On Thu, Sep 09, 2004 at 09:09:17AM +0300, Serge Pavlovsky wrote:

 SP> зря вы fud распространяете. в некоторых случаях и 100 тысяч совместимы.
 SP> как всегда, все зависит от применения и прямоты рук ;)

Я прекрасно знаю, что можно кирпичи возить на множестве велосипедов, но
уверен, что грузовик использовать для этого разумнее.

Если вы приведёте пример, когда на x86 100 тысяч тредов являются
оптимальным решением, я буду вам очень благодарен.

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: Как ускорить работу с потоками?

[Serge Pavlovsky]

On Чтв, 2004-09-09 at 23:07 +0400, Денис Смирнов wrote:
> On Thu, Sep 09, 2004 at 09:09:17AM +0300, Serge Pavlovsky wrote:
> 
>  SP> зря вы fud распространяете. в некоторых случаях и 100 тысяч совместимы.
>  SP> как всегда, все зависит от применения и прямоты рук ;)
> 
> Я прекрасно знаю, что можно кирпичи возить на множестве велосипедов, но
> уверен, что грузовик использовать для этого разумнее.
> 
> Если вы приведёте пример, когда на x86 100 тысяч тредов являются
> оптимальным решением, я буду вам очень благодарен.

если они все спят в чтении из сокетов
можете приводить пример грузовика ;)

[sisyphus] Re: Как ускорить работу с потоками?

[Денис Смирнов]

On Fri, Sep 10, 2004 at 02:51:00AM +0300, Serge Pavlovsky wrote:

 >> Если вы приведёте пример, когда на x86 100 тысяч тредов являются
 >> оптимальным решением, я буду вам очень благодарен.
 SP> если они все спят в чтении из сокетов
 SP> можете приводить пример грузовика ;)

epoll, например :)

select/poll на худой конец.

kevent в FreeBSD.

aio.

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

-- 
С уважением, Денис

http://freesource.info

RE: [sisyphus] Re:Как ускорить работу с потоками?

[Boronin Sergey]

> Я прекрасно знаю, что можно кирпичи возить на множестве велосипедов,
но
> уверен, что грузовик использовать для этого разумнее.
>

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

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

Стало интересно, раз если вы потоки называете велосипедами, то, что же
вы считаете грузовиком?

С уважением,
Боронин Сергей

> -----Original Message-----
> From: sisyphus-bounces@altlinux.ru
[mailto:sisyphus-bounces@altlinux.ru]
> On Behalf Of Денис Смирнов
> Sent: Thursday, September 09, 2004 11:07 PM
> To: Serge Pavlovsky
> Cc: ALT Linux Sisyphus discussion list
> Subject: [sisyphus] Re:Как ускорить работу с потоками?
> 
> On Thu, Sep 09, 2004 at 09:09:17AM +0300, Serge Pavlovsky wrote:
> 
>  SP> зря вы fud распространяете. в некоторых случаях и 100 тысяч
> совместимы.
>  SP> как всегда, все зависит от применения и прямоты рук ;)
> 
> Я прекрасно знаю, что можно кирпичи возить на множестве велосипедов,
но
> уверен, что грузовик использовать для этого разумнее.
> 
> Если вы приведёте пример, когда на x86 100 тысяч тредов являются
> оптимальным решением, я буду вам очень благодарен.
> 
> --
> С уважением, Денис
> 
> http://freesource.info
> 
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@altlinux.ru
> https://lists.altlinux.ru/mailman/listinfo/sisyphus

RE: [sisyphus] Re:Как ускорить работу с потоками?

[Boronin Sergey]

> epoll, например :)
> 
> select/poll на худой конец.
> 
> kevent в FreeBSD.
>

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

Если с помощью fork() то это медленнее, а пулл процессов будет отъедать
немало оперативки (гораздо больше чем потоки в процессах).

Кроме того, потоки удобны тем, что используют единое адресное
пространство,
Что требует конечно известной аккуратности и внимательности, но и
позволяет сделать код проще, логику его работы прозрачнее, да и памяти
по сравнению с fork() ест не в пример меньше.

С уважением,
Боронин Сергей

> -----Original Message-----
> From: sisyphus-bounces@altlinux.ru
[mailto:sisyphus-bounces@altlinux.ru]
> On Behalf Of Денис Смирнов
> Sent: Friday, September 10, 2004 6:55 AM
> To: Serge Pavlovsky
> Cc: ALT Linux Sisyphus discussion list
> Subject: [sisyphus] Re:Как ускорить работу с потоками?
> 
> On Fri, Sep 10, 2004 at 02:51:00AM +0300, Serge Pavlovsky wrote:
> 
>  >> Если вы приведёте пример, когда на x86 100 тысяч тредов являются
>  >> оптимальным решением, я буду вам очень благодарен.
>  SP> если они все спят в чтении из сокетов
>  SP> можете приводить пример грузовика ;)
> 
> epoll, например :)
> 
> select/poll на худой конец.
> 
> kevent в FreeBSD.
> 
> aio.
> 
> Самое разумное -- выносить в отдельные нити _обработку_, а как раз
ждать и
> данными кидаться в небольшом количестве нитей (в несколько раз больше
чем
> количество процессорв, для большей равномерности).
> 
> --
> С уважением, Денис
> 
> http://freesource.info
> 
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@altlinux.ru
> https://lists.altlinux.ru/mailman/listinfo/sisyphus

Re: [sisyphus] Re:Как ускорить работу с потоками?

[Денис Смирнов]

On Fri, Sep 10, 2004 at 02:50:38PM +0400, Boronin Sergey wrote:

 BS> Множество потоков удобны для распараллеливания слабосвязанных между
 BS> собой операций даже в клиентских системах, не говоря уже о серверных.

Опишите мне ситуацию, где нужно несколько сот нитей на x86-машине с одним
процессором. Я не могу себе её представить. 

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

Да ясное дело, что распараллеливать нужно. Только вот процессоров то всё
равно 1-2, а переключение между нитями занимает время. И чем больше нитей,
тем больше времени тратится на переключения вместо работы. Кому это надо?

 BS> Стало интересно, раз если вы потоки называете велосипедами, то, что же
 BS> вы считаете грузовиком?

Зависит от задачи. Для i/o (из-за чего чаще всего пытаются применять
нити, особенно выученые на Windows) они практически не нужны (как я уже
говорил -- нитей чуть боьлше чем процессоров).

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

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re:Как ускорить работу с потоками?

[Денис Смирнов]

On Fri, Sep 10, 2004 at 04:03:49PM +0400, Boronin Sergey wrote:

 BS> А можно в двух словах о концепциях, которые лежат в основе этих
 BS> технологий, т.е. на чем основана их работа и как реализуется
 BS> параллельность выполнения?
 BS> Если с помощью fork() то это медленнее, а пулл процессов будет отъедать
 BS> немало оперативки (гораздо больше чем потоки в процессах).

_Параллельность_ -- никак. Ибо на 1-процессорной машине её быть не может
вообще.

Идея aio -- процесс говорит "читай/пиши вон то во-о-он туда, как выполнишь
скажешь", после чего занимается другими делами (например говорит то же
самое для другого потока данных). Таким образом 1 тред может обрабатывать
очень большое количество одновременных потоков ввода/вывода (что критично,
например, на тех же web-серверах).

 BS> Кроме того, потоки удобны тем, что используют единое адресное
 BS> пространство,
 BS> Что требует конечно известной аккуратности и внимательности, но и
 BS> позволяет сделать код проще, логику его работы прозрачнее, да и памяти
 BS> по сравнению с fork() ест не в пример меньше.

Естественно. У fork() есть только одно преимущество -- изолящия, в том
числе в плане безопасности.

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

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

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: Как ускорить работу с потоками?

[Serge Pavlovsky]

On Птн, 2004-09-10 at 06:54 +0400, Денис Смирнов wrote:
> On Fri, Sep 10, 2004 at 02:51:00AM +0300, Serge Pavlovsky wrote:
> 
>  >> Если вы приведёте пример, когда на x86 100 тысяч тредов являются
>  >> оптимальным решением, я буду вам очень благодарен.
>  SP> если они все спят в чтении из сокетов
>  SP> можете приводить пример грузовика ;)
> 
> epoll, например :)
> 
> select/poll на худой конец.

когда вы в последний раз измеряли производительность epoll/select/poll
на 100к сокетов ?
конечно, epoll быстрее, чем select, но недостаточно

> kevent в FreeBSD.
> 
> aio.

чтобы почаще threads стартовать, чтоли ? ;)

> Самое разумное -- выносить в отдельные нити _обработку_, а как раз ждать и
> данными кидаться в небольшом количестве нитей (в несколько раз больше чем
> количество процессорв, для большей равномерности).

многие весьма неглупые на вид люди тоже так наивно полагают. на самом
деле это получится один в один доморощенная реализация user-level
threads - там тоже один большой select. только вот сложность получается
O(n^2) - чем больше потоков, тем чаще им надо читать * на тем больше
накладных расходов на каждый select. спрашивается, зачем делать самому
userlevel threads и зачем вообще это делать если оно очень быстро
начинает дико тормозить ?

[sisyphus] Re: Как ускорить работу с потоками?

[Денис Смирнов]

On Fri, Sep 10, 2004 at 08:21:34PM +0300, Serge Pavlovsky wrote:
>> epoll, например :)
>> select/poll на худой конец.
 SP> когда вы в последний раз измеряли производительность epoll/select/poll
 SP> на 100к сокетов ?
 SP> конечно, epoll быстрее, чем select, но недостаточно

Я не мерял на 100k сокетов. Поделитель тестовым кодом, если вы меряли?
И думается мне, что на 100k сокетов будет эффективнее всего работать
смешаная модель (epoll + нити).

>> kevent в FreeBSD.
>> aio.
 SP> чтобы почаще threads стартовать, чтоли ? ;)

:-))))

>> Самое разумное -- выносить в отдельные нити _обработку_, а как раз ждать и
>> данными кидаться в небольшом количестве нитей (в несколько раз больше чем
>> количество процессорв, для большей равномерности).
 SP> многие весьма неглупые на вид люди тоже так наивно полагают. на самом
 SP> деле это получится один в один доморощенная реализация user-level
 SP> threads - там тоже один большой select. только вот сложность получается
 SP> O(n^2) - чем больше потоков, тем чаще им надо читать * на тем больше
 SP> накладных расходов на каждый select. спрашивается, зачем делать самому
 SP> userlevel threads и зачем вообще это делать если оно очень быстро
 SP> начинает дико тормозить ?

Причём тут userlevel threads? Видимо вы меня неправильно поняли. Я не
предлагаю городить диспетчер, который бы распихивал по потокам пришедшие
события, боже упаси. Я предлагаю гораздо более тупую (т.е. простую) и
эффектвиную схему: в момент создания соединения сокет привязывается
статически к одной из нитей, и обрабатывается уже только ей. Нити
используем для более эффективного использования нескольких процессоров (да
и одного тоже несколько нитей будут эффективнее использовать) а epoll для
формирования очереди сообщений на обработку.

Ну и на 100k нитей что-то мне не верится что Linux на этом не будет
загибаться.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: Как ускорить работу с потоками?

[Michael Shigorin]

On Sat, Sep 11, 2004 at 01:32:53AM +0400, Денис Смирнов wrote:
> Ну и на 100k нитей что-то мне не верится что Linux на этом не
> будет загибаться.

Тугугл. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: Как ускорить работу с потоками?

[Денис Смирнов]

On Sat, Sep 11, 2004 at 06:20:18PM +0300, Michael Shigorin wrote:

 >> Ну и на 100k нитей что-то мне не верится что Linux на этом не
 >> будет загибаться.
 MS> Тугугл. :)

Э... Что искать? Или ты про NPTL?

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: Как ускорить работу с потоками?

[Serge Pavlovsky]

On Сбт, 2004-09-11 at 01:32 +0400, Денис Смирнов wrote:
> On Fri, Sep 10, 2004 at 08:21:34PM +0300, Serge Pavlovsky wrote:
> >> epoll, например :)
> >> select/poll на худой конец.
>  SP> когда вы в последний раз измеряли производительность epoll/select/poll
>  SP> на 100к сокетов ?
>  SP> конечно, epoll быстрее, чем select, но недостаточно
> 
> Я не мерял на 100k сокетов. Поделитель тестовым кодом, если вы меряли?

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

> И думается мне, что на 100k сокетов будет эффективнее всего работать
> смешаная модель (epoll + нити).

спящие нити при правильном ( О(1) ) шедулере никому не мешают. а epoll -
мешает

> >> Самое разумное -- выносить в отдельные нити _обработку_, а как раз ждать и
> >> данными кидаться в небольшом количестве нитей (в несколько раз больше чем
> >> количество процессорв, для большей равномерности).
>  SP> многие весьма неглупые на вид люди тоже так наивно полагают. на самом
>  SP> деле это получится один в один доморощенная реализация user-level
>  SP> threads - там тоже один большой select. только вот сложность получается
>  SP> O(n^2) - чем больше потоков, тем чаще им надо читать * на тем больше
>  SP> накладных расходов на каждый select. спрашивается, зачем делать самому
>  SP> userlevel threads и зачем вообще это делать если оно очень быстро
>  SP> начинает дико тормозить ?
> 
> Причём тут userlevel threads? Видимо вы меня неправильно поняли. Я не
> предлагаю городить диспетчер, который бы распихивал по потокам пришедшие
> события, боже упаси. Я предлагаю гораздо более тупую (т.е. простую) и
> эффектвиную схему: в момент создания соединения сокет привязывается
> статически к одной из нитей, и обрабатывается уже только ей. Нити
> используем для более эффективного использования нескольких процессоров (да
> и одного тоже несколько нитей будут эффективнее использовать) а epoll для
> формирования очереди сообщений на обработку.

это вы меня не правильно поняли ;)
нету никакой обработки - вся работа с сокетами. прочесть - записать. все
время уходит на poll. зачем же еще тратить время на очередь сообщений ?

userlevel threads, если от них отрезать переключение контекста, как раз
представляют собой генерацию одного большого select на каждый чих вроде
read() или write(). и тормозит как раз это, а не переключение контекста.

> Ну и на 100k нитей что-то мне не верится что Linux на этом не будет
> загибаться.

ну, на нашем ядре/libc - будет. но мы ведь дождемся светлого будущего ;)

[sisyphus] Re: Как ускорить работу с потоками?

[Денис Смирнов]

On Mon, Sep 13, 2004 at 03:19:15AM +0300, Serge Pavlovsky wrote:

 >> Я не мерял на 100k сокетов. Поделитель тестовым кодом, если вы меряли?
 SP> я пробовал реальное приложение. при сотнях штук уже кроме селекта ни на
 SP> что времени не оставалось. и зависимость таки была скорее квадратичная,
 SP> чем линейная.

Можно пример тестового кода? Какое количество дескрипторов передавалось
одному select'у?

 >> И думается мне, что на 100k сокетов будет эффективнее всего работать
 >> смешаная модель (epoll + нити).
 SP> спящие нити при правильном ( О(1) ) шедулере никому не мешают. а epoll -
 SP> мешает

Хм, именно _e_poll? :-(((
То, что poll/select нельзя передавать много дескрипторов я знаю.

А O(1) шедулер вроде только с 2.6 в основной ветке, или в 2.4 тоже есть?

>> Причём тут userlevel threads? Видимо вы меня неправильно поняли. Я не
>> предлагаю городить диспетчер, который бы распихивал по потокам пришедшие
>> события, боже упаси. Я предлагаю гораздо более тупую (т.е. простую) и
>> эффектвиную схему: в момент создания соединения сокет привязывается
>> статически к одной из нитей, и обрабатывается уже только ей. Нити
>> используем для более эффективного использования нескольких процессоров (да
>> и одного тоже несколько нитей будут эффективнее использовать) а epoll для
>> формирования очереди сообщений на обработку.
 SP> это вы меня не правильно поняли ;)
 SP> нету никакой обработки - вся работа с сокетами. прочесть - записать. все
 SP> время уходит на poll. зачем же еще тратить время на очередь сообщений ?

 SP> userlevel threads, если от них отрезать переключение контекста, как раз
 SP> представляют собой генерацию одного большого select на каждый чих вроде
 SP> read() или write(). и тормозит как раз это, а не переключение контекста.

Ясно.

>> Ну и на 100k нитей что-то мне не верится что Linux на этом не будет
>> загибаться.
 SP> ну, на нашем ядре/libc - будет. но мы ведь дождемся светлого будущего ;)

В смысле 2.6+NPTL?

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: Как ускорить работу с потоками?

[Serge Pavlovsky]

On Втр, 2004-09-14 at 00:02 +0400, Денис Смирнов wrote:
> On Mon, Sep 13, 2004 at 03:19:15AM +0300, Serge Pavlovsky wrote:
> 
>  >> Я не мерял на 100k сокетов. Поделитель тестовым кодом, если вы меряли?
>  SP> я пробовал реальное приложение. при сотнях штук уже кроме селекта ни на
>  SP> что времени не оставалось. и зависимость таки была скорее квадратичная,
>  SP> чем линейная.
> 
> Можно пример тестового кода? Какое количество дескрипторов передавалось
> одному select'у?

пример не дам - там все довольно запутанно и вообще не под линух ;), но
вы можете сделать сами, только кто-то должен еще кормить его пакетами

>  >> И думается мне, что на 100k сокетов будет эффективнее всего работать
>  >> смешаная модель (epoll + нити).
>  SP> спящие нити при правильном ( О(1) ) шедулере никому не мешают. а epoll -
>  SP> мешает
> 
> Хм, именно _e_poll? :-(((

ну, там есть два режима вообще. но тот , что быстрее гораздо неудобнее в
использовании и все равно делает лишнюю работу. да, и с портабилити у
него не очень ;)

> То, что poll/select нельзя передавать много дескрипторов я знаю.
> 
> А O(1) шедулер вроде только с 2.6 в основной ветке, или в 2.4 тоже есть?

может, есть патчи. не интересовался

> >> Ну и на 100k нитей что-то мне не верится что Linux на этом не будет
> >> загибаться.
>  SP> ну, на нашем ядре/libc - будет. но мы ведь дождемся светлого будущего ;)
> 
> В смысле 2.6+NPTL?

угу

[sisyphus] Re: Как ускорить работу с потоками?

[Michael Shigorin]

On Mon, Sep 13, 2004 at 12:20:21AM +0400, Денис Смирнов wrote:
>  >> Ну и на 100k нитей что-то мне не верится что Linux на этом не
>  >> будет загибаться.
>  MS> Тугугл. :)
> Э... Что искать? Или ты про NPTL?

100000 threads wakeup time linux nptl или около того,
за прошлый год в lkml.  Кажется.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: Как ускорить работу с потоками?

[Denis Smirnov]

On Tue, Sep 14, 2004 at 09:46:41PM +0300, Michael Shigorin wrote:
>  >>> Ну и на 100k нитей что-то мне не верится что Linux на этом не
>  >>> будет загибаться.
>  MS>> Тугугл. :)
>> Э... Что искать? Или ты про NPTL?
 MS> 100000 threads wakeup time linux nptl или около того,
 MS> за прошлый год в lkml.  Кажется.

Спасибо, гляну.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: Как ускорить работу с потоками?

[Денис Смирнов]

On Tue, Sep 14, 2004 at 03:04:49AM +0300, Serge Pavlovsky wrote:

 >> Можно пример тестового кода? Какое количество дескрипторов передавалось
 >> одному select'у?
 SP> пример не дам - там все довольно запутанно и вообще не под линух ;), но
 SP> вы можете сделать сами, только кто-то должен еще кормить его пакетами

Собственно это одна из причин, почему мне было лень такое делать.

>  >>> И думается мне, что на 100k сокетов будет эффективнее всего работать
>  >>> смешаная модель (epoll + нити).
>  SP>> спящие нити при правильном ( О(1) ) шедулере никому не мешают. а epoll -
>  SP>> мешает
>> Хм, именно _e_poll? :-(((
 SP> ну, там есть два режима вообще. но тот , что быстрее гораздо неудобнее в
 SP> использовании и все равно делает лишнюю работу.

Насколько много лишней работы?
 
 SP> да, и с портабилити у
 SP> него не очень ;)

 :)

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: Как ускорить работу с потоками?

[Serge Pavlovsky]

On Чтв, 2004-09-16 at 01:03 +0400, Денис Смирнов wrote:
> >> Хм, именно _e_poll? :-(((
>  SP> ну, там есть два режима вообще. но тот , что быстрее гораздо неудобнее в
>  SP> использовании и все равно делает лишнюю работу.
> 
> Насколько много лишней работы?

не много, но чтобы появилось желание с ним извращаться, он должен быть
значительно быстрее, а не "примерно такой же"