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

["Денис Смирнов" <mithraen@freesource.info>]

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