статье: thread::yield работает медленнее чем сохранение / восстановление контекста корутины.
Вы ведь наверняка не ввязались в корутины потому что модно, иначе бы на Go писали :))
Чисто в теории для меня поток и корутина отличаются только тем, что корутины не имеют thread local storage, поэтому не надо о нем думать. Ну и то, что у шедулера потоков чуть меньше объектов для обработки. Но зато у шедулера корутин больше (при этом первый работает на уровне ОС и я ему бы доверял больше). Остальные операции типа как сохранить регистры и стек общие для потоков и корутин. Откуда тогда профит?
1. сохранять нужно только регистры, которые нужно сохранять при вызове функции (то есть гораздо меньше, чем при смене потока) 2. не надо уходить ядро может быть, еще что-то есть
переключение потока это сохранение/загрузка нескольких мегабайт данных. stackful корутины - килобайт. stackless - 1-2 указателей. Как думаешь, как соотносится быстродействие этих операций? )
Создавать корутины намного дешевле чем потоки Скорость переключения корутины vs переключения потока можно как раз прикинуть, сравнив производительности thread::yield. При этом thread::yield - хитрый системный вызов, у него есть hot path который почти ничего не делает. С ним и соревнуемся. Другие вызовы будут дороже (ну кроме хитрых вызовов через vdso). Учтите, что в последнее время переключение в режим ядра становится только дороже из-за уязвимостей процессоров.
Обсуждают сегодня