Снова об асинхронности (concurrency) и параллемизме

Ты имеешь ввиду всякие gevent? АФАИК там такой же event loop как и в asyncio, просто как бы спрятанный от тебя. А на си это всё сводится к какому-нить epoll и циклу.

Не думаю что там какие-то серьезные накладные расходы.

Годное видео частично в тему https://www.youtube.com/watch?v=MCs5OvhV9S4 если кто не видел.

Очень хорошее введение в тему https://pypkg.com/pypi/pytgram/f/tests/files/test.pdf

ядра конкретной ОС

нет, зеленые потоки работают не на уровне ядра.

есть ли накладные расходы (overhead) от использования «зеленых потоков» со стороны как ВМ

есть конечно, но при правильной реализации небольшие. Просто указатель переключается с одной структуры на другую. Этим занимается планировщик, который переключает структуры в рабочих потоках. Сложно сделать сам планировщик и его инфраструктуру- он может переключать по добровольному yield от задач, может переключатьп о редукциям, чтобы избежать блокировки (при этом надо считать редукции всех операций), может переключать при i/o и так далее. Обычно присутствует комбинация нескольких вариантов.

О, спасибо. Пригодится.

Спасибо, это именно то, о чем я спрашивал.

потоки работают не на уровне ядра

Это понятно, просто, как я думаю, в зависимости от конкретной ОС будет отличаться реализация этого самого планировщика, не?

В зависимости от ОС будет отличаться работа рабочих потоков, в контексте которых выполняются зеленые потоки. Наверно можно сделать такую ОС, которая возьмет на себя часть работы, но по моему во всех основных ОС реализация плюс-минус одинаковая, за исключением использованных стандартных функций ядра.

в зависимости от конкретной ОС будет отличаться реализация этого самого планировщика, не?

Конечно, будет отличаться. Вот, например, в доке по асинкио указано какие системные вызовы используются в разных ОС - https://docs.python.org/3/library/asyncio-eventloops.html#available-event-loops

Есть, кстати еще uvloop, бенчмарки у него очень неплохие, я сам правда не мерял еще. https://github.com/MagicStack/uvloop

Кстати, про «не на уровне ядра» тоже не совсем правильно. Поллеры как раз на уровне ядра и работают. Просто в случае с «зелеными» потоками ты код пишешь не с колбеками, как в торнадо/javascript, а в псевдо-последовательном стиле с async/await.

И его тоже.

В общем идею понял.

Спасибо.

колбеками, как в торнадо

ээ там корутины давно http://www.tornadoweb.org/en/stable/guide/coroutines.html yield или async/await.

Тут тип не плохую вводную даёт.

Это про другое же.

В первой или во второй лекции есть обсуждение гринтредов. Но ежели tl;dr, то гринтреды, несмотря на накладные расходы, могут оказываться производительней чем классические, но накладывают ряд ограничений по дизайну. Есть ещё риалтайм системы, где ты условно должен yield дёрнуть или всё встанет. Ещё в современных операционных системах от Таненбаума тема более менее раскрыта в первых главах.

Так ведь кмк у гринтредов накладных расходов меньше, чем у классических? Или нет?

Гринтреды всё равно будут работать поверх классических, во всех не рт системах.

Основной плюшкой гринтредов считается минимизация переключений контекста, которые впрочем, уже не столь дороги как десять лет назад. Я глубоко тему не копал, но из того что попадалось на глаза, гринтреды делаются что бы сделать подобие рт в рамках своего приложения, т.е. что бы о планировании знал больше клиентский код чем код ядра системы (в смысле планировщик).

Например, если отжать под такое приложения у системы n ядер, то переключений конеткста не будет. Я видел самопальную реализацию такого рт (правда грин тредами в чистом виде его сложно назвать), там ребята на одном ядре(тогда это был топовый десктоп) успевали почитать ипкамеру с fps >= 30 в разрешении 1024x768, наложить на это изображения эффекты уровня fisheye, zoom и т.п., нарисовать это и обработать сообщения gui потока. Но код сей страшен как ночь.

минимизация переключений контекста

Ну да.

которые впрочем, уже не столь дороги как десять лет назад.

А если у тебя очень-очень дохрена таких тредов? В этом и фишка кмк.

Соль в том, что по сути гринтреды экономят только переключения в защищёный режим при сохранении почти той же функциональности. Т.е. переключение контекста между потоками, при условии что у тебя всё в честных корутинах со своим стеком распиханно, будут стоить дешевле на эту величину.

Вот если ты от куска функциональности откажешься (например от автоматического преключения стека), возможно получить заметный прирост. Иначе, если речь об онотопике например, проще затюнить ядро и настроить аффинити, результат если и будет отличаться, то надо будет очень постараться что бы это заметить, при этом планировщик(который будет априори не в курсе про I/o) должен быть написан не хуже чем в ядре. При этом при всё у тебя остаётся pthread_yield, который как бы позволяет ещё и попинать планировщик из вне.

Про память отдельный разговор. Есть ещё ненулевой шанс густо сэкономить на том, что кэш будет реже переписываться.

https://lwn.net/Articles/256433/
Вот это важнее знать наизусть, как и всю книгу. Особенно наизусть заучить про стоимость реального переключения контекста на CPU.

Из-за ценника, на стороне среды исполнения обычно пул из готовых потоков обслуживает работу многопоточного приложения, принимая на вход задачи и раскидывая их по свободным потокам из пула.

Очевидно, при прямых руках, ~неблокирующем коде и асинхронном I/O (где возможно) легко достичь оптимального размера пула потоков == кол-ву CPU в системе, вешая немногочисленные слишком блокирующие операции на отдельный пул потоков.

Спасибо, полезно.

Кстати, да совсем забыл о ней.

Полезное чтиво, во многом информативнее того же Таненбаума.