История изменений
Исправление
sf,
(текущая версия)
:
> Быстрее родных работать могут, для I/O костылей требовать не обязательно (хватит только на I/O апгрейдить green thread до OS thread).
Если зеленые потоки не блокируются (например, ожидая i/o), то работать быстрее нативных они не могут, потому что, в отличие от нативных, часть своего слайса тратят на переключение между зелеными потоками, при этом дополнительного процессорного времени не получают. Т.е. нинужно.
Если состояния блокирования нет (100% CPU load), то идеальный случай производительности - это когда на каждом ядре процессора крутится ровно 1 OS thread, а в нем ровно 1 green thread. Идеальная загрузка CPU с минимальным временем переключения контекстов зеленых потоков.
В модели с OS-only threads караулить число активных OS threads надо делать вручную.
А если зеленые потоки блокируются, то их приходится реализовывать как обертку над нативным потоком, т.е. снова нинужно.
Апгрейдятся до IO thread только те green threads, что неизбежно блокируются/виснут на долгое время (а избежать сравнительно легко). Остальные продолжают наиболее эффективно жрать CPU/IO.
Единственное вменяемое применение, которое тут предложили, это обертка для сокрытия асинхронного i/o от говнокодера. Но и это выглядит как сомнительный профит.
Каноничным примером проблемы с мультиплексированием IO является пример из 'man select_tut' (второй пример, с сокетами): http://linux.die.net/man/2/select_tut.
Если переписать его на потоки (OS threads) ни красивее, ни быстрее не станет.
До сих пор сомнительный? :]
UPD: уточнил на какие потоки
Исходная версия
sf,
:
> Быстрее родных работать могут, для I/O костылей требовать не обязательно (хватит только на I/O апгрейдить green thread до OS thread).
Если зеленые потоки не блокируются (например, ожидая i/o), то работать быстрее нативных они не могут, потому что, в отличие от нативных, часть своего слайса тратят на переключение между зелеными потоками, при этом дополнительного процессорного времени не получают. Т.е. нинужно.
Если состояния блокирования нет (100% CPU load), то идеальный случай производительности - это когда на каждом ядре процессора крутится ровно 1 OS thread, а в нем ровно 1 green thread. Идеальная загрузка CPU с минимальным временем переключения контекстов зеленых потоков.
В модели с OS-only threads караулить число активных OS threads надо делать вручную.
А если зеленые потоки блокируются, то их приходится реализовывать как обертку над нативным потоком, т.е. снова нинужно.
Апгрейдятся до IO thread только те green threads, что неизбежно блокируются/виснут на долгое время (а избежать сравнительно легко). Остальные продолжают наиболее эффективно жрать CPU/IO.
Единственное вменяемое применение, которое тут предложили, это обертка для сокрытия асинхронного i/o от говнокодера. Но и это выглядит как сомнительный профит.
Каноничным примером проблемы с мультиплексированием IO является пример из 'man select_tut' (второй пример, с сокетами): http://linux.die.net/man/2/select_tut.
Если переписать его на потоки ни красивее, ни быстрее не станет.
До сих пор сомнительный? :]