Posted on 16. March 2024

Get started with .NET 8 and AI using new quickstart tutorials

Дізнайтеся більше про .NET 8 та штучний інтелект за допомогою нових коротких навчальних матеріалів

У планах на наступний рік – кілька чудових оновлень для .NET-розробників, які працюють зі штучним інтелектом (щоб дізнатися більше, ознайомтеся з нашим баченням .NET 9).  Якщо ви замислювалися над тим, щоб наповнити свої наявні .NET-додатки генеративними моделями штучного інтелекту та великими мовними моделями (LLM), зараз саме час зануритися в роботу, і у нас є нові інструкції, які допоможуть вам у цьому.

Вивчайте штучний інтелект за допомогою нових інструкцій зі швидкого запуску .NET

Ми щойно випустили новий набір швидких запусків, які ви можете використовувати з великими мовними моделями OpenAI (незабаром з’явиться ще більше моделей):

У кожному прикладі ви крок за кроком ознайомитеся з кодом, необхідним для виконання теми, за допомогою Azure OpenAI SDK. Дуже скоро ми також додамо версії цих прикладів з використанням Semantic Kernel SDK (ми опублікуємо пост тут, коли вони будуть готові).

Дізнайтеся більше про основні концепції

Якщо ChatGPT, LLM, моделі та OpenAI – це нові для вас терміни, або ви тільки починаєте працювати в цій сфері, ось кілька додаткових ресурсів, які допоможуть вам вивчити основні поняття та дослідити їх краще:

 



.NET | AI | C#
Posted on 9. July 2023

У .NET Community Toolkit 8.2.1 з’явилися покращені генератори вихідного коду та засоби виправлення коду!

 

Ми раді повідомити про офіційний запуск версії 8.2.1 .NET Community Toolkit! Ця нова версія містить багато покращень QoL у всіх бібліотеках, ще кілька оптимізацій продуктивності для генераторів джерел MVVM Toolkit, нові засоби виправлення коду та покращену діагностику тощо!


.NET Community Toolkit 8.2.1

Ми хочемо висловити особливу подяку всім членам спільноти, які надали цінні відгуки, щоб допомогти визначити пріоритетність завдань для цього нового випуску. Ваші внески та звіти про помилки допомагають нам робити .NET Community Toolkit ще кращим із кожним випуском — ви найкращі!

Що входить до складу .NET Community Toolkit?

.NET Community Toolkit містить такі бібліотеки:

CommunityToolkit.Common

CommunityToolkit.Mvvm(він же «Microsoft MVVM Toolkit»)

CommunityToolkit.Diagnostics

CommunityToolkit.HighPerformance

Щоб дізнатися більше про історію .NET Community Toolkit, ось посилання на нашу попередню публікацію оголошення про 8.0.0 .

Ось розбивка основних змін, які включені в цей новий випуск 8.2.1 .NET Community Toolkit. Цей випуск здебільшого зосереджений на поступових покращеннях: немає нових функцій, але є багато налаштувань і виправлень!

Новий аналізатор і коректор коду для[RelayCommand] 

Атрибут [RelayCommand] (див. документацію тут) може автоматично обробляти асинхронні методи, і в цьому випадку він використовуватиме інтерфейси IAsyncRelayCommand (разом із відповідним типом асинхронної команди). Однак розробникам було нелегко виявити цю функцію, і багато хто натомість створював свої командні методи. Це також означало, що вони не могли використовувати всю додаткову функціональність, надану асинхронними командами (наприклад, звітування про прогрес і контроль паралельності).

Щоб допомогти з цим, версія 8.2.1 MVVM Toolkit постачається з абсолютно новим аналізатором, який випромінює діагностику для методів async void , позначених [RelayCommand]. А щоб зробити роботу ще простішою, є також новий засіб виправлення коду, який автоматично перероблятиме код за вас — просто клацніть піктограму лампочки, і дозвольте Roslyn зробити роботу за вас!

Виправлення коду аналізатора MVVM Toolkit

 

Тут ви можете побачити нову згенеровану діагностику, яка відображається для методу async void, пов’язаного з командою, і відповідного інтерфейсу коректора коду у Visual Studio з попереднім переглядом змін. Він також автоматично додасть необхідний оператор using у верхній частині вашого файлу, якщо Task ще немає в області видимості. І так само, як і інші засоби виправлення коду в MVVM Toolkit, ви також можете легко застосувати його до всіх місць у всьому вашому проєкті чи рішенні одним клацанням миші!

Інші зміни та вдосконалення

