АО
ещё есть пара проблем: это JVM ограничения (заблокировали поток - получили копец на корутине), то есть с некоторыми подходами/библиотеками корутины просто несовместимы
Size: a a a
2020 November 09
АО
в остальном корутины сильно лучше каких-нибудь тредов
AE
в остальном корутины сильно лучше каких-нибудь тредов
ну в случае чистых вычислений таки треды будут лучше
с#
ну в случае чистых вычислений таки треды будут лучше
io диспетчер выполняет корутины на тредах
KG
Только за счет тулинга
Хм, и правда.
Ну тогда да, когда появится другая реализация зелёных тредов со structured concurrency, и не требующая аж поддержки компилятора - да, в топку. А пока я не знаю альтернативы корутинам в этом плане
Ну тогда да, когда появится другая реализация зелёных тредов со structured concurrency, и не требующая аж поддержки компилятора - да, в топку. А пока я не знаю альтернативы корутинам в этом плане
AN
ну в случае чистых вычислений таки треды будут лучше
На самом деле без разницы. Оверхед на корутину очень маленький. Она под капотом тот же тред займет. Я мерил
AN
io диспетчер выполняет корутины на тредах
+
с#
ну в случае чистых вычислений таки треды будут лучше
треды будут эффективные только потому что вычисления блокирующие
AN
треды будут эффективные только потому что вычисления блокирующие
даже в этом случае без разницы, если это IO
с#
да, я как раз про это, потому что там даже если корутина заблокировалась, то там мультипоток
AE
На самом деле без разницы. Оверхед на корутину очень маленький. Она под капотом тот же тред займет. Я мерил
да, маленький. только пул потоков надо выделить по-больше, а не по конкурентности цп
АО
ну в случае чистых вычислений таки треды будут лучше
Не всегда, если вычисления маленькие - да, если большие - разница будет не такая большая
KG
да, я как раз про это, потому что там даже если корутина заблокировалась, то там мультипоток
Ничего не понял, но очень интересно (правда интересно). Что вы имеет в виду под "мультипоток"?
AE
треды будут эффективные только потому что вычисления блокирующие
вычисления ничего не блокируют, они просто занимают ресурс процессора. проблема блокировок именно в том, что при блокировках рессурс процессора простаивает
АО
ну в случае чистых вычислений таки треды будут лучше
Без suspend точек производительность корутины == производительности треда, на которой она работает. Там затраты будут не первое и последнее переключение контекстов (если они есть) + внутренние операции по передачи значений на выход
AE
Не всегда, если вычисления маленькие - да, если большие - разница будет не такая большая
да
с#
Ничего не понял, но очень интересно (правда интересно). Что вы имеет в виду под "мультипоток"?
проблема блокирующих операций в том, что корутина дальше не пойдет, пока операция не выполнится. поэтому либо делить операцию на сиквенсы делать суспенд функции, чем занимаются библиотеки (в случае с интернет-запросами), либо выполнять в IO, который корутины не в одном потоке выполняет
AN
Короче, резюмирую. Аппарат корутин можно использовать для управления потоками, не используя CPS и это тоже удобно. Но в случае с тяжелыми блокирующими операциями, разницы по сравнению с прямым использованием потоков не будет
KG
да, маленький. только пул потоков надо выделить по-больше, а не по конкурентности цп
Сильно больше цп не надо по идее. Там же фишка в work stealing, так? Т. е. даже если будет много IO, то достаточно нескольких тредов в отдельном диспетчере, чтобы дожидались завершения IO, а для вычислительной части 2 х кол-во ядер потоков в пуле достаточно должно быть
АО
Сильно больше цп не надо по идее. Там же фишка в work stealing, так? Т. е. даже если будет много IO, то достаточно нескольких тредов в отдельном диспетчере, чтобы дожидались завершения IO, а для вычислительной части 2 х кол-во ядер потоков в пуле достаточно должно быть
нет, так уж исторически сложилось,Ю что чтобы дождаться ответа из сокета/от системы/etc., нужно залочить поток до получения собственно ответа