2015-02-10 9:35 GMT+03:00 Анатолий Гришаев <[email protected]>: > 10.02.2015 5:27, Alex Chistyakov пишет: > >> 2015-02-09 11:57 GMT+03:00 Анатолий Гришаев <[email protected]>: >>> >>> 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 >>> [email protected] | http://moscow.pm.org > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
