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

[Анатолий Гришаев]

10.02.2015 5:27, 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) В асинхронной программе не нужны средства синхронизации потоков(Из-за
>> многопоточности), которые просто необходимы в потоках.
>> Накладные расходы на синхронизацию не ускоряют поточные программы и иногда
>> могут быть просто чудовищными.
> Все мы работаем с базами данных, каман.
> Ну - те из нас, кто работает.
Во первых не все, и не всегда. Можно пользоваться redis и memcached и не 
думать о базах данных.
А иногда бывает полезно иметь общий пул данных
> Так вот, те, кто работают с базами данных, знают слова вроде
> "оптимистичная блокировка", "MVCC".
> Есть еще такая вещь, как STM.
Опять не все, и не всегда.
Даже если блокировка самая быстрая, это не значит что на неё не 
используются ресурсы процессора вообще.
А поход в базу данных это совсем не дешевая альтернатива.

>
>> 100-200 циклов процессора минимум на одном примитиве.
> compare-and-swap это 100-200 циклов процессора минимум?
> Но на что? O_O
А вы читали Intel Design Manual для IE-32 и IE-64? А про POSIX ? А про 
примитивы синхронизации, как они устроены?
А про spin lock, что вам известно?
Почитайте, погуглите.
Может оказаться, что на CAS 100-200 циклов и уходит.
А одной блокировкой как правило, дело обычно не заканчивается.

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