On Monday, February 09, 2015 11:57:58 Анатолий Гришаев wrote: > 2) При большом количестве потоков у ядра вырастают накладные расходы на > переключение потоков. > В случае большой нагрузки вообще говоря количество потоков > вырастает(threads), а в случае асинхронной программы это количесто не > меняется, поэтому > асинхронная модель будет выигрывать за счет накладных расходов ядра системы.
Считается, что потоки программы, завязанные на сетевой IO, по большей части мирно спят. А зачем ядру будить спящие потоки? Поэтому, я бы хотел услышать доказательства этого тезиса. Ну, типа: "было исследование, вот ссылка"... Каждый тред -- отдельный стек. Сколько дадим? Допустим, 64кб. 10 тыс тредов, это 640мб стека. Не так уж и много. Время на сканирование очереди из 10к тредов чтобы передать управление -- только те, что не спят, а по статистике, работает одновременно всего 3-5%% соединений, это 500 тредов максимум. Современному процессору это раз плюнуть. Самое неприятное в переключении контекстов -- сброс кешей, но в серверные процессоры их не просто так по много мегабайт ставят. Вобщем, несмотря на то, что асинхронная модель не требует отдельных контекстов, стеков и прочего, треды не так уж безнадёжны. Самый главный минус тредов -- их нет в перле. На этом можно про них и закончить. > 3) Асинхронная программа это однопоточная программа. А поскольку > отлаживать однопоточную программу проще чем многопоточную, то > и отлаживать асинхронную программу легче, чем программу с потоками. Кроме логов я способа отладки не знаю. В этом случае мне всё равно что там с потоками. > 4) В асинхронной программе не нужны средства синхронизации потоков(Из-за > многопоточности), которые просто необходимы в потоках. Ах, если бы. Дайте мне, пожалуйста, _нормальное_ средство синхронизации между процессами, простого мьютекса мне было б уже достаточно. А то в итоге лок- менеджеры или прости господи файловые локи приходится делать... > Накладные расходы на синхронизацию не ускоряют поточные программы и > иногда могут быть просто чудовищными. > 100-200 циклов процессора минимум на одном примитиве. Уж лучше синхронизировать доступ, чем удивляться некорректному поведению. > Слегка не в тему, но для полноты > 5) forkи проще концептуально и приводят к меньшему количеству ошибок в > программировании, значит отлаживать будет меньше. Это просто синхронное программирование проще. Как раз параллелизация на форках уже заметно сложнее. -- PEF Developer -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
