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

[Alex Chistyakov]

2015-02-10 9:35 GMT+03:00 Анатолий Гришаев <0body0 на rambler.ru>:
> 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 и не
> думать о базах данных.

А у memcached внутри не MVCC? O_O

> А иногда бывает полезно иметь общий пул данных
>>
>> Так вот, те, кто работают с базами данных, знают слова вроде
>> "оптимистичная блокировка", "MVCC".
>> Есть еще такая вещь, как STM.
>
> Опять не все, и не всегда.

Да я уже понял, что не все и не всегда.

> Даже если блокировка самая быстрая, это не значит что на неё не используются
> ресурсы процессора вообще.

Где я это утверждал?

> А поход в базу данных это совсем не дешевая альтернатива.

Где я говорил, что это альтернатива?

>
>>
>>> 100-200 циклов процессора минимум на одном примитиве.
>>
>> compare-and-swap это 100-200 циклов процессора минимум?
>> Но на что? O_O
>
> А вы читали Intel Design Manual для IE-32 и IE-64?

А Вы читали Orange Book?

> А про POSIX ? А про
> примитивы синхронизации, как они устроены?

Да не - ну куда мне?

> А про spin lock, что вам известно?

А какая связь между spinlock и CAS?

> Почитайте, погуглите.
> Может оказаться, что на CAS 100-200 циклов и уходит.

Мне интересно другое - с чего Вы вообще про эти 100-200 циклов речь завели?
У Вас что, профайлер в это место в коде показал, или что?
Или Вам жалко эти 100-200 циклов?
Ну вот же все на поверхности лежит:
http://stackoverflow.com/questions/2972389/why-is-compareandswap-instruction-considered-expensive
Какие спинлоки, какой позикс, какой интел дизайн?
Где факты, где основания, где показания профайлера?
А то то, что для одного expensive, для другого может быть не expensive
- тут вон учаснеги на динамически типизированном языке годами пишут, и
норм им.

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