2.37M

№1-3

1.

№1: Формулирование
исследовательских вопросов и
задач.
Работу выполнил
Студенты группы УВП-177
Константинов Александр Геннадьевич
Бадьин Роман Сергеевич
Проверил:
Разживайкин Игорь Станиславович, ст. п.

2.

Задачи
Цель практической работы - научить студентов
формулировать исследовательские вопросы и задачи в
области проектирования и разработки программного
обеспечения (ПО).

3.

Тема работы:
Задачи
• Основные концепции квантового программирования
• Инструменты
• Способы применения

4.

Проблемы: С#
Команда .NET работала над новым экспериментом под названием async2,
который представляет собой новую реализацию шаблона async/await,
разработанную для большей эффективности и гибкости, чем текущая
реализация. Она началась с зеленых потоков и закончилась
экспериментом, который перемещается async/await в среду выполнения.
Эксперимент green thread:
Зеленые потоки — это потоки пользовательского пространства, которые
управляются виртуальной машиной вместо операционной системы.
Проблемы с управлением ресурсами и планировщиком задач.
Взаимодействие с кодом было сложным и более медленным, чем при
использовании обычных потоков.
Сложное взаимодействие между зелеными потоками и существующей
асинхронной моделью
Неопределенность относительно того, возможно ли сделать зеленые
потоки быстрее асинхронных в важных сценариях, учитывая усилия,
необходимые для улучшения.

5.

Проблемы: С#
Эксперимент Asunc2:
Целью эксперимента было перемещение async/await в среду выполнения
• Целесообразность внедрения нового подхода.
• Проблемы, возникающие при прямой трансляции в Runtime асинхронного
кода в IL (Intermediate Language) без создания конечного автомата.
• Размер сборки. А также затраты ОЗУ.
• Влияние на существующий синтаксис async/await.

6.

Вопросы: С#
Легковесные потоки для .Net:
• Какие подходы к созданию легковесных потоков могут быть применены к
.Net на основе опыта и техники из других языков программирования
(например, Go, Kotlin)?
• Возможные преимущества и недостатки при внедрении таких подходов в
экосистему .Net.
Сравнение Async2 с Async:
• Какой подход является более производительным и гибким?
• Анализ преимуществ и недостатков каждого подхода на основе
экспериментальных данных.
Оптимизация ресурсов:
• Как различные подходы к асинхронному программированию влияют на
оптимизацию использования оперативной памяти (ОЗУ) и постоянного
запоминающего устройства (ПЗУ)?
• Сравнительный анализ ресурсных затрат различных сборок.

7.

Литература:
С#
• Доклад Евгения Пешкова с DotNext 2024 «Асинхронность: не только
async/await»
• Блог Steven Giesel «async2 - The .NET Runtime Async experiment
concludes»
• Github эксперементов https://github.com/dotnet/runtime/issues/94620
• Эксперимент по задачам, обрабатываемым во время выполнения
https://github.com/dotnet/runtimelab/blob/feature/async2experiment/docs/design/features/runtime-handled-tasks.md

8.

№2: Планирование
исследовательского
проекта.
Работу выполнил
Студенты группы УВП-177
Константинов Александр Геннадьевич
Бадьин Роман Сергеевич
Проверил:
Разживайкин Игорь Станиславович, ст. п.

9.

Задачи
Цель данной практической работы состоит в том, чтобы
научить студентов
планировать исследовательский проект в области
проектирования и
разработки программного обеспечения. Задачи включают в
себя
разработку детального плана исследовательского проекта,
определение
этапов работы, распределение ресурсов и временных рамок
для
достижения поставленных целей.

10.

План исследования
1. Анализ существующих подходов на Языках C#/Java
2. Анализ приоритетных подходов
• С#
• Green Threads
• Async2
• State Machine ну уровне IL
• Stack Unwinder
• Java
• <Рома>
3. Анализ научных статей
4. Создание прототипов для сравнения
5. Итоги

11.

Анализ существующих подходов на Языках C#/Java
Существующие подходы на C# имеют рад проблем.
• Повышения одновременно обрабатываемых запросов
• За счет создания конечного автомата сборки достигают
большого объёма
• Уменьшение количества созданных потоков
В ходе работы будут проанализированы данные
характеристики существующих подходов

12.

