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

[Alex Chistyakov]

2015-02-09 11:57 GMT+03:00 Анатолий Гришаев <0body0 на rambler.ru>:
> 09.02.2015 11:01, Daniel Podolsky пишет:
>
>>> 1) было исследование программ на C, которое показывало, асинхронный код
>>> не
>>> проигрывает тредовому, и довольно
>>> часто при большой нагрузке оказывается быстрее. ( Кажется это была
>>> толстая
>>> зеленая книга)
>>> 2) За исключением патологических случаем fork по скорости сравним с
>>> threads.
>>> 3) Писать и отлаживать на AnyEvent + fork намного проще, чем на threads.
>>>
>>> Т.е. threads --- это технологический тупик.
>>> И если он есть это наверно хорошо, но лучше им не пользоваться.
>>> Выгоды от него ограниченные, а гемороя можно получить в разы больше.
>>
>> А приведите, пожалуйста, хотя бы по паре аргументов в поддержку этих
>> тезисов :)
>
>
> 1) Создание потоков и процессом в Линуксе делается одним вызовом (clone)
> разница только в копировании адресного пространства при создании процесса,
> а внутри они ничем не различаются, кроме адресного пространства.
> Если процесс поток/процесс живет довольно долго, то разницу в накладных
> расходов при создании процесса можно пренебречь
> 2) При большом количестве потоков у ядра вырастают накладные расходы на
> переключение потоков.
> В случае большой нагрузки вообще говоря количество потоков
> вырастает(threads), а в случае асинхронной программы это количесто не
> меняется, поэтому
> асинхронная модель будет выигрывать за счет накладных расходов ядра системы.
> 3) Асинхронная программа это однопоточная программа. А поскольку отлаживать
> однопоточную программу проще чем многопоточную, то
> и отлаживать асинхронную программу легче, чем программу с потоками.

Это утверждение вопиюще неверно.

> 4) В асинхронной программе не нужны средства синхронизации потоков(Из-за
> многопоточности), которые просто необходимы в потоках.
> Накладные расходы на синхронизацию не ускоряют поточные программы и иногда
> могут быть просто чудовищными.

Все мы работаем с базами данных, каман.
Ну - те из нас, кто работает.
Так вот, те, кто работают с базами данных, знают слова вроде
"оптимистичная блокировка", "MVCC".
Есть еще такая вещь, как STM.

> 100-200 циклов процессора минимум на одном примитиве.

compare-and-swap это 100-200 циклов процессора минимум?
Но на что? O_O

--
SY,
Alex


>
> Слегка не в тему, но для полноты
> 5) forkи  проще концептуально и приводят к меньшему количеству ошибок в
> программировании, значит отлаживать будет меньше.
>
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org