[Moscow.pm] Темы для докладов

Анатолий Гришаев 0body0 на rambler.ru
Пн Фев 9 00:57:58 PST 2015


09.02.2015 11:01, Daniel Podolsky пишет:
>> 1) было исследование программ на C, которое показывало, асинхронный код не
>> проигрывает тредовому, и довольно
>> часто при большой нагрузке оказывается быстрее. ( Кажется это была толстая
>> зеленая книга)
>> 2) За исключением патологических случаем fork по скорости сравним с threads.
>> 3) Писать и отлаживать на AnyEvent + fork намного проще, чем на threads.
>>
>> Т.е. threads --- это технологический тупик.
>> И если он есть это наверно хорошо, но лучше им не пользоваться.
>> Выгоды от него ограниченные, а гемороя можно получить в разы больше.
> А приведите, пожалуйста, хотя бы по паре аргументов в поддержку этих тезисов :)

1) Создание потоков и процессом в Линуксе делается одним вызовом (clone) 
разница только в копировании адресного пространства при создании процесса,
а внутри они ничем не различаются, кроме адресного пространства.
Если процесс поток/процесс живет довольно долго, то разницу в накладных 
расходов при создании процесса можно пренебречь
2) При большом количестве потоков у ядра вырастают накладные расходы на 
переключение потоков.
В случае большой нагрузки вообще говоря количество потоков 
вырастает(threads), а в случае асинхронной программы это количесто не 
меняется, поэтому
асинхронная модель будет выигрывать за счет накладных расходов ядра системы.
3) Асинхронная программа это однопоточная программа. А поскольку 
отлаживать однопоточную программу проще чем многопоточную, то
и отлаживать асинхронную программу легче, чем программу с потоками.
4) В асинхронной программе не нужны средства синхронизации потоков(Из-за 
многопоточности), которые просто необходимы в потоках.
Накладные расходы на синхронизацию не ускоряют поточные программы и 
иногда могут быть просто чудовищными.
100-200 циклов процессора минимум на одном примитиве.

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





Подробная информация о списке рассылки Moscow-pm