Анализ приоритетных подходов
Команда .NET работала над новым экспериментом под
названием async2, который представляет собой новую
реализацию шаблона async/await, разработанную для
большей эффективности и гибкости, чем текущая
реализация. Она началась с зеленых потоков и закончилась
экспериментом, который перемещается async/await в среду
выполнения.
Основные направления:
• Эксперимент green thread:
• Эксперимент Asunc2:

13.

Создание прототипов для сравнения
Создание прототипов и сравнение таких параметров:
• Оперативная память
• Размер сборки
• RPM

14.

№3: Сбор и анализ данных.
Работу выполнил
Студенты группы УВП-177
Константинов Александр Геннадьевич
Бадьин Роман Сергеевич
Проверил:
Разживайкин Игорь Станиславович, ст. п.

15.

Асинхронность в C# сейчас:
.NET Runtime исторически поддерживала модель программирования
разработки асинхронных программ посредством использования библиотеки
System.Threading.Tasks, предоставляемой средой выполнения, а также
поддержки асинхронных методов Roslyn, которая взаимодействует с этой
библиотекой задач, чтобы упростить написание конечных автоматов на
основе обратных вызовов, которые может использовать среда выполнения.
За эти годы было предпринято несколько попыток оптимизировать
производительность и другие характеристики этой схемы, но в основном
эти договоренности опирались либо на изменения в кодовой базе
основной библиотеки, либо на корректировки сгенерированного кода IL.
Эта работа стремится определить, какие улучшения в асинхронной модели
могут быть достигнуты путем перемещения вычисления и обработки
конечного автомата на внутреннюю обработку в среде выполнения.

16.

Экспериментальные цели:
• Выясните, являются ли асинхронные конечные автоматы, созданные во
время выполнения, существенно более производительными, чем
существующая модель асинхронного конечного автомата.
• Выясните, можем ли мы реализовать вариант async, который имеет
некоторые тонкие изменения семантического поведения, но остается
совместимым с существующим кодом, написанным в оригинальном стиле.

17.

Эксперимент green thread:
Зеленые потоки — это потоки пользовательского пространства, которые
управляются виртуальной машиной вместо операционной системы.
Проблемы:
Проблемы с управлением ресурсами и планировщиком задач.
Взаимодействие с кодом было сложным и более медленным, чем при
использовании обычных потоков.
Сложное взаимодействие между зелеными потоками и существующей
асинхронной моделью
Неопределенность относительно того, возможно ли сделать зеленые
потоки быстрее асинхронных в важных сценариях, учитывая усилия,
необходимые для улучшения.

18.

19.

Реализация green thread:
Thread.IsGreenThread
Проверяет, запущен ли код на green thread
Task.RunAsGreenThread(Action)
Запускает синхронный Action как асинхронный на green thread
Task.Wait() / .GetAwaiter().GetResult()
При вызове в green thread выполняет неблокирующее ожидание

20.

Реализация green thread:

21.

Недостатки green threads:
• Заражение синхронного кода stub’ами
• Проблема с методами, принимающими Span<T>
• Для перехода в Async-версию требуется копирование (в массив из
пула)
• Медленный Invoke (6 раз)
• По производительности оказался таким же, как async (но они и не про
перформанс?!):
• ASP.NET Core plaintext: 178K RPS (async), 162K RPS (green threads)
• Различные сложности реализации
• На этом эксперимент с green threads закончили

22.

Эксперимент async2:
Целью эксперимента было перемещение async/await в среду выполнения.
Проблемы:
• Целесообразность внедрения нового подхода.
• Проблемы, возникающие при прямой трансляции в Runtime асинхронного
кода в IL (Intermediate Language) без создания конечного автомата.
• Размер сборки. А также затраты ОЗУ.
• Влияние на существующий синтаксис async/await.

23.

Эксперимент async2:
Как было до этого:

24.

Эксперимент async2:
Как стало:

25.

async2: размер сборки
• async2 не разворачивает код в state machine
• IL кода получается меньше, на уровне синхронного метода
Совместимость в обе стороны:
• async2 может ожидать (await) Task
• async метод может ожидать async2 метод

26.

async2: exception throwing

27.

async2 in runtime
Две реализации
• Сохранение состояния стека (stack unwinder)
• State machine, сгенерированная на уровне JIT
DOTNET_RuntimeAsyncViaJitGeneratedStateMachines

28.

async2: stack unwinder

29.

