👀 Аж в феврале вышло 1 превью .NET 11, ровно тогда же я почитал релиз ноты и захотел написать пост... долго же я собирался. Что же меня так зацепило? Оптимизация асинхронной модели, хотя это не единственная интересная фича, про нее и будет этот вводный пост
🤯 Издревле (.NET Framework 4.5 – 2012 год) так сложилось, что механизм асинхронности в C# реализован через явную пометку пользователем цвета функций – через ключевое слово async, и такое же явное обозначение точки приостановки (suspension) – через ключевое слово await. Многими даже считается, что именно C# стал основным популяризатором такого подхода в свое время.
🚀 Тем не менее время шло, и в новых языках – необремененных еще необходимостью поддерживать обратную совместимость с 100500 предыдущими версиями – стали появляться более эффективные, но менее гибкие подходы. Главным контрпримером обычно выступает Go с легковесными потоками, которые планируются рантаймом поверх обычных тредов операционной системы. При таком подходе программист может не задумываться о всем вышеперечисленном, вплоть до полного непонимания что такое асинхронность. Сравнивать эти модели с точки зрения удобства и гибкости сейчас не будем – это тема как минимум отдельного поста (ставьте классы)
😭 А вот с точки зрения стоимости исполнения у C# есть проблемы: за выразительность приходится платить достаточно сложной инфраструктурой под капотом. Так что на перфоманс-сравнение с Go, мне как C# разработчику, больно смотеть. Вот и разработчики из Майкрософта, кажется, так подумали и решили наконец что-то сделать. Этим “что-то” стал runtime-async – оптимизация, которая сильно облегчает рантайму обработку асинхронных операций, не меняя с точки зрения пользователя ни синтаксис, ни семантику существующего async/await.
😨 Хоть runtime async пока и находится в превью, очень интересно видеть, что результаты некоторых бенчмарков говорят об улучшении не просто на проценты, а в разы! Так, в последнем превью мы получили 6357.1 ms → 457.1 ms времени выполнения для async методов, возобновляемых после OSR-оптимизации.
Интересно разобрать откуда такой выигрыш и как это работает под капотом?
🤯 Издревле (.NET Framework 4.5 – 2012 год) так сложилось, что механизм асинхронности в C# реализован через явную пометку пользователем цвета функций – через ключевое слово async, и такое же явное обозначение точки приостановки (suspension) – через ключевое слово await. Многими даже считается, что именно C# стал основным популяризатором такого подхода в свое время.
🚀 Тем не менее время шло, и в новых языках – необремененных еще необходимостью поддерживать обратную совместимость с 100500 предыдущими версиями – стали появляться более эффективные, но менее гибкие подходы. Главным контрпримером обычно выступает Go с легковесными потоками, которые планируются рантаймом поверх обычных тредов операционной системы. При таком подходе программист может не задумываться о всем вышеперечисленном, вплоть до полного непонимания что такое асинхронность. Сравнивать эти модели с точки зрения удобства и гибкости сейчас не будем – это тема как минимум отдельного поста (ставьте классы)
😭 А вот с точки зрения стоимости исполнения у C# есть проблемы: за выразительность приходится платить достаточно сложной инфраструктурой под капотом. Так что на перфоманс-сравнение с Go, мне как C# разработчику, больно смотеть. Вот и разработчики из Майкрософта, кажется, так подумали и решили наконец что-то сделать. Этим “что-то” стал runtime-async – оптимизация, которая сильно облегчает рантайму обработку асинхронных операций, не меняя с точки зрения пользователя ни синтаксис, ни семантику существующего async/await.
😨 Хоть runtime async пока и находится в превью, очень интересно видеть, что результаты некоторых бенчмарков говорят об улучшении не просто на проценты, а в разы! Так, в последнем превью мы получили 6357.1 ms → 457.1 ms времени выполнения для async методов, возобновляемых после OSR-оптимизации.
Интересно разобрать откуда такой выигрыш и как это работает под капотом?