Где-нибудь можно найти информацию, почему переключение контекста (уровня ОС) такое дорогое? Вот на 5:53, например, написано total costs, including cache invalidation? Какие кеши инвалидируются? В современных процессорах physically-tagged кеши (VIPT или PIPT), их не надо инвалидировать при переключении контекста. TLB для переключения на тред того же процесса инвалидировать не надо, и вообще современные TLB поддерживают теги адресных пространств. У меня ощущение, что для человека "со стороны", который не разрабатывает процессоры или операционные системы, во всем Интернете невозможно найти нормальный ответ на вопрос "зачем нужен user-space scheduling" (корутины, файберы, горутины, или что там в вашей среде есть). В худшем случае будет бредятина про то, что стеки ОС-тредов занимают слишком много памяти (ну да, ведь 2^64 байт - это так мало для масштабируемости), а в лучшем - про инвалидацию кешей.
я думаю, что главная здесь проблема это race condition или ты сам управляешь переключением в "безопасные" и понятные моменты времени или это делает операционная система (например, посредине инкремента целого числа, который выполняется в две машинные инструкции)
стекфул ничем не отличается от классического кода со стеком стеклесс код хранит все "локальные" переменные не на стеке, а в специально отведенном регионе памяти (который обычно располагают в куче) главное преимущество такого подхода -- расход памяти ты должен выделить ровно столько памяти, сколько реально надо для работы конкретной корутины в случае классического стека ты всегда выделяешь на глазок и делаешь это с запасом, что приводит к перерасходу памяти недостатоки стеклесс -- необходимость отмечать все корутины специальным образом и невозможность их использования как обычных методов плюс современные компиляторы, увы, не могут предсказать размер региона под переменные на этапе компиляции и память нужно выделять каким-то образом в рантайме
не самый хороший доклад с точки зрения формулирования мыслей и использования терминологии для тех, кто плохо разбирается в теме, может скорее сбить с толка, чем что-то прояснить корутины (особенно stackful) это нифига не колбэки это потоки выполнения, похожие на threads, а корутинный движок это их шедулер
![Как устроены швейные машинки? [Veritasium]](http://i.ytimg.com/vi/FFW0GcMCgd0/mqdefault.jpg)
![Как устроены швейные машинки? [Veritasium]](/img/tr.png)
Спасибо!
Спасибо за видео.Коммент в поддержку!
А что под капотом у стакфулл короутин? Каким образом получается сохранить локальные переменные в процедуре?
Где-нибудь можно найти информацию, почему переключение контекста (уровня ОС) такое дорогое? Вот на 5:53, например, написано total costs, including cache invalidation? Какие кеши инвалидируются? В современных процессорах physically-tagged кеши (VIPT или PIPT), их не надо инвалидировать при переключении контекста. TLB для переключения на тред того же процесса инвалидировать не надо, и вообще современные TLB поддерживают теги адресных пространств. У меня ощущение, что для человека "со стороны", который не разрабатывает процессоры или операционные системы, во всем Интернете невозможно найти нормальный ответ на вопрос "зачем нужен user-space scheduling" (корутины, файберы, горутины, или что там в вашей среде есть). В худшем случае будет бредятина про то, что стеки ОС-тредов занимают слишком много памяти (ну да, ведь 2^64 байт - это так мало для масштабируемости), а в лучшем - про инвалидацию кешей.
я думаю, что главная здесь проблема это race condition
или ты сам управляешь переключением в "безопасные" и понятные моменты времени или это делает операционная система (например, посредине инкремента целого числа, который выполняется в две машинные инструкции)
Создание потока на питоне - не проблема. Проблема в том, что потоки не будут работать параллельно.
Смотря какой движок питона использовать) есть реализации без GIL, но тогда придется писать tread-safe код)
@@jekapsk по умолчанию все понимают о каком движке речь)
А так конечно, можно пытаться и мертвого воскрешать
объясните стекфул vs стеклесс корутины?
стекфул ничем не отличается от классического кода со стеком
стеклесс код хранит все "локальные" переменные не на стеке, а в специально отведенном регионе памяти (который обычно располагают в куче)
главное преимущество такого подхода -- расход памяти
ты должен выделить ровно столько памяти, сколько реально надо для работы конкретной корутины
в случае классического стека ты всегда выделяешь на глазок и делаешь это с запасом, что приводит к перерасходу памяти
недостатоки стеклесс -- необходимость отмечать все корутины специальным образом и невозможность их использования как обычных методов
плюс современные компиляторы, увы, не могут предсказать размер региона под переменные на этапе компиляции и память нужно выделять каким-то образом в рантайме
Все видео было ощущение , что лектор говорить про шедуллер Go)
Ну это одна и так же идея.
не самый хороший доклад с точки зрения формулирования мыслей и использования терминологии
для тех, кто плохо разбирается в теме, может скорее сбить с толка, чем что-то прояснить
корутины (особенно stackful) это нифига не колбэки
это потоки выполнения, похожие на threads, а корутинный движок это их шедулер
Спасибо!