Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Промышленная инженерия доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 18
Native AOT + ReadyToRun -- не очень понятно то имеется ввиду под этим.
Это я ради эксперимента попробовал одновременно использовать оба подхода к компиляции в машинный код.
Вообще, по идее должен был быть конфликт. Потому что Native AOT это полная компиляция решения в машинный код, а ReadyToRun только частичная. Но судя по тому что приложение запустилось и его объем увеличился, можно сказать что эксперимент удался)
Но публиковать приложение, собранное таким образом, конечно же не стоит)
Их нельзя использовать вместе никак, это два разных рантайма. У вас на выбор 4 опции:
NativeAOT
JIT + R2R (обычно все базовые библиотеки в R2R идут), при этом весь R2R код (если он горячий) по итогу все равно пере-компилируется джитом в Tier1
JIT-only (если насильно отключить R2R).
R2R-only, но тут практически нереально добиться того чтобы джит не вызывался
Ещё есть интерпретатор новый.
Нда, с дотнетом прямо совсем с размерами печаль. Самый толстый модбас сканер в мире получился =)
Согласен :)
И пока что не вижу путей как ещё уменьшить размер приложения. Native AOT был последней надеждой.
Помню, как то пытался перенести часть функционала на Qt. Размер приложения уменьшился. Но я как разработчик не был в восторге при использовании этого фреймворка. Пока что мне больше нравится связка C# и xaml разметки.
Вы можете пойти другим путем:
- реализовать сервисную часть на native aot и запускать ее, например, как службу windows или предоставлять как общую библиотеку
- реализовать отдельно ui-часть
если обеспечить совместимость на уровне контракта, то вы сможете обновлять лишь нужную часть, а не требовать перекачки всего приложения. к тому же станет очень очевидным, где лежит самая тяжелая часть приложения.
p.s. всё-таки, на мой взгляд, native aot - это больше про оптимизации, когда вы решили работать напрямую с памятью, указателями и т.п., но не желаете менять язык, и в большинстве проектов в этом нет необходимости - это нецелесообразно.
а чтобы приложение от долгого старта не казалось зависшим - есть отдельные приемы для визуализации этого процесса.
Самая большая часть приложения - это .NET Runtime)) Я публикую приложение автономным, чтобы не зависеть от наличия рантайма на машине пользователя.
В другом проекте я пробовал разделять приложение на службу и UI часть. И ко всему прочему добавились ещё и проблемы с отладкой взаимодействия этих двух компонентов. Не забываем ещё про отладку и возможные ньюансы на разных ОС. Поэтому не вижу в этом смысла.
Также если использовать Native AOT только в одном из компонентов приложения, то это не решит проблем описанных в статье.
Но я в целом соглашусь с тем, что вы написали в постскриптуме. А в моем случае, эксперимент с оптимизациями не удался.
В .net 9 пофиксили ложное срабатывание антивируса. До .net 9 помогало перемещение .managed в .text(вроде), на гите dotnet можно найти информацию по этому поводу.
К сожалению, у меня на ПК с Windows 11 были ложные срабатывания. Собирал как раз на .NET 9. Подожду релиз .NET 10. Надеюсь, там это исправят.
У меня на Avalonia прога, которая качает по стима игры - ругается вирус тотал только если иконку к приложению задать. Один детект. Иконку убрать - 0 детектов 😄
Программа сложная и иногда нужная но очень тяжелая.
Всякие красивые интерфейсы помоему не нужны.
Главное функционал.
Как ксати обстоит дело с NaN при приобразовании Float ?
С размером приложения, к сожалению, ничего не сделать. Это современные реалии. Я и так ужал ее почти вдвое, перейдя с WPF на Avalonia UI. Об этом можно почитать в предыдущих статьях. Не вижу путей как можно уменьшить размер еще больше, оставаясь в экосистеме .NET.
Красивый интерфейс делает работу приятнее. В инженерном софте этого не хватает.
Сейчас при преобразовании в число типа float можно получить NaN. На своей практике я замечал это в нецелевых форматах числа (у меня же выводится все четыре комбинации байт для float числа). Работе это не мешает. А у вас есть предложения по этому поводу? Или же сценарии, когда это важно?
У примеру у нас имеется контроллер имеющий каналы для измерения тока и напряжения. Он калибруются производителем и поправочные константы прописываются в отдельную флеш память.
В процессе работы измеренные данные корректируются согласно калибровочным константам и полученный результат можно считать по modbus rtu.
Встроенное ПО контроллера производит вычисления для каждого значения и если оно не укладывается в норму то отдает не рассчитанное значение а NaN.
И считав его по Modbus мы понимаем что этим данным верить нельзя.
Тут либо повреждены калибровочные данные или АЦП отдал какую то дичь.
NaN для нас это как флаг что данные битые.
Для Infinity значения возможно работает также (не проверял)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CoreBus: Часть 5 — попытка использования Native AOT