async2: stack unwinder
Общая конструкция заключается в использовании идеи, что функция,
сгенерированная обычным кодом в точке вызова функции, фактически
является конечным автоматом.
Индекс для возобновления — это IP, который установит возврат к
функции, а стековый фрейм + сохраненные регистры — это текущее
состояние конечного автомата.
Мы можем достичь производительности, сравнимой с синхронным кодом, с
помощью этой схемы для не приостановленных сценариев, и мы можем
достичь приемлемой общей производительности в качестве асинхронного
механизма, если приостановка будет относительно редкой.

30.

async2: stack unwinder

31.

async2: stack unwinder

32.

async2: stack unwinder

33.

async2: stack unwinder

34.

async2: stack unwinder

35.

async2: stack unwinder

36.

async2: stack unwinder

37.

Сравнение :
Производительность
взаимодействия между
стратегиями реализации
Async и Async2 стала
проблемой при. Учитывая,
что это предложение
предполагает построение
модели, которая позволяет
обеим сосуществовать в
одном приложении, важно
понимать стоимость таких
вызовов.
Этот бенчмарк подсчитывает итерации в секунду не приостанавливающих
вызовов
между различными методами, реализованными как async или async2
относительно редкой.

38.

Сравнение: Сборщик мусора
Стоит рассмотреть поведение простого бенчмарка, который обеспечивает 10000
приостановленных задач в какой-то момент, каждая из которых содержит 100
стековых кадров с по крайней мере 1 объектом и 1 целым числом, активным через
await, и, таким образом, требует захвата. В то время, когда задачи
приостанавливаются, бенчмарк принудительно запускает несколько Gen0 GC и
измеряет среднее время, затраченное GC, а также размер управляемой кучи.
При выполнении измерений тест выдает очень мало мусора, поскольку основной
интерес представляет не то, как сборщик мусора обрабатывает выделения, а то,
как наличие захваченных задач влияет на сборщик мусора.

39.

Сравнение: Сборщик мусора
Async1
Есть некоторый шум, но типичная пауза Gen0 в приведенном выше сценарии
составила: 120 микросекунд. Управляемый размер кучи (по сообщению
GetGCMemoryInfo.HeapSizeBytes) стабилен и составляет 130 Мб. Пиковый рабочий
набор (по сообщению Task Manager) составляет 148 Мб.
Async2 (unwinding/stack-capturing based)
Когда паузы GC измерялись как есть, результаты были весьма разочаровывающими
- 48690 микросекунд .
(примерно в 400 раз хуже, чем async1 и в целом неприемлемо для паузы Gen0)
Причина таких временных рамок в том, что реализация будет проходить через
каждый из 1000000 tasklet и сообщать о ссылочных объектах как о корнях. Это
занимает много времени и также является очень избыточным, если рассматривать
модель поколений GC. Поскольку приостановленные стеки не могут видеть
назначения новых объектов, после того, как GC выполняет массовое продвижение,
все корни, принадлежащие этим задачам, становятся слишком старыми, чтобы
представлять интерес для коллекций, нацеленных на более молодые поколения,
пока содержащая задача не будет возобновлена.
Это уникальная проблема реализации захвата стека. В async1 приостановленные

40.

Сравнение: Сборщик мусора
Async2 (на основе конечного автомата JIT)
Время паузы наблюдалось на уровне 100 микросекунд , что лучше, чем в
реализации async1. Поскольку корневой набор будет примерно таким же, как в
async1, разница может быть просто эффектами второго порядка другого графика
кучи или другого распределения размеров объектов.
Пиковый рабочий набор был замечен на уровне 328 Мб. Это выше, чем async1, и,
скорее всего, просто дополнительные временные выделения в JIT. Поскольку в
бенчмарке всего несколько методов, это не могут быть тела методов, но для
подтверждения может потребоваться некоторое последующее наблюдение.

41.

Итоги
Исходя из приведенного исследования можно сделать выводы, что имплементация
зеленых потоков в C#, как и переход к одной из нескольких реализаций Async2
имеет место быть.
Зеленые потоки могут быть полезны для разгрузки реальных потоков, хоть и на
практике значительного преимущества в производительности и не дают.
Касательно же перемещения конечного автомата в JIT, будет однозначно полезно.
Благодаря эксперименту сотрудников Microsoft, было продемонстрирована
реализация данного подхода с положительными результатами.
Подход же с unwinding/stack-capturing based является самым перспективным
направлением, которое требует переработки GC, в качестве дальнейшего развития
мы видим именно этот подход.

English Русский Rules