Виправлено аварійну ситуацію при індексації розрізаного екземпляра Memory2D (#675): у деяких випадках могло бути викликано порушення доступу під час індексування елементів після нарізання екземпляра Memory2D. Тепер це виправлено, дякуємо mahalex за повідомлення про це!

– Виправлено атрибути пересилання з від’ємними значеннями переліку (#681): використання елементів переліку з від’ємними значеннями більше не спричиняє проблеми з генераторами MVVM Toolkit для згенерованих спостережуваних властивостей. Дякуємо n-coelho-cerinnov за повідомлення про це!

Виправлено збій генератора під час пересилання недійсних атрибутів (#683): спроба переслати атрибути, на які є неправильні посилання, тепер завершуватиметься помилкою та створюватиме зрозуміле повідомлення про помилку.

Виправлення генератора  ObservableValidator для виявлення успадкованих властивостей (#616): генератор для перевірки властивостей більше не буде випадково ігнорувати властивості базових типів для цільової моделі перегляду. Дякуємо dgellow за повідомлення про це!

Додано попередження під час використання packages.config для MVVM Toolkit (#695): генератори набору інструментів MVVM працюють лише під час використання (це відоме обмеження SDK, і воно є задумом), але раніше не було чітких вказівок на те, чому генератори не працювали для користувачів, які намагаються використовувати їх із проекту за допомогою packages.config. MVVM Toolkit тепер постачається з покращеною діагностикою, яка створить корисне попереджувальне повідомлення в цьому випадку. Дякуємо, smaugbend , що повідомили про це!

Частіше перевіряйте скасування в генераторах (#703): це має призвести до невеликих покращень у чутливості IDE під час використання MVVM Toolkit.

 

Видалення непотрібного тимчасового розподілу масиву (#719): ще одна невелика оптимізація пам’яті для генераторів джерел MVVM Toolkit.

Обробка поля [ObservableProperty] з ідентифікаторами ключових слів (#710): генератор більше не створюватиме недійсний код у випадку, якщо поля анотовані [ObservableProperty] використовують ідентифікатори ключових слів, які були екрановані у джерелі (наприклад, @event). Дякуємо Get0457 за повідомлення про це!

 

Примітка: існує відома проблема з джерельними генераторами в старіших версіях Roslyn, через яку IntelliSense іноді може не працювати належним чином для згенерованих учасників (див. #493 і пов’язану проблему відстеження Roslyn). Це нарешті виправлено у VS 2022 17.7, який зараз знаходиться в прев’ю. Якщо ви бачите будь-які проблеми під час використання MVVM Toolkit, обов’язково спробуйте останню версію VS 17.7 Preview!

Інші зміни

Ви можете переглянути повний журнал змін для цього випуску на сторінці випуску GitHub .

Почніть сьогодні!

Ви можете знайти весь вихідний код у нашому репо GitHub , деякі рукописні документи на MS learn і повні посилання на API на веб-сайті браузера .NET API. Якщо ви хочете внести свій внесок, не соромтеся відкривати питання або зв’язуватися з нами, щоб повідомити про свій досвід! Щоб стежити за розмовою в Twitter, використовуйте хештег #CommunityToolkit. Усі ваші відгуки дуже допомагають у формуванні напрямків цих бібліотек, тож поділіться ними!

 

Щасливого кодування!

Source




Posted on 30. April 2023

Почніть роботу з OpenAI Completions та .NET

 

Ласкаво просимо до цієї серії блогів про OpenAI та .NET!

Якщо ви тут новачок, перегляньте нашу першу публікацію, де ми представляємо цю серію та показуємо, як почати використовувати OpenAI у .NET.

Основна увага цієї публікації зосереджена на completions. Давайте розпочнемо!

Що таке completions?

Completions — це відповіді, згенеровані такою моделлю, як GPT.

Типи відповідей, які ви можете створити, включають:

Текст

Ввід:

Перекладіть «Hello» іспанською.

Вивід:

«Hola»

Код

Ввід

 

Створіть функцію C#, яка додає два цілі числа

Вивід

Зображення

Ввід

Затишний мопс в килимку

Вивід

Зображення, створене штучним інтелектом, зображення мопса 1 у масштабі 1 jpg

 

У цій публікації основна увага приділяється доповненню тексту та коду.

Як генеруються completions?

Є кілька частин, необхідних для створення completion:

- Модель

- Ввід користувача (запит)

Схема робочого процесу завершення AI (введення користувача, модель, завершення)

Ви можете розглядати модель як функцію зі збереженням стану. Модель — це система, розроблена для визначення шаблонів у даних за допомогою алгоритмів. Можливості моделі залежать від даних і алгоритмів, які використовуються для побудови моделі. Додаткову інформацію про різні типи моделей та їхні можливості див. у документації моделей Azure OpenAI Service .

Алгоритми, які використовуються для створення моделей OpenAI, таких як GPT, є нейронними мережами, відомими як трансформатори. Якщо говорити точніше, такі моделі, як GPT, часто називають великими мовними моделями (LLM – Large language model) через їх розмір (великі) і тип проблем, який вони призначені вирішувати (мова).

Технічні деталі LLM виходять за рамки цієї публікації. Однак, якщо вам цікаво дізнатися більше, перегляньте статтю Що робить ChatGPT…і чому він працює, а також документ Мовні моделі – це ті, хто навчається без особливих зусиль.

Ввід користувача, також відомий як запит (промпт), є тим, що керує моделлю та надає інструкції щодо того, що ви хочете отримати за допомогою неї. Для більш точних результатів промпт повинен мати такий вміст:

- Контекст

- Завдання / запитання

З огляду на наступний запит:

Підсумуйте це для учня другого класу:

Юпітер — п’ята планета від Сонця і найбільша в Сонячній системі. Це газовий гігант, маса якого в одну тисячу разів перевищує масу Сонця, і у два з половиною рази більша, ніж у всіх інших планет Сонячної системи разом узятих. Юпітер є одним із найяскравіших об’єктів, видимих ​​неозброєним оком на нічному небі, і був відомий стародавнім цивілізаціям ще до історичних пам’яток. Він названий на честь римського бога Юпітера.[19] Якщо дивитися з Землі, Юпітер може бути достатньо яскравим, щоб його відбите світло відкидало видимі тіні [20], і в середньому є третім за яскравістю природним об’єктом на нічному небі після Місяця та Венери.

Його можна розбити на:

- Контекст: Юпітер — п’ята планета від Сонця та найбільша в Сонячній системі. Це газовий гігант, маса якого в одну тисячу разів перевищує масу Сонця, і у два з половиною рази більша, ніж у всіх інших планет Сонячної системи разом узятих. Юпітер є одним із найяскравіших об’єктів, видимих ​​неозброєним оком на нічному небі, і був відомий стародавнім цивілізаціям ще до писемної історії. Він названий на честь римського бога Юпітера.[19] Якщо дивитися з Землі, Юпітер може бути достатньо яскравим, щоб його відбите світло відкидало видимі тіні [20], і в середньому є третім за яскравістю природним об’єктом на нічному небі після Місяця та Венери.

- Завдання/запитання: Узагальніть це для учня другого класу:

Отриманий completion має виглядати приблизно так:

Юпітер — п’ята планета від Сонця і найбільша в нашій Сонячній системі. Він дуже яскравий на нічному небі та відомий з давніх часів. Він названий на честь римського бога Юпітера. Зазвичай це третій за яскравістю об’єкт на нічному небі після Місяця та Венери.

 

Важливою частиною тут є завдання/запит, оскільки це те, що керує моделлю для отримання певного виду результату. Наприклад, якби я змінив завдання/запит на «Яка маса Юпітера порівняно з Сонцем?», я міг би розраховувати на завершення, подібне до «Юпітер має масу в тисячну частину від маси Сонця або 0,001 сонячної маси».

Як ви бачите, коли ви поєднуєте таку модель, як GPT, із добре сформованим запитом, вони формують ефективну основу для створення всіх типів додатків за допомогою ШІ.

Скільки тексту я можу надати у своєму запиті?

Розмір запиту вимірюється в токенах. Як правило, моделі GPT розбивають слова на «токени». Хоча звичайні багатоскладові слова часто складаються з однієї лексеми, менш поширені слова розбиваються на склади. Кожна модель має ліміт жетонів. Щоб отримати додаткові відомості, перегляньте документацію щодо моделей служби Azure OpenAI .

Щоб підрахувати кількість токенів у вашому запиті, скористайтеся пакетом Microsoft.ML.Tokenizers NuGet.

Подробиці режиму див. у прикладі токенізації .

Як почати генерувати власні completions?

Тепер, коли ви знаєте, що таке completions та як вони генеруються, настав час почати генерувати власні. Щоб почати:

1. Зареєструйтеся або подайте запит на доступ до OpenAI або Azure OpenAI Service .

2. Використовуйте свої облікові дані, щоб почати експериментувати із зразками OpenAI .NET .

Що далі

У наступному дописі ми детальніше розглянемо тему розробки запитів, яка є процесом оптимізації ваших промптів для отримання більш точних відповідей.

Ми хочемо почути від вас

Допоможіть нам дізнатися більше про те, як ви плануєте використовувати ШІ у своїх програмах. Приділіть кілька хвилин, щоб заповнити це опитування .

 

Чи є якісь теми, про які вам цікаво дізнатися більше? Дайте нам знати в коментарях.

Source



Posted on 5. April 2021

GC Perf Infrastructure - Часть 1

Microsoft открывает новый проект GC Perf! Теперь это часть репозитория производительность .Net.

Прежде всего, позвольте отметить, что целевой аудиторией этой инфраструктуры, помимо очевидной (то есть тех, кто вносит изменения в производительность GC), являются люди, которым необходимо провести углубленный анализ GC / производительности управляемой памяти и / или построить автоматизацию вокруг этого. Таким образом, предполагается, что у вас уже есть достаточное количество знаний о том, что искать при анализе.

Во-вторых, в инфраструктуре много движущихся частей, и, поскольку она все еще находится в стадии разработки, я не удивлюсь, если вы столкнетесь с проблемами при ее использовании. Пожалуйста, будьте терпеливы, когда мы решаем проблемы! У нас нет много ресурсов, поэтому мы не сможем получить к ним доступ сразу. И, конечно, если вы хотите внести свой вклад, для нас это будет очень ценно. Я знаю многих людей, которые читают это, увлечены анализом производительности и проделали огромную работу по созданию / улучшению ее для .NET. А внесение вклада в анализ производительности – это фантастический способ узнать о настройке GC, если вы хотите начать с чего-то. Поэтому я настоятельно рекомендую вам внести свой вклад!

 

Топология

Мы обсудили, хотим ли мы открыть исходный код для этого в своем собственном репо, и пришли к выводу, что мы не будем делать это в основном из-за логистических соображений, поэтому это стало частью репозитория perf в каталоге src/benchmarks/gc (к которому я буду обращаться в качестве корневого каталога). Это не зависит от чего-либо это означает, что вам не нужно ничего создавать вне этого каталога, если вы просто хотите использовать инфракрасную часть GC perf.

Файл readme.md в корневом каталоге описывает общий рабочий процесс и основное использование. Дополнительную документацию можно найти в каталоге документов.

Есть 2 основных компонента инфраструктуры:

Запуск тестов производительности

Это запускает наши собственные тесты перфорирования – это для людей, которым нужно действительно вносить изменения производительности в GC. Это обеспечивает следующие функциональные возможности –

Задание различных аргументов командной строки для генерации разных характеристик perf в тестах, например, разных коэффициентов построения для SOH / LOH и разных коэффициентов пиннинга;

Определение сборок для сравнения;

Задание различных сред, например, различных переменных env для указания конфигураций GC, работы в контейнерах или ситуаций с высокой загрузкой памяти;

Задание различных параметров для сбора трасс с помощью, GCCollectOnly или ThreadTime.

Вы указываете все это в том, что мы называем стендовым файлом (это файл .yaml, но на самом деле это может быть что угодно – мы просто выбрали .yaml). Мы также предоставляем конфигурации для базовых сценариев перфорации, поэтому при внесении изменений их следует запускать, чтобы убедиться, что все не регрессирует.

Вам не нужно запускать тесты – вы можете запускать все что угодно, если только вы можете указать это как программу командной строки, и при этом использовать все остальное, что мы предоставляем, например запуск в контейнере.

Это задокументировано в файле readme, и я буду говорить об этом более подробно в одной из будущих записей в блоге.

Источник для этого находится в exec dir.

Анализ производительности

Это может использоваться без бегущей части вообще. Если вы уже собрали следы перфектов, вы можете использовать их для анализа. Я предполагаю, что больше людей заинтересуются этим, чем бегущей частью, поэтому я посвятим больше контента анализу. В последней публикации GC я уже говорил о том, что вы можете сделать это с помощью Jupyter Notebook (я покажу больше примеров с реальным кодом в следующих записях блога). На этот раз я сосредоточусь на фактической настройке и использовании команд, которые мы предоставляем. Не стесняйтесь попробовать это сейчас

Источник находится в  analysis.

Настройка анализа

После копирования репозитория с производительностью dotnet вы увидите файл readme в директории gc infra root. Настройка подробно описана в этом документе. Если вам просто нужен анализ, вам не нужно выполнять все шаги по настройке. Единственные шаги, которые вам нужны –

Установите Python. 3.7 является минимально необходимой версией и рекомендуемой версией. 3.8 есть проблемы с Jupyter Notebook. Я хотел указать на это, потому что 3.8 – последняя версия релиза на странице python.

Установите необходимые библиотеки python – вы можете сделать это через «py -m pip install -r src / needs.txt», как сказано в readme, и если ошибок не возникает, отлично; но вы можете получить ошибки с pythonnet, который является обязательным для анализа. На самом деле установка pythonnet может быть настолько хлопотной, что мы посвятили ей целый документ. Я надеюсь, что однажды в VSCode будет достаточно хороших библиотек для построения диаграмм на С#, и С# в Jupyter Notebook, будут работать,  поэтому нам больше не понадобится pythonnet.

Создайте библиотеку анализа С#, запустив «dotnet publish» в каталоге src\analysis\managed-lib dir.

Укажите, что анализировать

Допустим, вы собрали трассировку ETW (это может быть из .NET или .NET Core) вам нужно его проанализировать, какой процесс будет для вас интересен (в Linux вы собираете события для интересующего процесса с помощью dotnet-trace, но поскольку инфраструктура работает как в Windows, так и в Linux, это те же шаги). Определение процесса для анализа означает простую запись файла .yaml, который мы называем «файлом статуса теста». Из файла readme для файла состояния теста, который вы пишете только для анализа, нужны только эти 3 строки:

success: true

trace_file_name: x.etl # A relative path. Should generally match the name of this file.

process_id: 1234 # If you don’t know this, use the print-processes command for a list

Вы можете задаться вопросом, зачем вообще указывать строку «success: true» – это просто потому, что нижеприведенная схема также может использоваться для анализа результатов выполнения тестов. Когда вы запускаете множество тестов и анализируете их результаты в области автоматизации, мы ищем эту строку и анализируем только те, которые были успешными.

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

Мы действительно хотели, чтобы инфраструктура обеспечивала значимую встроенную помощь, поэтому, когда вы задаетесь вопросом, как сделать что-то, вы можете найти это в  справке. Чтобы получить список всех команд, просто попросите помощи верхнего уровня в корневом каталоге –

C:\perf\src\benchmarks\gc>py . help

Сначала прочтите README.md. Для помощи с отдельной командой используйте py . command-name –help. (Вы можете пропустить —help –hidden чтобы увидеть скрытые аргументы.)

Запустите команду

[пропустить]

команды анализа

Команды для анализа результатов теста (файлы трассировки). Чтобы сравнить небольшое количество конфигурации, используйте diff. Для сравнения используйте chart-configs. Для подробного анализа одной трассы используйте analyze-single или chart-individual-gcs.

analysis-single: с учетом одной трассы, показателей печати и, при необходимости, показателей для отдельных GC.

analyse-single-gc: выводит подробную информацию об одном GC в пределах одной трассы.

[больше вывода опущено и выполнено некоторое форматирование вывода]

 

(Я прошу прощения за форматирование – меня поражает, что у нас, похоже, нет приличной программы редактирования html для ведения блогов, а написание блога в основном состоит из ручного написания html, что очень больно)

Как говорится в справке высокого приоритета, вы можете получить помощь по конкретным командам. Поэтому мы последуем этому предложению и сделаем

C: \ perf \ src \ benchmarks \ gc> py. помочь печатным процессам

 

Напечатайте все PID процесса и имена из файла трассировки.

[больше выходных данных пропущено; Я также сделал некоторое форматирование, чтобы избавиться от некоторых столбцов, чтобы строки не были слишком длинными]

 

В качестве примера я специально выбрал тест, который, по моему мнению, не подходит для работы с Server GC, потому что он имеет только один поток, поэтому я ожидаю увидеть некоторый дисбаланс потоков. Я знаю, что дисбаланс возникнет, когда мы отметим объекты старшего поколения, удерживающие объекты молодого поколения, поэтому я буду использовать команду chart-individual-gcs, чтобы показать мне, сколько времени потребовалась каждому потоку.

C:\perf\src\benchmarks\gc>py . chart-individual-gcs C:\traces\fragment\fragment.yaml –x-single-gc-metric Index –y-single-heap-metrics MarkOlderMSec

Это покажет 8 куч. Подумайте о прохождении —show-n-heaps.

Конечно, одна из куч всегда занимает значительно больше времени, чтобы пометить объекты молодого поколения, на которые ссылаются объекты более старого поколения, и чтобы убедиться, что это не из-за каких-то других факторов, я также посмотрел, сколько повышается за кучу –

C:\perf\src\benchmarks\gc>py . chart-individual-gcs C:\traces\fragment\fragment.yaml –x-single-gc-metric Index –y-single-heap-metrics MarkOlderPromotedMB

Это покажет 8 куч. Подумайте о прохождении —show-n-heaps.

Это подтверждает теорию – потому что мы пометили значительно больше одной кучи, что привело к тому, что эта куча потратила значительно больше времени на маркировку.

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

Вот пример .md, который показывает примеры использования некоторых команд. Обратите внимание, что анализ объединения еще не проверен – пиар вышел, и я хотел потратить больше времени на CR, прежде чем объединять его.

Источник



Posted on 19. March 2020

Асинхронное объединение ValueTask в .NET 5

Функция async / await в C # произвела революцию в том, как разработчики, нацеленные на .NET, пишут асинхронный код. Прибавьте немного async и await, измените, некоторые типы возвращаемых данных на задачи, и вы получите асинхронную реализацию. Теоретически.

На практике, очевидно, я преувеличивал легкость, с которой кодовая база может быть сделана полностью асинхронной, как и со многими задачами в разработке программного обеспечения, загвоздки часто в деталях. Одной из таких «загвоздок», с которыми, вероятно, знакомы разработчики .NET, ориентированные на производительность, является объект конечного автомата, который позволяет асинхронному методу выполнить свою магию.

Распределения и конечные автоматы

Когда вы пишете асинхронный метод в C #, компилятор переписывает это в конечный автомат, где большая часть вашего кода в вашем асинхронном методе перемещается в MoveNext сгенерированного компилятором типа (структура в сборках Release),  и с этим MoveNext  завален переходами и метками, которые позволяют методу приостановить и резюмировать в пункты  await. К незавершенным задачам await подключено продолжение (обратный вызов), которое при окончательном завершении задачи вызывает метод MoveNext и переходит к месту, где функция была приостановлена. Для того чтобы локальные переменные могли поддерживать свое состояние через эти выходы и повторные входы метода, соответствующие «локальные объекты» переписываются компилятором в поля типа конечного автомата. И для того, чтобы этот конечный автомат как структура сохранялся в тех же самых приостановках, он должен быть перемещен в кучу.

Компилятор C # и среда выполнения .NET изо всех сил стараются не помещать этот конечный автомат в кучу. Многие вызовы асинхронных методов фактически завершаются синхронно, и компилятор и среда выполнения настраиваются на этот вариант использования.  Как указано, в релизном билде, конечный автомат, сгенерированный компилятором, является структурой, и когда вызывается асинхронный метод, конечный автомат начинает свою жизнь в стеке. Если асинхронный метод завершается без приостановки, конечный автомат успешно завершится, никогда не вызывая распределение. Однако, если асинхронный метод когда-либо нужно приостановить, конечный автомат должен быть каким-то образом собран.

В .NET Framework, момент Task или  ValueTask возвращение асинхронного метода (как общего, так и не универсального) приостанавливается впервые, происходит несколько выделений:

1. Структура конечного автомата копируется в кучу через стандартный бокс времени выполнения; каждый конечный автомат реализует IAsyncStateMachine  интерфейс, среда выполнения буквально приводит структуру к этому интерфейсу.

2. Среда выполнения фиксирует текущий ExecutionContext а затем выделяет объект (он называет это «бегун»), который он использует для хранения обоих конечных автоматов в штучной упаковке и ExecutionContext  (обратите внимание, что в .NET Framework, регистрация ExecutionContext  если это не значение по умолчанию, это также приводит к одному или нескольким выделениям).

3. Среда выполнения выделяет Action , который указывает на метод в этом объекте запуска, потому что шаблон ожидающего требует Action  которые будут переданы ожидающему методу {Unsafe}OnCompleted; при вызове Action будет использовать ExecutionContext для вызова метода MoveNext на конечном компьютере.

4. Среда выполнения выделяет объект Task, который будет завершен после завершения асинхронного метода и это возвращается из асинхронного метода к его синхронному вызывающему (если асинхронный метод набран для возврата ValueTask, структура ValueTask просто оборачивается вокруг объекта Task).

Это как минимум четыре средства, когда асинхронный метод в первый раз приостанавливается. Кроме того, каждый последующий раз асинхронный метод приостанавливается, если мы окажемся с нестандартным ExecutionContext  (например, он переносит состояние для AsyncLocal),  среда выполнения перераспределяет это в запускающийся объект, затем перераспределяет действие, которое указывает на него (потому что делегаты неизменны), каждый раз выполняя минимум два дополнительных выделения, когда асинхронный метод приостанавливается после первого раза. Вот простое повторение этого в Visual Studio с правым окном, в котором отображаются распределения в соответствии с инструментом отслеживания распределения объектов .NET:

Это было значительно улучшено, в .NET Core, особенно с .NET Core 2.1. Когда асинхронный метод приостанавливается, выделяется Task. Но это не базовый тип Task или Task. Структура конечного автомата хранится в строго типизированном поле для этого производного типа, устранение необходимости в отдельном распределении бокса. Этот тип также имеет поле для захваченного ExecutionContext (который является неизменным в .NET Core, это означает что захват никогда не выделяется), нам не нужен отдельный объект ранера. И у среды выполнения теперь есть специальные пути кода, которые поддерживают передачу этого типа AsyncStateMachineBox напрямую всем ожидающим, о которых среда выполнения знает, это означает, что пока асинхронный метод ожидает только TaskTaskValueTask или ValueTask (напрямую или через их аналоги ConfigureAwait), ему вообще не нужно выделять Action. Затем, поскольку у нас есть прямой доступ к полю ExecutionContext, последующие приостановки не требуют выделения нового участника (участники полностью отсутствуют), это также означает, что даже если нам нужно было распределить действие, нам не нужно его перераспределять. Это значит, тогда как в .NET Framework у нас есть как минимум четыре выделения для первой приостановки и часто по крайней мере два распределения для каждой последующей приостановки, в .NET Core у нас есть одно распределение для первого приостановления (наихудший случай два, если используются пользовательские ожидающие), и это все. Другие изменения, такие как переписывание инфраструктуры очередей ThreadPool, также значительно сократили распределение.

 

Это изменение оказало очень ощутимое влияние на производительность (и, как оказалось, не только на производительность; оно также очень полезно для отладки), и мы все можем радоваться удалению ненужных ассигнований. Однако, как уже было отмечено, одно распределение все еще остается, когда асинхронный метод завершается асинхронно. Но ... что если мы тоже сможем избавиться от этого?  Что если бы мы могли сделать так, чтобы вызов асинхронного метода имел (амортизировался) накладные расходы при нулевом распределении независимо от того, завершился он синхронно или асинхронно?

ValueTask

ValueTask был введен в период .NET Core 1.0, чтобы помочь разработчикам избежать выделения ресурсов,  когда асинхронные методы завершаются синхронно. Это была относительно простая структура, представляющая различаемое объединение между TResult и Task. При использовании в качестве типа результата асинхронного метода, если вызов асинхронного метода возвращается синхронно, независимо от значения результата TResult, метод требует нулевого распределения накладных расходов: конечный автомат не нужно перемещать в кучу, и нет необходимости в задании Task для результата; значение результата просто сохраняется в поле TResult возвращенной ValueTask. Однако, если асинхронный метод завершается асинхронно, среда выполнения возвращается к поведению так же, как и в случае с задачей Task: он создает единственную задачу AsyncStateMachineBox, который затем возвращается в структуру ValueTask.

В .NET Core 2.1 мы представили интерфейс IValueTaskSource, наряду с неуниверсальными аналогами ValueTask и IValueTaskSource. Мы также сделали ValueTask способным хранить не только TResult, но и Task, но также IValueTaskSource (то же самое для неуниверсального ValueTask, который, может хранить Task или IValueTaskSource). Этот продвинутый интерфейс позволяет предприимчивому разработчику написать свое собственное резервное хранилище для задачи,  и они могут делать это таким образом, чтобы повторно использовать этот объект хранилища резервных копий для нескольких не параллельных операций (намного больше информации об этом доступно в этом посте). Например, Socket обычно используется не более чем для одной операции приема и одна операция отправки за раз. Socket  был изменен для хранения повторно используемого / сбрасываемого IValueTaskSource для каждого направления и каждой последующей операции чтения или записи что завершает и асинхронно раздает ValueTask, поддерживаемый соответствующим общим экземпляром. Это означает, что в подавляющем большинстве случаев методы ReceiveAsync/SendAsync на основе ValueTask в Socket  в конечном итоге не выделяются, независимо от того, выполняются они синхронно или асинхронно.  Несколько типов получили эту обработку, но только в тех случаях, где это будет действенно.

Таким образом, в .NET Core 2.1 были добавлены несколько реализаций в ключевых областях, таких как System.Net.SocketsSystem.Threading.Channels и System.IO.Pipelines, но не намного дальше. Впоследствии мы ввели тип ManualResetValueTaskSource, чтобы упростить такие реализации, и в результате было добавлено больше реализаций этих интерфейсов в .NET Core 3.0, а также в .NET 5, хотя в основном внутри различных компонентов, таких как System.Net.Http.

Улучшения в .NET 5

В .NET 5 мы дальше экспериментируем с этой оптимизацией. С .NET 5 Preview 1, если до запуска вашего процесса для переменной среды DOTNET_SYSTEM_THREADING_POOLASYNCVALUETASKS установлено значение true  или 1, среда выполнения будет использовать объекты конечного автомата, которые реализуют интерфейсы IValueTaskSource и IValueTaskSource. Он будет объединять объекты, которые создает, для возвращенных экземпляров из асинхронных методов async ValueTask  или async ValueTask. Итак, если, как и в предыдущем примере, вы повторно вызываете один и тот же метод и ожидаете результата, каждый раз, когда вы в конечном итоге получите ValueTask, который оборачивает один и тот же объект, просто сбрасывайте его каждый раз, чтобы позволить отслеживать другое выполнение. Магия.


Почему он не включен по умолчанию прямо сейчас? Две основные причины:

1. Объединение не является бесплатным. Разработчик может оптимизировать свой код различными способами. Один из них - просто улучшить код, чтобы больше не нуждаться в выделении; с точки зрения производительности это, как правило, очень низкий риск. Другой - повторно использовать уже доступный объект, например, добавив дополнительное поле к существующему объекту с аналогичным сроком службы; это все еще требует более подробного анализа производительности. Затем приходит объединение. Оно может быть очень полезным, когда создание объединяемой вещи очень ценно; хорошим примером этого является пул соединений HTTPS, где стоимость установления нового безопасного соединения, как правило, на несколько порядков дороже, чем доступ к нему даже в самой наивной структуре пулов данных. Более спорная форма объединения - это когда пул предназначен для дешевых объектов с целью избежать затрат на сборку мусора. Используя такой пул, разработчик делает ставку на то, что он может реализовать собственный распределитель (который действительно является пулом), который лучше, чем универсальный распределитель GC. Победить в сборной нетривиально. Но разработчик может это сделать, учитывая знания, которые они имеют в своем конкретном сценарии. Например, .NET GC очень хорошо умеет эффективно собирать недолговечные объекты, которые становятся коллекционными в поколении 0, и попытка объединения таких объектов может легко сделать программу более дорогой (даже если это выглядит хорошо на микробенчмарке, сфокусированном на измерении распределения). Но если вы знаете, что ваши объекты, вероятно, выживут в gen0, например, если они используются для представления потенциально асинхронных операций с большой задержкой, вполне возможно, что пользовательский пул может сбрить некоторые накладные расходы. Мы еще не сделали этот асинхронный пул async ValueTask по умолчанию, потому что, хотя он хорошо выглядит на микробенчмарках, мы не уверены, что это действительно значительное улучшение рабочих нагрузок в реальном мире.

2. ValueTasks имеют ограничения. Типы Task  и Task были разработаны, чтобы быть очень надежными. Вы можете их кешировать. Вы можете ждать их любое количество. Они поддерживают несколько продолжений. Они потокобезопасны, с любым количеством потоков, способных одновременно регистрировать продолжения. И в дополнение к ожиданию и поддержке асинхронных уведомлений о завершении, они также поддерживают модель блокировки, при этом синхронные абоненты могут ожидать получения результата. Ничто из этого не относится к ValueTask и ValueTask. Потому что они могут быть поддержаны сбрасываемыми экземплярами IValueTaskSource, вы не должны их кэшировать (то, что они переносят, может быть использовано повторно) и не ждать их несколько раз. Вы не должны пытаться зарегистрировать несколько продолжений (после первого завершения объект может попытаться сбросить себя для другой операции), будь то одновременно или нет. И вы не должны пытаться блокировать ожидание их завершения (реализации IValueTaskSource не должны предоставлять такую семантику). Пока вызывающие абоненты напрямую ожидают результата вызова метода, который возвращает  ValueTask или ValueTask, все должно работать хорошо, но как только кто-то сходит с этого золотого пути, все может быстро измениться; это может означать получение исключений или коррупцию в процессе. Кроме того, эти сложности обычно проявляются только тогда, когда ValueTask или ValueTask переносят реализацию IValueTaskSource; когда они переносят Task, вещи обычно «просто работают», так как ValueTask наследует надежность Task, и когда они оборачивают необработанное значение результата, ограничения технически вообще не применяются. И это означает, что, переключая асинхронные методы async ValueTask с поддержкой Task, вместо поддержки этих объединенных реализаций IValueTaskSource, мы могли бы выявлять скрытые ошибки в приложении разработчика, либо напрямую, либо через библиотеки, которые они используют. Предстоящий выпуск Roslyn Analyzers будет включать в себя анализатор, который должен помочь найти большинство нецелевых использований.

Призыв к действию

Если у вас есть приложение, которому, по вашему мнению, будет полезно это объединение, мы будем рады получить от вас сообщение. Скачивайте .NET 5 Preview 1. Попробуйте включить эту функцию. Что-нибудь сломается, в вашем коде, или в другой библиотеке, или в самом .NET. Или вы увидите значительные изменения в производительности, такие как пропускная способность или задержка, или рабочий набор, или что-то еще интересное. Обратите внимание, что изменение касается только асинхронных методов async ValueTask и async ValueTask, поэтому, если у вас есть async Task или async Task, вам также может потребоваться сначала изменить их, чтобы использовать их эквиваленты ValueTask.

Выпуск dotnet / runtime # 13633 отбражает виденье того, что мы должны делать с этой функцией для .NET 5, и Microsoft хочет услышать ваш фидбек; команда будет рада, если вы опубликуете какие-либо мысли или результаты.


Источник



Posted on 17. January 2020

Получение и анализ дампов памяти

Опираясь на улучшения диагностики, представленные в .NET Core 3.1, мы представили новый инструмент для сбора дампов кучи из запущенного процесса .NET Core.

В предыдущем посте мы представили dotnet-dump, инструмент, позволяющий вам собирать и анализировать дампы процессов. С тех пор мы усердно работали над улучшением работы с дампами.

Два ключевых улучшения, которые мы внесли в dotnet-dump:

Нам больше не требуется sudo  для сбора дампов в Linux

dotnet dump analyze теперь поддерживается в Windows

GC дампы

Однако одно из ключевых ограничений, которое остается, - это то, что дампы процессов не переносимы. Невозможно диагностировать дампы, собранные в Linux с помощью Windows и наоборот.

Многие распространенные сценарии не требуют полной проверки дампа процесса. Чтобы включить эти сценарии, мы представили новый облегченный механизм сбора дампа, который является переносимым. Запустив сборку мусора в целевом процессе, мы можем осуществлять потоковую передачу событий, генерируемых сборщиком мусора, через механизм Existing EventPipe для восстановления графика корней объектов из этих событий.

Эти дампы GC полезны для нескольких сценариев, включая:

Сравнение количества объектов по типу в куче

Анализ корней объекта

Нахождение каких объектов имеет ссылку на какой тип

Другой статистический анализ об объектах в куче

dotnet-gcdump

 

В .NET Core 3.1 мы представляем новый инструмент, который позволяет вам захватывать вышеупомянутые дампы процессов для анализа в PerfView и Visual Studio.

Вы можете установить этот глобальный инструмент .NET, выполнив следующую команду:

dotnet tool install --global dotnet-gcdump

 

Установив dotnet gcdump, вы можете перехватить дамп GC, выполнив следующую команду:

dotnet gcdump collect -p <target-process-PID>

 

Примечание: Сбор gcdump запускает полную сборку мусора Gen 2 в целевом процессе и может изменить характеристики производительности вашего приложения. Продолжительность паузы GC, испытываемая приложением, пропорциональна размеру кучи GC; приложения с большими кучами будут испытывать более длительные паузы.

Полученный файл.gcdump можно проанализировать в Visual Studio и PerfView в Windows.

Анализ дампов GC в Visual Studio

Собранные дампы GC можно проанализировать, открыв файлы .gcdumpв Visual Studio. После открытия в Visual Studio вы попадаете на страницу отчета об анализе памяти.

В верхней панели отображается количество и размер типов в снимке, включая размер всех объектов, на которые ссылается тип (Inclusive Size).

В нижней панели дерево Paths to Root отображает объекты, которые ссылаются на тип, выбранный в верхней панели. В дереве ссылочных типов отображаются ссылки, содержащиеся в типе, выбранном в верхней панели.

В дополнение к отчету об анализе памяти только одного дампа GC, Visual Studio также позволяет сравнивать два дампа GC. Чтобы просмотреть подробную информацию о разнице между текущим снимком и предыдущим снимком, перейдите в раздел отчета Compare To и выберите другой дамп GC, который будет использоваться в качестве базовой линии.

Заключение

Спасибо за опробование новых инструментов диагностики в .NET Core 3.1. Пожалуйста, продолжайте оставлять свои отзывы, либо в комментариях, либо на GitHub Мы внимательно прислушиваемся к вашим отзывам и будем вносить изменения.

 

Источник



Posted on 12. December 2019

Знакомство с System.Threading.Channels

Проблемы «производитель / потребитель» существуют везде, во всех аспектах нашей жизни. Последовательность приготовления заказа в заведениях быстрого питания: повар, нарезающий помидоры, которые передаются другому который складывает гамбургер, который предают работнику выдачи вашего заказа, который вы после с удовольствием съедаете. Почтовые водители доставляют почту по всем своим маршрутам, вы либо наблюдаете за прибывшим грузовиком и забираете свои посылки, либо же проверяете ящик придя с работы. Сотрудник авиакомпании выгружает чемоданы из грузового отсека реактивного лайнера, помещая их на конвейерную ленту, где они доставляются другому работнику, который переносит сумки в фургон и доставляет их на еще один конвейер, который привезет их к вам. Счастливая пара готовится разослать приглашения на свою свадьбу, причем один партнер закрывает конверты, передает другому который заклеивает и кладет в ящик.

Как разработчики программного обеспечения, регулярно наблюдаем, как события из нашей повседневной жизни проникают в наше программное обеспечение, и проблемы «производитель/потребитель» не являются исключением. Любой, кто собирал команды в командной строке, использовал производителя/потребителя, причем стандартный вывод одной программы передается как стандартный ввод другой. Любой, кто запустил несколько загрузок данных с нескольких сайтов или вычисления дискретных задач использовал метод производитель/потребитель, с потребителем агрегируя результаты для отображения или дальнейшей обработки.  Кто пытался распараллелить конвейер, явно использовал этот метод. И так далее.

У всех этих сценариев, происходящих в реальной жизни или в жизни программного обеспечения, есть что-то общее: есть какой-то механизм для передачи результатов от производителя к потребителю. Сотрудник фаст-фуда кладет гамбургеры на полку, из которой возьмет их другой работник, для выдачи заказа клиенту. Работник почты кладет посылки в почтовый ящик. Руки помолвленной пары встречаются, чтобы передать материалы от одного к другому. В программном обеспечении такая передача требует некоторой структуры данных для облегчения транзакции, хранилища, которое может использовать производитель для передачи результата и, возможно, буферизовать больше, в то же время позволяя потребителю получать уведомление о наличии одного или нескольких результатов. Вступление в System.Threading.Channels.

Что такое Канал?

Мне часто проще понять некоторые технологии, реализовав для себя простую версию. При этом я узнаю о различных проблемах, которые разработчики этой технологии, возможно должны были устранить, и о наилучшем способе использования функционала.  Для этого давайте начнем знакомство с System.Threading.Channels, реализовав «канал» с нуля.

Канал - это просто структура данных, используемая для хранения полученных данных для извлечения потребителем, и соответствующая синхронизация, позволяющая это безопасно выполнять, одновременно с включением соответствующих уведомлений в обоих направлениях. Существует множество возможных проектных решений. Должен ли канал содержать неограниченное количество элементов? Что должно произойти, когда он заполняется? Насколько критична производительность? Нужно ли пытаться минимизировать синхронизацию?  Можем ли сделать какие-либо предположения о том, сколько производителей и потребителей может быть допущено одновременно? В целях быстрого написания простого канала, давайте сделаем упрощающие предположения, что нам не нужно применять какие-либо конкретные ограничения и что нам не нужно слишком беспокоиться о дополнительных расходах. Разработчики также составили простой API.

Для начала нам нужен наш тип, к которому добавим несколько простых методов:

public sealed class Channel<T>

{

    public void Write(T value);

    public ValueTask<T> ReadAsync(CancellationToken cancellationToken = default);

}

 

Метод Write позволяет нам его использовать для вывода данных в канал, и ReadAsync метод дает нам потреблять от него. Так как решили, что наш канал неограничен, ввод данных в него всегда завершается успешно и синхронно, так же, как запрос Add в List<T> поэтому сделали его не асинхронным и возвращающим пустоту. В противоположность, наш метод использования это ReadAsync который является асинхронным, потому что данные, которые хотим использовать, могут быть еще не доступны, и, таким образом, нам нужно будет дождаться их обновлений.  И пока начинаем разработку, не слишком обеспокоены производительностью, также не хотим иметь много ненужных дополнительных расходов. Так как ожидаем, что будем читать, данные которые уже доступны для использования, метод ­­­­­ ReadAsync возвращает ValueTask<T> а не к Task<T>, так что можем сделать это без выделения при синхронном завершении.

Теперь нам просто нужно реализовать эти два метода. Для начала добавим два поля к нашему типу: один, будет служить механизмом хранения, и вотрой для координации между производителями и потребителями:

private readonly ConcurrentQueue<T> _queue = new ConcurrentQueue<T>();
private readonly SemaphoreSlim _semaphore = new SemaphoreSlim(0);

Используем ConcurrentQueue<T> для хранения данных, освобождая нас от необходимости делать собственную блокировку для защиты структуры данных буферизации, такую как ConcurrentQueue<T> она является потоко-безопасной для любого количества производителей/потребителей. И используем SempahoreSlim он помогает координировать между производителями и потребителей и уведомлять потребителей о поступлении дополнительных данных.

Наш метод Write прост. Ему нужно сохранить данные в очереди и увеличить счетчик SemaphoreSlim, “публикуя” его:

public void Write(T value)
{
    _queue.Enqueue(value); // store the data
    _semaphore.Release(); // notify any consumers that more data is available
}

 

Метод ReadAsync почти так же прост. Нужно подождать, пока данные будут доступны, а затем вынуть их.

public async ValueTask<T> ReadAsync(CancellationToken cancellationToken = default)
{
    await _semaphore.WaitAsync(cancellationToken).ConfigureAwait(false); // wait
    bool gotOne = _queue.TryDequeue(out T item); // retrieve the data
    Debug.Assert(gotOne);
    return item;
}

 

Обратите внимание, поскольку никакой другой код не может управлять семафором или очередью, как только мы успешно дождались на семафор, в очереди будут данные, чтобы передать их нам, вот почему мы можем просто утверждать, что метод TryDequeue успешно вернулся. 

На этом то все: у нас есть основной канал. Если все, что вам нужно, это базовые функции, такая реализация вполне разумна. Разумеется, требования часто более значимы как для производительности, так и для API, необходимых для обеспечения большего количества сценариев.

Теперь, когда понимаем основы того, что предоставляет канал, можем перейти к рассмотрению реальных API-интерфейсов System.Threading.Channel.

 

Представляем System.Threading.Channels

Основные абстракции, представленные в библиотеке System.Threading.Channels, написаны так:

public abstract class ChannelWriter<T>
{
    public abstract bool TryWrite(T item);
    public virtual ValueTask WriteAsync(T item, CancellationToken cancellationToken = default);
    public abstract ValueTask WaitToWriteAsync(CancellationToken cancellationToken = default);
    public void Complete(Exception error);
    public virtual bool TryComplete(Exception error);
}

 

и читается:

public abstract class ChannelReader<T>
{
    public abstract bool TryRead(out T item);
    public virtual ValueTask<T> ReadAsync(CancellationToken cancellationToken = default)
    public abstract ValueTask WaitToReadAsync(CancellationToken cancellationToken = default);
    public virtual IAsyncEnumerable<T> ReadAllAsync([EnumeratorCancellation] CancellationToken cancellationToken = default);
    public virtual Task Completion { get; }
}

 

Только что завершил свою собственную разработку и внедрение простого канала, большая часть поверхности API должна быть знакома. ChannelWriter<T> обеспечивает метод TryWrite, который очень похож на наш метод записи; тем не менее, это абстрактно и метод проб, который возвращает Boolean учитывать тот факт, что некоторые реализации могут быть ограничены в количестве элементов они могут на нем храниться и если канал был заполнен так, что запись не могла завершиться синхронно, TryWrite потребуется вернуть false, чтобы указать, что запись была неудачной.  Тем не менее ChannelWriter<T> также обеспечивает метод WriteAsync; в таком случае, канал переполнен и запись должна ждать (часто упоминается как «обратное воздействие»), можно использовать WriteAsync, с производителем в ожидании результата WriteAsync его можно будет использовать, только когда пространство освободиться.

Конечно, бывают ситуации, когда код может не сразу создать значение; если полученные значения будут дорогим или если значение, представляет собой дорогой ресурс, (к примеру, это большой объект, который занял бы много памяти, или, может быть, он хранит кучу открытых файлов) в таких случаях, производитель работает быстрее, чем потребитель, производитель может захотеть отложить создание значения, пока не убедиться, что запись будет успешной. Для этого, есть соответствующий сценарий WaitToWriteAsync. Создатель может ожидать WaitToWriteAsync возвращение true, и только затем создатель выбирает значение TryWrite или WriteAsync на канал.

Обратите внимание что, WriteAsync виртуальный. Некоторые ее осуществления могут выбрать более оптимизированные переходы, но с абстрактным TryWrite и WaitToWriteAsync, базовый тип может обеспечить благоразумную реализацию, что немного сложнее, чем эта:

public async ValueTask WriteAsync(T item, CancellationToken cancellationToken)
{
    while (await WaitToWriteAsync(cancellationToken).ConfigureAwait(false))
        if (TryWrite(item))
            return;
 
    throw new ChannelCompletedException();
}

 

В дополнение к обзору WaitToWriteAsync и TryWrite  можно использовать, это позволит подчеркнуть несколько дополнительных интересных вещей. Во-первых, здесь присутствует цикл, потому что каналы по умолчанию могут использоваться любым количеством производителей и любым количеством потребителей одновременно. Если канал имеет верхнюю границу для количества элементов, которые он может хранить,  если несколько потоков стремятся записаться в буфер, это возможно для двух потоков, если есть место используя WaitToWriteAsync. 

В этом примере также показано, почему WaitToWriteAsync возвращает ValueTask<bool> вместо ValueTask, а также ситуации за пределами полного буфера, в которых TryWrite может возвращать false. Каналы поддерживают концепцию завершения, когда производитель может сигнализировать потребителю, что больше не будет произведено никаких товаров, что позволяет потребителю прекратить попытки потреблять. Это делается с помощью методов Complete или TryComplete , ранее показанных на ChannelWriter<T> (Complete  реализован для вызова TryComplete  и throw, если он возвращает false). Но если один продюсер помечает канал как завершенный, другим продюсерам нужно знать, что они больше не могут писать в канал; в этом случае TryWrite возвращает false, WaitToWriteAsync также возвращает false, а WriteAsync генерирует исключение ChannelCompletedException.

Большинство членов ChannelReader<T>, вероятно, тоже говорят сами за себя.TryRead  попытается синхронно извлечь следующий элемент из канала. ReadAsync также извлекает следующий элемент из канала, но если элемент не может быть получен синхронно, он возвращает задачу. И WaitToReadAsync возвращает ValueTask<bool>, который служит уведомлением о доступе элемента. Как и в случае WriteAsync для ChannelWriter<T>, ReadAsync является виртуальным, с базовой реализацией, осуществляемой в терминах абстрактных TryRead  и WaitToReadAsync; это не точная реализация в базовом классе, но очень близка:

public async ValueTask<T> ReadAsync(CancellationToken cancellationToken)
{
    while (true)
    {
        if (!await WaitToReadAsync(cancellationToken).ConfigureAwait(false))
            throw new ChannelClosedException();
 
        if (TryRead(out T item))
            return item;
    }
}

 

Существует множество типичных шаблонов того, как использовать канал ChannelReader<T>. Если он представляет собой бесконечный поток значений, один из подходов состоит в том, чтобы просто сидеть в бесконечном цикле потребителя через ReadAsync:

while (true)
{
    T item = await channelReader.ReadAsync();
    Use(item);
}

 

Конечно, если поток значений не является бесконечным и канал будет в какой-то момент помечен как завершенный, после того как потребители очистят канал от всех своих данных, последующие попытки чтения из него будут отброшены. Напротив, TryRead  вернет false, как и WaitToReadAsync. Итак, более распространенная модель потребления - через вложенный цикл:

while (await channelReader.WaitToReadAsync())
    while (channelReader.TryRead(out T item))
        Use(item);

 

Вместо этого внутреннее «while» могло бы быть простым «if», но наличие тесного внутреннего цикла позволяет экономному разработчику избегать небольших дополнительных издержек WaitToReadAsync, так что TryRead будет успешно использовать этот элемент. Фактически, это точный шаблон, используемый методом ReadAllAsync. ReadAllAsync был представлен в .NET Core 3.0 и возвращает IAsyncEnumerable<T>. Это позволяет всем данным быть прочитанными из канала, используя знакомые языковые конструкции:

await foreach (T item in channelReader.ReadAllAsync())
    Use(item);

 

А базовая реализация виртуального метода использует точный шаблон вложенного цикла, показанный ранее с WaitToReadAsync и TryRead:

public virtual async IAsyncEnumerable<T> ReadAllAsync(
    [EnumeratorCancellation] CancellationToken cancellationToken = default)
{
    while (await WaitToReadAsync(cancellationToken).ConfigureAwait(false))
        while (TryRead(out T item))
            yield return item;
}

 

Последняя часть ChannelReader это Completion. Возвращает Task, который будет выполнено после завершения чтения канала. Это означает, что писатель отметил, что канал завершен, и все данные были использованы.

Реализация встроенных каналов

Итак, мы знаем, как писать писателям и читать письма от читателей ... но откуда мы берем этих писателей и читателей? 

Тип Channel<TWrite, TRead> предоставляет свойство Writer и свойство Reader, которое возвращает ChannelWriter<TWrite> и ChannelReader<TRead>  соответственно:

public abstract class Channel<TWrite, TRead>
{
    public ChannelReader<TRead> Reader { get;  }
    public ChannelWriter<TWrite> Writer { get; }
}

 

Этот базовый абстрактный класс доступен для нишевых случаев использования, когда канал сам может преобразовать записанные данные в другой тип для потребления, но в большинстве случаев использование TWrite и TRead совпадают, поэтому использование большинства происходит через производную Тип канала, который не более чем:

public abstract class Channel<T> : Channel<T, T> { }

 

Нетипичный Channel type обеспечивает фабрики для нескольких реализаций Channel<T>:

public static class Channel
{
    public static Channel<T> CreateUnbounded<T>();
    public static Channel<T> CreateUnbounded<T>(UnboundedChannelOptions options);
 
    public static Channel<T> CreateBounded<T>(int capacity);
    public static Channel<T> CreateBounded<T>(BoundedChannelOptions options);
}

 

Метод CreateUnbounded создает канал без ограничения на количество элементов, которые могут быть сохранены (конечно, в какой-то момент он может выйти за лимит памяти, так же, как с List<T> любые другие подборки), очень похоже на канальный тип, который реализовали в начале этого поста. TryWrite всегда возвращает true, и оба его WriteAsync и WaitToWriteAsync будут всегда завершаться синхронно.

Метод CreateBounded создает канал с явным ограничением. Как и в случае CreateUnbounded, TryWrite возвращает значение true, и WriteAsync и WaitToWriteAsync завершатся синхронно. Но как только канал заполняется, TryWrite возвращает false, и WriteAsync и WriteAsync завершаются асинхронно, выполняя свои возвращенные задачи только при наличии свободного места. (Само собой разумеется, что все эти API, которые принимают CancellationToken, также могут быть прерваны запросом отмены).

В CreateUnbounded, и CreateBounded есть перегрузки, которые принимает тип ChannelOption. Эта базовая опция предоставляет параметры, которые могут контролировать поведение любого канала. Например, он предоставляет свойства SingleWriter и SingleReader, которые позволяют создателю указывать ограничения, которые они готовы принять; разработчик устанавливает для SingleWriter значение true, чтобы указать, что один производитель будет одновременно обращаться к устройству записи, и аналогичным образом устанавливает для SingleReader значение true, чтобы указать, что не более одного потребителя будет одновременно обращаться к читателю. Это позволяет методам специализировать созданную реализацию, оптимизируя ее на основе предоставленных опций; например, если параметры, переданные CreateUnbounded, указывают на SingleReader как true, он возвращает реализацию, которая также позволяет избежать операций с блокировкой при чтении, что значительно снижает накладные расходы, связанные с потреблением из канала. Базовые ChannelOptions также предоставляют свойство AllowSynchronousContinuations. Как и в случае с SingleReader и SingleWriter, по умолчанию используется значение false, а для создателя значение true означает подписку на некоторые оптимизации, которые также имеют серьезные последствия для написания кода.  В частности, AllowSynchronousContinuations в некотором смысле позволяет производителю временно стать потребителем. Допустим, в канале нет данных, и потребитель приходит и вызывает ReadAsync. Ожидая задачу, возвращенную из ReadAsync, этот потребитель эффективно подключает обратный вызов, который будет вызываться при записи данных в канал. По умолчанию этот обратный вызов будет вызываться асинхронно, при этом производитель записывает данные в канал, а затем ставит в очередь вызов этого обратного вызова, что позволяет производителю одновременно идти своим путем, пока потребитель обрабатывается каким-то другим потоком. Однако в некоторых ситуациях для производительности может быть выгодно, чтобы этот производитель, записывающий данные, также сам обрабатывал обратный вызов, например, вместо того, чтобы TryWrite ставил в очередь вызов обратного вызова, он просто вызывает сам обратный вызов. Это может значительно сократить накладные расходы, но также требует глубокого понимания окружающей среды, так как, например, если вы удерживали блокировку при вызове TryWrite, а для параметра AllowSynchronousContinuations установлено значение true, вы можете в конечном итоге вызвать обратный вызов, удерживая блокировку, который (в зависимости от того, что пытался сделать обратный вызов) можете в конечном итоге наблюдать за некоторыми сломанными инвариантами, которые пытается поддерживать ваша блокировка.

BoundedChannelOptions передается слоям CreateBounded для дополнительных опций, связанных с ограничением. В дополнение к максимальной емкости, поддерживаемой каналом, он также предоставляет перечисление BoundedChannelFullMode, которое указывает, что записи поведения должны возникать при заполнении канала:

  public enum BoundedChannelFullMode
{
    Wait,
    DropNewest,
    DropOldest,
    DropWrite
}

 

TryWrite  на полном канале возвращает false, WriteAsync  вернет задачу, которая будет выполнена только тогда, когда освободится место, и запись может быть успешно завершена, и аналогично WaitToWriteAsync  будет завершена только тогда, когда пространство станет доступным. Вместо этого в трех других режимах запись всегда выполняется синхронно, удаляя элемент, если канал заполнен. DropOldest удалит «самый старый» элемент из очереди, что означает, что какой-либо элемент будет в дальнейшем удален потребителем. И наоборот, DropNewest удалит новый элемент, какой элемент был записан в канал в последний раз. И DropWrite удаляет элемент, который в данный момент пишется, то есть, например, TryWrite вернет true, но добавленный элемент будет немедленно удален.

Выполнение

С точки зрения API, представленные абстракции относительно просты, что является большой частью того, откуда исходит сила библиотеки. Простые абстракции и несколько конкретных реализаций, которые должны удовлетворять потребности разработчиков на 99,9%. Конечно, площадь поверхности библиотеки может указывать на простоту реализации. По правде говоря, в реализации есть приличная сложность, в основном сфокусированная на обеспечении высокой пропускной способности при одновременном использовании простых шаблонов потребления, легко используемых в потреблении кода. Реализация, например, делает все возможное, чтобы минимизировать распределение. Возможно, вы заметили, что многие методы возвращают ValueTask и ValueTask<T>, а не Task и Task<T>. Как увидели в нашем тривиальном примере реализации в начале этой статьи, мы можем использовать ValueTask<T>, чтобы избежать выделения при синхронном завершении методов, но реализация System.Threading.Channels также использует расширенные интерфейсы IValueTaskSource и IValueTaskSource<T>, чтобы избежать выделения ресурсов даже когда различные методы завершаются асинхронно и нужно возвращать задачи.

Рассмотрим этот тест:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System.Threading.Channels;
using System.Threading.Tasks;
 
[MemoryDiagnoser]
public class Program
{
    static void Main() => BenchmarkRunner.Run();
 
    private readonly Channel s_channel = Channel.CreateUnbounded();
 
    [Benchmark]
    public async Task WriteThenRead()
    {
        ChannelWriter writer = s_channel.Writer;
        ChannelReader reader = s_channel.Reader;
        for (int i = 0; i < 10_000_000; i++)
        {
            writer.TryWrite(i);
            await reader.ReadAsync();
        }
    }
}

 

Здесь мы просто тестируем пропускную способность и распределение памяти на неограниченном канале при записи элемента, а затем читаем этот элемент 10 миллионов раз, это означает, что элемент всегда будет доступен для чтения, и, таким образом, чтение всегда будет завершаться синхронно, что дает следующие результаты на моем компьютере (72 байта, показанные в столбце Allocated, предназначены для одной Задачи, возвращенной из WriteThenRead):

 

Method                                          Mean                            Error StdDev Gen 0    Gen 1    Gen 2    Allocated

WriteThenRead                           527.8 ms                    2.03 ms              1.90 ms                                                       72 B

Но теперь давайте немного его изменим, сначала выполняя чтение, и только потом записывая элемент, который его удовлетворит. В этом случае чтение всегда завершается асинхронно, потому что данные для их завершения никогда не будут доступны:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System.Threading.Channels;
using System.Threading.Tasks;
 
[MemoryDiagnoser]
public class Program
{
    static void Main() => BenchmarkRunner.Run();
 
    private readonly Channel s_channel = Channel.CreateUnbounded();
 
    [Benchmark]
    public async Task ReadThenWrite()
    {
        ChannelWriter writer = s_channel.Writer;
        ChannelReader reader = s_channel.Reader;
        for (int i = 0; i < 10_000_000; i++)
        {
            ValueTask vt = reader.ReadAsync();
            writer.TryWrite(i);
            await vt;
        }
    }
}

 

который на моей машине за 10 миллионов операций записи и чтения дает такие результаты:

Method                                          Mean                            Error StdDev Gen 0    Gen 1    Gen 2    Allocated

ReadThenWrite                           881.2 ms                    4.60 ms              4.30 ms                                                       72 B

 

Итак, есть некоторые дополнительные издержки, когда каждое чтение завершается асинхронно, но даже здесь мы видим нулевое распределение для 10 миллионов асинхронно завершающих чтений (опять же, 72 байта, показанные в столбце Allocated, предназначены для Задачи, возвращаемой из ReadThenWrite)!

Комбинаторы

Обычно потребление каналов является простым, используя один из подходов, показанных ранее. Но, как и в случае с IEnumerables, можно также выполнять различные виды операций по каналам для достижения определенной цели. Например, допустим, я хочу дождаться поступления первого элемента от одного из двух предоставленных читателей; Я мог бы написать что-то вроде этого:

public static async ValueTask> WhenAny(
    ChannelReader reader1, ChannelReader reader2)
{
    var cts = new CancellationTokenSource();
    Task t1 = reader1.WaitToReadAsync(cts.Token).AsTask();
    Task t2 = reader2.WaitToReadAsync(cts.Token).AsTask();
    Task completed = await Task.WhenAny(t1, t2);
    cts.Cancel();
    return completed == t1 ? reader1 : reader2;
}

 

Здесь мы просто запрашиваем WaitToReadAsync на обоих каналах и возвращаем считыватель в зависимости от того, что завершается первым. Одна из интересных вещей, которую стоит отметить в этом примере, это то, что в то время как ChannelReader<T> имеет много общего с IEnumerator<T>, этот пример не может быть хорошо реализован поверх IEnumerator<T> (или IAsyncEnumerator<T>).

I{Async}Enumerator<T> предоставляет метод MoveNext{Async}, который перемещает курсор вперед к следующему элементу, который затем открывается из Current. Если бы мы попытались реализовать такой WhenAny поверх IAsyncEnumerator<T>, нам нужно было бы вызвать MoveNextAsync для каждого. При этом мы потенциально могли бы перейти к следующему пункту. Если бы мы затем использовали этот метод в цикле, мы, скорее всего, в конечном итоге пропустили бы элементы из одного или обоих перечислителей, потому что мы потенциально могли бы расширить перечислитель, который мы не вернули из метода.

Отношение к остальной части .NET Core

System.Threading.Channels является частью общей платформы .NET Core, что означает, что приложение .NET Core может начать использовать его, не устанавливая ничего дополнительного. Он также доступен в виде отдельного пакета NuGet, хотя отдельная реализация не имеет всех оптимизаций, в значительной степени потому, что встроенная реализация может использовать преимущества дополнительной среды выполнения и поддержки библиотеки. NET Core.

Он также используется множеством других систем в .NET. Например, ASP.NET использует каналы как часть SignalR, а также в своей транспортировке Kestrel на основе Libuv. Каналы также используются будущей реализацией QUIC, которая в настоящее время разрабатывается для .NET 5.

Библиотека System.Threading.Channels также выглядит немного похожей на библиотеку System.Threading.Tasks.Dataflow, которая уже много лет доступна в .NET. В некотором смысле библиотека потоков данных является расширенным набором библиотеки каналов; в частности, тип BufferBlock<T> из библиотеки потока данных предоставляет большую часть той же функциональности. Однако библиотека потоков данных также ориентирована на другую модель программирования, в которой блоки связаны между собой так, что данные автоматически передаются от одного к другому. Он также включает расширенные функциональные возможности, которые поддерживают, например, форму двухфазной фиксации, с несколькими блоками, связанными с одними и теми же потребителями, и теми пользователями, которые позволяют извлекать механизмы из нескольких блоков без блокировки, которые необходимы для его включения, гораздо более сложны, и, в то же время, более мощные и более дорогие. Это очевидно, просто написав такой же тест для BufferBlock<T>, как мы делали ранее для каналов.

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System.Threading.Channels;
using System.Threading.Tasks;
using System.Threading.Tasks.Dataflow;
 
[MemoryDiagnoser]
public class Program
{
    static void Main() => BenchmarkRunner.Run();
 
    private readonly Channel _channel = Channel.CreateUnbounded();
    private readonly BufferBlock _bufferBlock = new BufferBlock();
 
    [Benchmark]
    public async Task Channel_ReadThenWrite()
    {
        ChannelWriter writer = _channel.Writer;
        ChannelReader reader = _channel.Reader;
        for (int i = 0; i < 10_000_000; i++)
        {
            ValueTask vt = reader.ReadAsync();
            writer.TryWrite(i);
            await vt;
        }
    }
 
    [Benchmark]
    public async Task BufferBlock_ReadThenWrite()
    {
        for (int i = 0; i < 10_000_000; i++)
        {
            Task t = _bufferBlock.ReceiveAsync();
            _bufferBlock.Post(i);
            await t;
        }
    }
}

 

 

Method                                          Mean                            Error StdDev Gen 0    Gen 1    Gen 2    Allocated

Channel_ReadThenWrite       878.9 ms                    0.68 ms              0.60 ms                72 B                                 72 B

BufferBlock_ReadThenWrite                                  20,116.4 ms         192.82 ms           180.37 ms           1184000.0000    2000.0000                                                                                        7360000232 B

 

Это не означает, что библиотека System.Threading.Tasks.Dataflow не должна использоваться. Он позволяет разработчикам кратко выражать большое количество концепций и может демонстрировать очень хорошую производительность применительно к задачам, которые ему наиболее подходят. Однако, когда все, что вам нужно, - это структура передачи данных между одним или несколькими производителями и одним или несколькими потребителями, которую вы внедрили вручную, System.Threading.Channels - гораздо более компактная и экономная ставка.

Что же дальше?

Надеюсь, на данный момент вы более детально разобрались в библиотеке System.Threading.Channels и сможете с ее помощью улучшить ваши приложения. Попробуйте, и будем рады вашим отзывам, предложениям, проблемам и PR, чтобы улучшить ее

https://github.com/dotnet/runtime.

Источник

 



Posted on 25. June 2019

Выпуск .NET Core 3.0 Preview 5

Совсем недавно вышел .NET Core 3.0 Preview 5. Он содержит новый Json сериализатор, поддержку публикации исполняемых файлов из одного файла, обновление для отката времени выполнения и изменения в BCL. Не забудьте ознакомиться с улучшениями в .NET Core 3.0 Preview 4.

Загрузите .NET Core 3.0 Preview 5 на Ваш Windows, macOS и Linux уже сейчас.

Также были обновлены ASP.NET Core и EF Core.

WPF и Windows Forms Обновления

Вы должны увидеть улучшение производительности при запуске  WPF и Windows Forms. Сборки WPF и Windows Forms теперь скомпилированы заранее, с использованием crossgen. Многие пользователи уже заметили улучшения при запуске между Preview 4 и Preview 5.

Было опубликовано больше WPF кода как часть .NET Core 3.0 Preview 4. Уже в Preview 7 будет окончательная WPF публикация.

Новый SqlClient

SqlClient - это поставщик данных, который Вы используете для доступа к SQL Server и базе данных SQL Azure либо через один из популярных .NET O/RM, например EF Core или Dapper, либо напрямую через API-интерфейсы ADO.NET.

В течение многих лет SqlClient поставлялся как часть сборки System.Data.dll в .NET Framework. Каждый раз, когда для использования новых функций SQL Server требовались изменения в SqlClient, приходилось ждать возможности, чтобы обновить .NET Framework на Windows. Раньше это работало нормально, поскольку новые функции SQL Server по-прежнему регулярно выпускались, разработка новых функций переходила на .NET Core и все вело к улучшению стабильности .NET Framework, и было больше смысла выводить разработку SqlClient из-под диапазона.

Введите Microsoft.Data.SqlClient, новую версию SqlClient, которую Вы можете добавить как NuGet пакет в .NET Framework и .NET Core (включая .NET Core 3.0) приложениях, которые сегодня запускаются в режиме предварительного просмотра.

Что нового в Microsoft.Data.SqlClient?

Отсутствие поддержки Always Encrypted в .NET Core было основной проблемой, которая была решена в этом предварительном просмотре.

Также ведется работа над двумя новыми функциями, доступными как для .NET Framework, так и для .NET Core:

  • Классификация данных
  • Поддержка UTF-8

В настоящее время планируется выпустить эти и другие улучшения в Microsoft.Data.SqlClient в те же сроки, что и в .NET Core 3.0.

Что значит для System.Data.SqlClient?

System.Data.SqlClient по-прежнему будет поддерживаться и получать важные обновления безопасности, поэтому нет необходимости перемещения, если Ваше приложение взаимодействует с ним. Но если Вы хотите воспользоваться новыми функциями, Вам следует рассмотреть обновление к Microsoft.Data.SqlClient. Процесс должен быть простым для многих приложений: просто установите пакет и обновите пространство SqlClient имен в Вашем коде. В некоторых других случаях потребуются изменения в конфигурации или обновленных O/RM версиях, которые зависят от нового SqlClient.

Следите за этим блог постом, чтобы узнать больше информации о новом SqlClient.

Публикация отдельных EXE-файлов

Теперь Вы можете публиковать однофайловый исполняемый файл с помощью dotnet publish. Эта форма одиночного EXE-файла - фактически самораспаковывающийся исполняемый файл. Он содержит все зависимости, включая нативные зависимости, в качестве ресурсов. При запуске он копирует все зависимости во временный каталог и загружает их туда. Распаковать зависимости нужно всего один раз. После этого запуск происходит быстро и просто.

Вы можете включить этот параметр публикации, добавив свойство PublishSingleFile в файл проекта или добавив новый параметр в командной строке.

К примеру, чтобы создать отдельное EXE-приложение для 64-разрядной Windows версии:

dotnet publish -r win10-x64 /p:PublishSingleFile=true

Отдельные EXE-приложения должны соответствовать архитектуре. В результате необходимо указать идентификатор времени выполнения.

Смотрите Single file bundler для получения дополнительной информации.

Триммер сборки, преждевременная компиляция (через кроссген) и объединение отдельных файлов - новые функции в .NET Core 3.0, которые можно использовать вместе или по отдельности. Ожидайте услышать больше об этих трех особенностях в будущих preview-версиях.

Ожидается, что многие из Вас предпочтут один exe-файл, предоставляемый заранее установленным компилятором, а не самораспаковывающийся-исполняемый подход в .NET Core 3.0. Опережающий подход к компиляции будет предоставлен как часть .NET 5 выпуска.

JSON Сериализатор

Новый JSON сериализатор расположен поверх высокопроизводительных Utf8JsonReader и Utf8JsonWriter. Он десериализует объекты из JSON и сериализует объекты в JSON. Выделение памяти минимально и включает в себя поддержку чтения и записи JSON с Stream в асинхронном режиме.

Для начала используйте JsonSerializer класс в пространстве System.Text.Json.Serialization имен. Смотрите документацию с дополнительной информацией и примерами. Набор функций продолжает расширяться для будущих preview-версий.

Изменение дизайна Utf8JsonWriter

Основываясь на отзывах об удобстве использования и надежности, был внесен ряд изменений в Utf8JsonWriter дизайн, который был добавлен во второй preview-версии. Writer теперь является обычным классом, а не ref структурой, и реализует IDisposable. Это позволяет добавлять поддержку записи в потоки напрямую. Кроме того, был удален JsonWriterState, и теперь JsonWriterOptions необходимо передавать непосредственно в Utf8JsonWriter, который поддерживает свое собственное состояние. Чтобы помочь компенсировать распределение, Utf8JsonWriter имеет новый API сброса, который позволяет Вам сбросить его состояние и повторно использовать модуль записи. Также была добавлена встроенная реализация IBufferWriter с именем ArrayBufferWriter, которую можно использовать с Utf8JsonWriter. Вот фрагмент кода, который показывает изменения:

// New, built-in IBufferWriter that's backed by a grow-able array
var arrayBufferWriter = new ArrayBufferWriter();
 
// Utf8JsonWriter is now IDisposable
using (var writer = new Utf8JsonWriter(arrayBufferWriter, new JsonWriterOptions { Indented = true }))
{
 
   // Write some JSON using existing WriteX() APIs.
 
   writer.Flush(); // There is no isFinalBlock bool parameter anymore
}

Вы можете прочитать больше об изменении дизайна здесь.

Index и Range

В предыдущем предварительном просмотре платформа поддерживала Index и Range, предоставляя перегрузки общих операций, таких как индексаторы и методы, такие как Substring, которые принимали значения Index и Range. Основываясь на отзывах пользователей, все было упрощено и позволило компилятору вызывать существующие индексаторы. В документе «Index и Range изменения» содержится более подробная информация о том, как это работает, но основная идея заключается в том, что компилятор может вызывать индексатор на int основе, извлекая смещение из заданного значения Index. Это означает, что индексирование с использованием Index теперь будет работать для всех типов, которые предоставляют индексатор и имеют Count или Length свойство. Компилятор обычно не может использовать существующий индексатор для Range, потому что он возвращает только единичные значения. Однако теперь компилятор разрешает индексирование с использованием Range, когда тип предоставляет индексатор, который принимает Range, или Slice метод. Это позволяет Вам выполнять индексацию с использованием Range, а также работать с интерфейсами и типами, которые Вы не контролируете, предоставляя метод расширения.

Существующий код, использующий эти индексаторы, будет продолжать компилироваться и работать, как ожидается. Смотрите пример в этом коде:

string s = "0123456789";
char lastChar = s[^1]; // lastChar = '9'
string startFromIndex2 = s[2..]; // startFromIndex2 = "23456789"

Следующие String методы были удалены:

public String Substring(Index startIndex);
public String Substring(Range range);

Любой код, использующий эти String методы, должен быть обновлен для использования индексаторов

string substring = s[^10..]; // Replaces s.Substring(^10);
string substring = s[2..8];   // Replaces s.Substring(2..8);

Следующий Range метод ранее возвращал OffsetAndLength:

public Range.OffsetAndLength GetOffsetAndLength(int length);

Теперь он просто вернет строку:

public ValueTuple GetOffsetAndLength(int length);

Здесь продолжается компиляция и запуск, как и раньше:

(int offset, int length) = range.GetOffsetAndLength(20);

Новая японская эра (Reiwa)

1 мая 2019 года в Японии началась новая эра - так называемая Reiwa. Программное обеспечение, поддерживающее японские календари, например .NET Core, должно быть обновлено в соответствии с требованиями Reiwa. .NET Core и .NET Framework были обновлены и корректно обрабатывают японское форматирование и парсинг даных.

.NET полагается на операционную систему или другие обновления для правильной обработки Reiwa данных. Если Вы или Ваши клиенты используете Windows, загрузите последние Windows обновления. Если Вы используете macOS или Linux, загрузите и установите ICU 64.2 версию, которая поддерживает новую японскую эру.

В блог посте "Управление и переход к новой эре в японском календаре" содержит больше информации об изменениях, внесенных в .NET для поддержки новой японской эры.

Внутренние аппаратные API изменения

Avx2.ConvertToVector256* методы были изменены, чтобы возвращать подписанный тип, а не неподписанный. Это помещает их в строку с Sse41.ConvertToVector128* методами и соответствующими встроенными функциями. Например, Vector256 ConvertToVector256UInt16(Vector128) теперь является Vector256 ConvertToVector256Int16(Vector128).

Sse41/Avx.ConvertToVector128/256* методы были разделены на методы, которые принимают Vector128/256, и методы, которые принимают T*. Например, ConvertToVector256Int16(Vector128) теперь поддерживает перегрузку ConvertToVector256Int16 (byte*). Это было сделано потому, что основная инструкция, которая принимает адрес, выполняет частичное векторное чтение (а не полное векторное или скалярное чтение). Это означало, что генерирация оптимального кодирования команд не всегда была возможной и пользователю приходилось выполнять чтение из памяти. Это разделение позволяет пользователю явно выбирать форму адресации инструкции при необходимости (например, когда у Вас еще нет Vector128).

Записи перечисления FloatComparisonMode и Sse/Sse2.Compare методы были переименованы, чтобы уточнить, что операция упорядочена / неупорядочена. Они также были переупорядочены для обеспечения большего взаимодействия между SSE и AVX реализациями. Например, Sse.CompareEqualOrderedScalar теперь является Sse.CompareScalarOrderedEqual. Аналогично, для AVX версий Avx.CompareScalar (left, right, FloatComparisonMode.OrderedEqualNonSignalling) теперь Avx.CompareScalar(left, right, FloatComparisonMode.EqualOrderedNonSignalling).

Обновление политики среды выполнения .NET Core

Среда выполнения .NET Core, фактически связная среда, теперь позволяет выполнять откат до основной версии. Средство выполнения уже включает откат на исправление и второстепенные версии в качестве политики по умолчанию. В планах - не добавлять откат основной версии в качестве политики по умолчанию, хотя это важно для некоторых сценариев.

Также важно добавить обширный набор параметров конфигурации привязки во время выполнения, чтобы предоставить Вам необходимый контроль.

Существует новый RollForward, который принимает следующие значения:

  • LatestPatch — Переход к самой высокой версии. Это отключит второстепенный откат версии.
  • Minor — Переход к самой меньшей минорной версии, если запрашиваемая минорная версия отсутствует. Если запрашиваемая дополнительная версия присутствует, используется LatestPatch политика. Это политика по умолчанию.
  • Major — Переход к самой меньшей высокой версии и меньшей минорной версии, если запрашиваемая основная версия отсутствует. Если запрашиваемая основная версия присутствует, то используется дополнительная Minor политика.
  • LatestMinor — Переход к большей минорной версии, даже если запрошенная минорная версия присутствует.
  • LatestMajor — Переход к большей и большей минорной версии, даже если присутствует запрашиваемая главная версия.
  • Disable — Не откатывайтесь заранее. Привязывайтесь только к указанной версии. Эта политика не рекомендована для общего использования, так как она отключает возможность перехода к последним исправлениям. Рекомендуется только для тестирования.
Для получения дополнительной информации изучите блог посты Runtime Binding Behavior и dotnet/core-setup #5691.

Уменьшение докерных изображений .NET Core для Linux

Размер среды выполнения был сокращен примерно на 10 МБ, с помощью функции «частичного кроссгена».

По умолчанию, когда заранее компилируются сборки, также компилируются и все методы. Эти нативные скомпилированные методы увеличивают размер сборки, иногда очень сильно (затраты довольно изменчивы). Во многих случаях при запуске используется подмножество, иногда небольшое подмножество методов. Это означает, что затраты и выгода могут быть асимметричными. Частичный кроссген позволяет предварительно скомпилировать только те методы, которые имеют значение.

Запустите несколько .NET Core приложений и соберите данные о том, какие методы вызываются. Этот процесс называется «обучение». Обучающие данные называются «IBC» и используются в качестве входных данных для перекрестного анализа, чтобы определить, какие методы компилировать.

Этот процесс полезен только в том случае, если Вы изучаете продукт с помощью представительных приложений. В противном случае это может повредить запуск. В настоящее время поставлена цель, сделать образы Docker контейнеров для Linux меньше. В результате, получится только .NET Core сборка для Linux, которая меньше по размеру и где был использован частичный кроссген. Это позволяет изучать .NET Core с меньшим набором приложений, потому что сценарий относительно узок. Это обучение было сосредоточено на .NET Core SDK (например, на запуске dotnet сборки и тестировании dotnet), приложениях ASP.NET Core и PowerShell.

В будущих выпусках будет расширено использование частичного кроссгена.

Docker Обновления

Теперь поддерживаются Alpine ARM64 образы. Также Linux образ по умолчанию переключен на Debian 10 / Buster. Debian 10 еще не выпущен. Есть вероятность, что он будет выпущен до .NET Core 3.0.

Добавилась поддержка Ubuntu 19.04 / Disco. Обычно не добавляется поддержка выпусков Ubuntu, не относящихся к LTS, но поддержка 19.04 была добавлена как часть процесса готовности к Ubuntu 20.04, следующей версии LTS. Поддержка для 19.10 будет добавлена при его выпуске.

О том, как использовать .NET Core и Docker вместе, Вы можете ознакомиться подробно здесь.

Обновления AssemblyLoadContext

AssemblyLoadContext продолжает улучшаться, чтобы в будущем простые модели плагинов работали без особых усилий (или кода) с Вашей стороны, и чтобы были возможны сложные модели плагинов. В Preview 5 была добавлена неявная загрузка типов и сборок через Type.GetType, когда вызывающая сторона не является приложением, например, сериализатором.

См. документ AssemblyLoadContext.CurrentContextualReflectionContext для получения дополнительной информации.

COM-вызываемые управляемые компоненты

Теперь Вы можете создавать управляемые COM-компоненты в Windows. Эта возможность очень важна для использования .NET Core с моделями COM надстроек, а также для обеспечения паритета с .NET Framework.

В .NET Framework использовался mscoree.dll в качестве COM-сервера. Вместе с .NET Core мы предоставляем встроенную библиотеку DLL запуска, которая добавляется в каталог bin компонента при сборке COM-компонента.

Изучите COM Server Demo, чтобы опробовать эту новую возможность.

Поддержка больших GC страниц

Большие страницы (также известные как «Огромные страницы на Linux») - это функция, при которой операционная система может устанавливать области памяти, превышающие собственный размер страницы (часто 4 КБ), чтобы повысить производительность приложения, запрашивающего эти большие страницы.

Когда происходит преобразование виртуального адреса в физический, сначала обращаются к кэшу, называемому буфером просмотра трансляции (TLB), чтобы проверить, доступен ли физический перевод для виртуального адреса, к которому осуществляется доступ, чтобы избежать создания таблицы страниц. Каждый перевод большой страницы использует один буфер перевода внутри процессора. Размер этого буфера обычно на три порядка больше размера собственной страницы; это увеличивает эффективность буфера трансляции, что может повысить производительность часто используемой памяти.

Теперь GC можно настроить с помощью GCLargePages в качестве опции для выбора размещения больших страниц на Windows. Использование больших страниц уменьшает количество TLB пропусков, поэтому потенциально может повысить производительность приложений. Это, однако, идет с некоторыми ограничениями.

В заключении

Обязательно попробуйте новый выпуск .NET Core 3.0. Пожалуйста, делитесь Вашими отзывами или комментариями на GitHub. Ваш вклад важен для будущего развития!

Взгляните на .NET Core 3.0 Preview 1, Preview 2, Preview 3 и Preview 4, если Вы пропустили эти выпуски. В этом посте Вы можете узучить полный набор новых возможностей, которые были добавлены к выпуску .NET Core 3.0.



Posted on 31. May 2019

.NET Framework 4.8 [Part 2]

WCF - ServiceHealthBehavior

Конечные точки работоспособности имеют множество преимуществ и широко используются инструментами оркестровки для управления сервисом на основе состояния его работоспособности. Проверка работоспособности также может использоваться инструментами мониторинга для отслеживания и оповещения о доступности и производительности сервиса, где они работают как ранние индикаторы проблем.

ServiceHealthBehavior - это поведение WCF сервиса, которое расширяет IServiceBehavior. При добавлении в коллекцию ServiceDescription.Behaviors будет включено следующее:

  • Возвращение состояния работоспособности сервиса с помощью ответов HTTP кода. В строке запроса можно указать код HTTP состояния для выполнения запроса проверки HTTP / GET работоспособности.
  • Публикация работоспособности сервиса: специфичные для сервиса детали, включая состояние сервиса и количество дросселей, отображаются с помощью HTTP / GET-запроса, используя “?health” строку запроса. Легкий доступ к отображаемой информации важны при устранении проблем WCF сервиса.

Конфигурация ServiceHealthBehavior:

Существует два способа предоставления конечной точки работоспособности и публикации информации о работоспособности WCF сервиса: с помощью кода или с помощью файла конфигурации.

  1. Включите конечную точку работоспособности, используя код
  2. Включите конечную точку работоспособности, используя конфигурацию

Верните статус работоспособности сервиса с помощью HTTP ответов кода:

Состояние работоспособности может запрашиваться параметрами запроса (OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded). HTTP ответ кода (200 - 599) можно указать для каждого параметра запроса. Если HTTP ответ кода отсутствует для параметра запроса, по умолчанию используется 503 HTTP.

Параметры и примеры запросов:

1. OnServiceFailure: 

  • Пример: путем https://contoso:81/Service1?health&OnServiceFailure=450 запроса, код состояния HTTP-ответа 450 возвращается, когда ServiceHost.State больше, чем CommunicationState.Opened.

2. OnDispatcherFailure:

  • Пример: при запросе https://contoso:81/Service1?health&OnDispatcherFailure=455 код состояния HTTP 455 ответа возвращается, когда состояние любого из диспетчеров каналов больше, чем CommunicationState.Opened.

3. OnListenerFailure:

  • Пример: путем запроса https://contoso:81/Service1?health&OnListenerFailure=465 код состояния HTTP 465 ответа возвращается, когда состояние любого из прослушивателей канала больше, чем CommunicationState.Opened.

4. OnThrottlePercentExceeded: указывает процент {1 - 100}, который инициирует ответ, и его HTTP-код ответа {200 - 599}.

  • Пример: путем запроса https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500 когда процент газа равен или превышает 95%, HTTP ответ кода 500; когда процент равен или больше 70% и меньше 95%, возвращается 350; в противном случае 200 возвращается. 

Публикация сервиса здоровья:

После включения конечной точки работоспособности состояние работоспособности сервиса может отображаться либо в html формате (указав строку запроса: https://contoso:81/Service1?health&Xml), либо в xml формате (указав строку запроса: https://contoso:81/Service1?health&Xml). https://contoso:81/Service1?health&NoContent возвращает пустую HTML-страницу.

Примечание:

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

  1. Используйте другой порт для конечной точки работоспособности, чем тот, который используется для других cервисов, а также используйте правило брандмауэра для управления доступом.
  2. Добавьте желаемую аутентификацию и авторизацию для привязки конечной точки работоспособности.

WPF - экранные рассказчики больше не объявляют элементы с видимостью «Свернутый» или «Скрытый»

Элементы со свернутой или скрытой видимостью больше не объявляются программами чтения с экрана. Пользовательские интерфейсы, содержащие элементы с видимостью Свернутый или Скрытый, могут быть искажены программами чтения с экрана, если такие элементы объявлены пользователю. В .NET Framework 4.8 WPF больше не включает в себя элементы «Свернутый» или «Скрытый» в Control View структуры UIAutomation, поэтому программы чтения с экрана больше не могут объявлять эти элементы.

WPF - Свойство SelectionTextBrush для использования с Non-Adorner текстовым выделением

В .NET Framework 4.7.2 версии, в WPF добавилась возможность выделения TextBox и PasswordBox текста без использования adorner (см. здесь). Цвет переднего плана выделенного текста в этом сценарии был определен с помощью SystemColors.HighlightTextBrush.

В .NET Framework 4.8 будет добавлено новое свойство - SelectionTextBrush, которое позволит разработчикам выбирать конкретную кисть для выбранного текста при использовании выделения текста, основанного на non-adorner выделении текста.

Это свойство работает только для производных элементов управления TextBoxBase и PasswordBox в WPF приложениях с включенным выделением текста, не основанным на графическом элементе. Оно не работает на RichTextBox. Если выбор текста, не основанного на объявлении, не включен, это свойство игнорируется.

Чтобы использовать это свойство, просто добавьте его в Ваш XAML код и используйте соответствующую кисть или связывание.

В результате выбор текста будет выглядеть так:

Вы можете комбинировать использование SelectionBrush и SelectionTextBrush для создания любой подходящей цветовой комбинации фона и переднего плана.

WPF - Усовершенствования с высоким разрешением

В WPF добавлена поддержка Per-Monitor V2 DPI Awareness и смешанного DPI режима в .NET 4.8. Дополнительную информацию об этих Windows концепциях смотрите здесь.

В последнем руководстве разработчика по созданию WPF приложений говорится, что только приложения с чистым WPF кодом будут бесперебойно работать в WPF приложениях с высоким разрешением и что элементы управления Hosted HWND и Windows Forms будут поддерживаться не полностью.

В .NET 4.8 улучшена поддержка взаимодействия между HWND и Windows Forms в WPF приложениях с высоким разрешением на платформах, которые поддерживают Mixed-Mode DPI (Windows 10 версия 1803). Когда размещенные элементы управления HWND или Windows Forms создаются как масштабированные Mixed-Mode DPI окна (как описано в документации «Mixed-Mode DPI маштабирование и API-интерфейсы с DPI поддержкой» путем вызова SetThreadDpiHostingBehavior и SetThreadDpiAwarenessContext API), можно будет разместить такое содержимое в PerF Monitor V2 WPF приложении, и маштабировать их размер соответствующим образом.

Поддержка режима Per-Monitor V2 DPI осведомленности также позволяет размещать WPF элементы управления (т.е. помещать их в родительское окно) под нативным окном в приложении с высоким разрешением. Поддержка Per-Monitor V2 DPI Awareness будет доступна в Windows 10 версии 1607 (Anniversary Update). Windows добавляет поддержку дочерних HWND для получения уведомлений об изменении DPI, когда Per-Monitor V2 DPI Awareness режим включен через манифест приложения.

WPF использует эту поддержку, чтобы гарантировать, что элементы управления, размещенные в собственном окне, могут реагировать на DPI изменения и обновляться самостоятельно. Например, WPF элемент управления, размещенный в Windows Forms или Win32 приложении, которое отображается как Per Monitor V2, теперь сможет корректно реагировать на DPI изменения и сам обновляться.

Обратите внимание, что Windows поддерживает Mixed-Mode DPI масштабирование в Windows 10 версии 1803, тогда как Per-Monitor V2 поддерживается в версии 1607 и выше.

Чтобы опробовать эти функции, необходимо включить следующий манифест приложения и AppContext флажки:

1. Включите Per-Monitor DPI в Вашем приложении

  • Включите Per-Monitor V2 в Вашем app.manifest

2. Включите поддержку высокого разрешения в WPF

  • Нацельте .NET Framework 4.6.2 и выше

а также

3. Установите AppContext переключатель в Вашем app.config

Или же

Установите AAppContextSwitch Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false в App.Config, чтобы включить поддержку Per-Monitor V2 и Mixed-Mode DPI, внедренную в .NET 4.8.

Раздел времени выполнения в конечном App.Config файле может выглядеть следующим образом:

Переключатели AppContext также могут быть установлены в реестре. Вы можете обратиться к AppContext Классу для получения дополнительной документации.

WPF - Поддержка свойства UIAutomation ControllerFor

Свойство UIAutomation ControllerFor возвращает множество элементов автоматизации, которыми управляет элемент автоматизации, поддерживающий это свойство. Это свойство обычно используется для автоматического предложения доступности. ControllerFor используется, когда элемент автоматизации влияет на один или несколько сегментов пользовательского интерфейса приложения или рабочего стола. В противном случае трудно связать влияние операции управления с элементами пользовательского интерфейса.

Новый виртуальный метод был добавлен в AutomationPeer:

Чтобы предоставить значение для свойства ControllerFor, просто переопределите этот метод и верните список AutomationPeers для элементов управления, которыми манипулирует этот AutomationPeer:

WPF - Подсказки по доступу с клавиатуры

В настоящее время всплывающие подсказки отображаются только тогда, когда пользователь наводит курсор мыши на элемент управления. В .NET Framework 4.8, WPF добавляет функцию, позволяющую отображать всплывающие подсказки как на клавиатуре, так и с помощью сочетания клавиш.

Чтобы включить эту функцию, приложению необходимо настроить таргетинг на .NET Framework 4.8 или зарегистрироваться через AppContext переключатель «Switch.UseLegacyAccessibilityFeatures.3» и «Switch.UseLegacyToolTipDisplay».

Пример App.config файла:

 

 
 
      
         
     
   
     
   

 

После включения все элементы управления, содержащие подсказку, начнут отображать ее, как только элемент управления получит фокус клавиатуры. Подсказка может быть отклонена с течением времени или при изменении фокуса клавиатуры. Пользователи также могут отклонить всплывающую подсказку вручную с помощью сочетания клавиш Ctrl + Shift + F10. Как только всплывающая подсказка будет отклонена, ее можно снова отобразить с помощью того же сочетания клавиш.

Примечание. Подсказки RibbonTool на элементах управления ленты не отображаются на фокусе клавиатуры - они отображаются только через сочетание клавиш.

WPF - Добавлена поддержка свойств SizeOfSet и PositionInSet UIAutomation

Windows 10 представила новые свойства UIAutomation SizeOfSet и PositionInSet, которые используются приложениями для описания количества элементов в наборе. Клиентские приложения UIAutomation, такие как программы чтения с экрана, могут затем запросить приложение для этих свойств и объявить точное представление пользовательского интерфейса приложения.

Эта функция добавляет поддержку WPF приложений для предоставления этих двух свойств UIAutomation. Это может быть выполнено двумя способами:

1. DependencyProperties

Новые DependencyProperties SizeOfSet и PositionInSet были добавлены в пространство имен System.Windows.Automation.AutomationProperties. Разработчик может установить эти значения через XAML:

 

 
 

 

2. Виртуальные методы AutomationPeer

Виртуальные методы GetSizeOfSetCore и GetPositionInSetCore также были добавлены в AutomationPeer класс. Разработчик может предоставить значения для SizeOfSet и PositionInSet, переопределив эти методы:

 

public class MyButtonAutomationPeer : ButtonAutomationPeer 
    { 
        protected override int GetSizeOfSetCore() 
        { 
            // Call into your own logic to provide a value for SizeOfSet 
            return CalculateSizeOfSet(); 
        } 
         protected override int GetPositionInSetCore() 
        { 
            // Call into your own logic to provide a value for PositionInSet 
            return CalculatePositionInSet(); 
        } 
    }

 

Автоматические значения

Элементы в ItemsControls автоматически предоставляют значение для этих свойств без дополнительных действий со стороны разработчика. Если ItemsControl сгруппирован, коллекция групп будет представлена как набор, и каждая группа будет подсчитана как отдельный набор, при этом каждый элемент внутри этой группы будет обеспечивать свою позицию внутри этой группы, а также размер группы. Автоматические значения не зависят от виртуализации. Даже если элемент не реализован, он все равно учитывается в общем размере набора и влияет на позицию в наборе его родственных элементов.

Автоматические значения предоставляются только в том случае, если разработчик нацелен на .NET Framework 4.8 или установил AppContext переключатель «Switch.UseLegacyAccessibilityFeatures.3» - например, через App.config файл:

 
 
      
         
     
   
     
  
В заключение

Попробуйте эти улучшения в .NET Framework 4.8 и поделитесь Вашими отзывами в комментариях здесь или на GitHub.

Часть 1.

Источник




Posted on 20. May 2019

ML.NET 1.0

Уже сегодня, выходит новый ML.NET 1.0. ML.NET - это кросс-платформенная система машинного обучения с открытым исходным кодом для использования возможностей машинного обучения (ML) в .NET приложениях.

https://github.com/dotnet/machinelearning 

Начните работу @ http://dot.net/ml 

ML.NET позволяет обучать, создавать и поставлять пользовательские модели машинного обучения с использованием C# или F# для таких сценариев, как анализ мнений, классификация проблем, прогнозирование, рекомендации и многое другое. Вы можете изучить эти сценарии и задачи в ML.NET репозитории.

Изначально ML.NET разрабатывался в рамках Microsoft Research и превратился в важную среду, используемую многими Microsoft продуктами, такими как Windows Defender, Microsoft Office (Проектирование идей для PowerPoint презентаций, Построение диаграмм в Microsoft Excel), Azure Machine Learning, Ключевые факторы влияния PowerBI и многие другие!

После первого выпуска ML.NET, он стал использоваться многими организациями, такими как SigParser (обнаружение спама в электронной почте), William Mullens (классификация юридических вопросов) и Evolution Software (определение уровня влажности лесных орехов). Вы можете ознакомиться с этими и многими другими организациями, которые используют ML.NET, на витрине ML.NET клиентов. Эти пользователи говорят нам, что простота использования ML.NET, возможность повторно использовать .NET навыки и полное сохранение технического стека в .NET являются основными причинами использования ML.NET.

Наряду с выпуском ML.NET 1.0 также были добавлены новые функции preview-версии, такие как автоматизированное машинное обучение (AutoML) и новые инструменты, такие как ML.NET CLI и ML.NET Model Builder, что позволит Вам добавлять модели машинного обучения в Ваши приложения в один клик!

Остальная часть этого поста посвящена новому функционалу.

Основные компоненты ML.NET

ML.NET нацелен на обеспечение конечного рабочего процесса для использования машинного обучения в .NET приложениях на различных этапах машинного обучения (первые наброски, разработка функций, моделирование, оценка и эксплуатация). ML.NET 1.0 предоставляет следующие ключевые компоненты:

1. Представление данных
  • Фундаментальные типы данных конвейера ML данных, такие как IDataView - основной тип конвейера данных
  • Читалки для поддержки чтения данных из текстовых файлов с разделителями или IEnumerable объектов
2. Поддержка задач машинного обучения:
  • Бинарная классификация
  • Мультиклассовая классификация
  • Регрессия
  • Ранжирование
  • Обнаружение аномалий
  • Кластеризация
  • Рекомендация (preview)
3. Преобразование данных и индивидуализация
  • Текст
  • Категории
  • Выбор функций
  • Нормализация и обработка пропущенных значений
  • Подделка образов
  • Временные циклы (preview)
  • Поддержка интеграции ONNX и TensorFlow моделей (preview-версия)
4. Другое
  • Модель понимания и объяснимости
  • Пользовательские преобразования
  • Схема операций
  • Поддержка манипулирования наборами данных и перекрестной проверки
Automated Machine Learning (Preview-версия)

На данный момент, начало работы с машинным обучением включает в себя невероятный путь. При создании пользовательских моделей машинного обучения Вы должны выяснить, какую задачу машинного обучения необходимо выбрать для Вашего сценария (например, классификацию или регрессию?), преобразовать Ваши данные в формат, понятный ML алгоритмам (например, текстовые данные -> числовые векторы), и настроить эти ML алгоритмы, чтобы получить лучшую производительность. Если Вы новичок в ML, каждый из этих шагов может быть довольно сложным!

Automated Machine Learning упрощает Ваше начало в работе с ML, автоматически выясняя, как преобразовать входные данные, и выбирая для Вас наилучший ML алгоритм с правильными настройками, позволяющими легко создавать лучшие в своем классе пользовательские ML модели.

AutoML поддержка в ML.NET еще находится в режиме предварительного просмотра, и в настоящее время поддерживаются ML задачи (регрессия (используется для сценариев, таких как прогнозирование цен)) и классификация (используется для сценариев, таких как анализ настроений, классификация документов, обнаружение спама и т. д.).

Вы можете попробовать AutoML в ML.NET в трех форм-факторах, используя ML.NET Model Builder, ML.NET CLI или прямо через API AutoML (примеры смотрите здесь).

Для пользователей, которые не знакомы с машинным обучением, рекомендуется начать с ML.NET Model Builder в Visual Studio и ML.NET CLI на любой поддерживаемой платформе. AutoML API также очень удобен для сценариев, в которых можно создавать модели на лету.

Model Builder (Preview-версия)

Чтобы упростить .NET разработчикам путь по созданию ML моделей, был выпущен ML.NET Model Builder. С помощью ML.NET Model Builder внедрение машинного обучения в Ваши приложения бует доступно в один клик!

Model Builder - это простой инструмент пользовательского интерфейса для разработчиков, который использует AutoML для создания лучших в своем классе ML моделей с использованием предоставленного Вами набора данных. В дополнение к этому, Model Builder также генерирует обучение модели и код потребления модели для наиболее эффективной модели, позволяющей быстро добавлять ML в Ваши приложения.

Узнайте больше о ML.NET Model Builder

На данный момент, Model Builder находится в режиме предварительного просмотра, и Ваши отзывы и замечания будут очень полезными для его будущего развития!

ML.NET CLI (Preview-версия)

ML.NET CLI (интерфейс командной строки) - это еще один новый инструмент, который был недавно выпущен!

ML.NET CLI - это dotnet инструмент, который позволяет создавать ML.NET модели с помощью AutoML и ML.NET. ML.NET CLI быстро выполняет итерацию по Вашему набору данных для конкретной ML задачи (в настоящее время поддерживает регрессию и классификацию) и создает лучшую модель.

CLI в дополнение к созданию лучшей модели также позволяет пользователям генерировать модели обучения и код модели потребления для наиболее эффективной модели.

ML.NET CLI - это кросс-платформенная система, которая представляет собой простое дополнение к .NET CLI. Расширение Model Builder Visual Studio также использует ML.NET CLI для предоставления возможностей построителя моделей.

Вы можете установить ML.NET CLI, используя эту команду.

 

dotnet tool install -g mlnet

 

На следующем рисунке показан интерфейс командной строки ML.NET CLI, создающий набор данных для анализа настроений.

 

Узнайте больше о ML.NET CLI

На данный момент ML.NET CLI тоже находится в режиме предварительного просмотра, и Ваш фидбэк будет очень полезным для его дальнейшего развития!

Начните уже сейчас!

Если Вы еще этого не сделали, начать работу с ML.NET легко, и Вы можете сделать это в несколько простых шагов, которые описаны ниже. В приведенном ниже примере показано, как можно выполнить анализ настроений с помощью ML.NET.

 

//Step 1. Create a ML Context
var ctx = new MLContext();
 
//Step 2. Read in the input data for model training
IDataView dataReader = ctx.Data
    .LoadFromTextFile(dataPath, hasHeader: true);
 
//Step 3. Build your estimator
IEstimator est = ctx.Transforms.Text
    .FeaturizeText("Features", nameof(SentimentIssue.Text))
    .Append(ctx.BinaryClassification.Trainers
        .LbfgsLogisticRegression("Label", "Features"));
 
//Step 4. Train your Model
ITransformer trainedModel = est.Fit(dataReader);
 
//Step 5. Make predictions using your model
var predictionEngine = ctx.Model
    .CreatePredictionEngine(trainedModel);
 
var sampleStatement = new MyInput { Text = "This is a horrible movie" };
 
var prediction = predictionEngine.Predict(sampleStatement);

 

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

Что будет дальше в ML.NET?

Не смотря на то, что недавно был выпущен ML.NET 1.0, команда продолжает усердно работать, чтобы как можно скорее добавить функции, описанные в этом блог посте, в следующий выпуск.

  • AutoML для дополнительных ML сценариев
  • Улучшенная поддержка сценариев глубокого обучения
  • Поддержка других источников, таких как SQL Server, CosmosDB, хранилище Azure Blob и других.
  • Масштабирование в Azure для модели обучения и потребления
  • Поддержка дополнительных сценариев и ML функций при использовании Model Builder и CLI
  • Встроенная интеграция для машинного обучения в масштабе с .NET для Apache Spark и ML.NET
  • Новые ML типы в .NET, например DataFrame
Вклад участников

Выражена специальная благодарность этим замечательным участникам, которые помогали при разработке, чтобы сделать машинное обучение доступным для .NET разработчиков с ML.NET.


Если Вы еще не начали, обязательно попробуйте ML.NET!

Ваше мнение очень важно для ML.NET улучшения и вскоре .NET будет лучшей платформой для машинного обучения.