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 и не
думать о базах данных.
А иногда бывает полезно иметь общий пул данных
Так вот, те, кто работают с базами данных, знают слова вроде
"оптимистичная блокировка", "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
[email protected] | http://moscow.pm.org
--
Moscow.pm mailing list
[email protected] | http://moscow.pm.org
