Сообщение Re[6]: C++20 coroutines (co_await) от 09.01.2021 14:44
Изменено 09.01.2021 14:59 Evgeny.Panasyuk
Re[6]: C++20 coroutines (co_await)
Здравствуйте, landerhigh, Вы писали:
L>Не уверен насчет крутости. Пока сам не использовал всерьез, лишь игрался невсерьез.
L>-Они stackless. Значит, yield'ануть из глубин вложенных вызовов функций не выйдет.
L>+Они stackelss. Значит, оверхед по памяти ограничен и оверхед на переключение контекста должен быть минимальным
L>Этот плюс, имхо, должен перекрывать минус на порядок.
И stackless и stackful хороши по-своему.
Stackful легко реализуются в виде библиотеки — см Boost.Coroutine. А вот stackless в виде библиотеки не очень, и не полноценно — смотри реализацию в Boost.Asio. Поэтому вполне логично добавить stackless в стандарт в первую очередь.
Другое дело что походу то что завезли в стандарт, оно не самое лучше из того что можно было сделать, а конкртено в том месте где они впипдюрили аллоцирование фрейма, которого могло бы не быть, и что открыло бы ещё больше zero-overhead вариантов использования. В частности даже stackless макро-реализация из Boost.Asio обошлась без аллокаций, и такой и должна быть реализация stackless здорового человека, ибо размер фрейма известен во время компиляции. Точно также как и размер замыкания известен во время компиляции, и мы мыжем просто сохранить всё замыкание через автоматический вывод типа.
L>Не уверен насчет крутости. Пока сам не использовал всерьез, лишь игрался невсерьез.
L>-Они stackless. Значит, yield'ануть из глубин вложенных вызовов функций не выйдет.
L>+Они stackelss. Значит, оверхед по памяти ограничен и оверхед на переключение контекста должен быть минимальным
L>Этот плюс, имхо, должен перекрывать минус на порядок.
И stackless и stackful хороши по-своему.
Stackful легко реализуются в виде библиотеки — см Boost.Coroutine. А вот stackless в виде библиотеки не очень, и не полноценно — смотри реализацию в Boost.Asio. Поэтому вполне логично добавить stackless в стандарт в первую очередь.
Другое дело что походу то что завезли в стандарт, оно не самое лучше из того что можно было сделать, а конкртено в том месте где они впипдюрили аллоцирование фрейма, которого могло бы не быть, и что открыло бы ещё больше zero-overhead вариантов использования. В частности даже stackless макро-реализация из Boost.Asio обошлась без аллокаций, и такой и должна быть реализация stackless здорового человека, ибо размер фрейма известен во время компиляции. Точно также как и размер замыкания известен во время компиляции, и мы мыжем просто сохранить всё замыкание через автоматический вывод типа.
Re[6]: C++20 coroutines (co_await)
Здравствуйте, landerhigh, Вы писали:
L>Не уверен насчет крутости. Пока сам не использовал всерьез, лишь игрался невсерьез.
L>-Они stackless. Значит, yield'ануть из глубин вложенных вызовов функций не выйдет.
L>+Они stackelss. Значит, оверхед по памяти ограничен и оверхед на переключение контекста должен быть минимальным
L>Этот плюс, имхо, должен перекрывать минус на порядок.
И stackless и stackful хороши по-своему.
Stackful легко реализуются в виде библиотеки — см Boost.Coroutine. А вот stackless в виде библиотеки не очень, и не полноценно — смотри реализацию в Boost.Asio. Поэтому вполне логично добавить stackless в стандарт в первую очередь.
Другое дело что походу то что завезли в стандарт, оно не самое лучше из того что можно было сделать, а конкртено в том месте где они впипдюрили аллоцирование фрейма, которого могло бы не быть, и что открыло бы ещё больше zero-overhead вариантов использования. В частности даже stackless макро-реализация из Boost.Asio обошлась без аллокаций, и такой и должна быть реализация stackless здорового человека, ибо размер фрейма известен во время компиляции.
Точно также как и размер замыкания известен во время компиляции, и мы мыжем просто сохранить всё замыкание через автоматический вывод типа. Представь что вместо конкретного типа замыкания мы бы всегда получали std::function
L>Не уверен насчет крутости. Пока сам не использовал всерьез, лишь игрался невсерьез.
L>-Они stackless. Значит, yield'ануть из глубин вложенных вызовов функций не выйдет.
L>+Они stackelss. Значит, оверхед по памяти ограничен и оверхед на переключение контекста должен быть минимальным
L>Этот плюс, имхо, должен перекрывать минус на порядок.
И stackless и stackful хороши по-своему.
Stackful легко реализуются в виде библиотеки — см Boost.Coroutine. А вот stackless в виде библиотеки не очень, и не полноценно — смотри реализацию в Boost.Asio. Поэтому вполне логично добавить stackless в стандарт в первую очередь.
Другое дело что походу то что завезли в стандарт, оно не самое лучше из того что можно было сделать, а конкртено в том месте где они впипдюрили аллоцирование фрейма, которого могло бы не быть, и что открыло бы ещё больше zero-overhead вариантов использования. В частности даже stackless макро-реализация из Boost.Asio обошлась без аллокаций, и такой и должна быть реализация stackless здорового человека, ибо размер фрейма известен во время компиляции.
Точно также как и размер замыкания известен во время компиляции, и мы мыжем просто сохранить всё замыкание через автоматический вывод типа. Представь что вместо конкретного типа замыкания мы бы всегда получали std::function