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

[PEF Secure]

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