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) В асинхронной программе не нужны средства синхронизации потоков(Из-за > многопоточности), которые просто необходимы в потоках. > Накладные расходы на синхронизацию не ускоряют поточные программы и иногда > могут быть просто чудовищными. Все мы работаем с базами данных, каман. Ну - те из нас, кто работает. Так вот, те, кто работают с базами данных, знают слова вроде "оптимистичная блокировка", "MVCC". Есть еще такая вещь, как STM. > 100-200 циклов процессора минимум на одном примитиве. compare-and-swap это 100-200 циклов процессора минимум? Но на что? O_O -- SY, Alex > > Слегка не в тему, но для полноты > 5) forkи проще концептуально и приводят к меньшему количеству ошибок в > программировании, значит отлаживать будет меньше. > > > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
