Здравствуйте, Serginio1, Вы писали:
S>>> Я так понимаю, что это аналог NGEN которому огромное количество лет и с теми же недостатками.
S>·>Насколько я знаю, главный недостаток NGEN для мобильных девайсов в том, что его нет. Вот что пишут о .NET Micro Framework:
S>·>The CLR is an interpreter rather than a just-in-time compiler, and uses a simpler mark-and-sweep garbage collector instead of a generational approach.
S>·>Т.е. вообще тупой интерпретатор с примитивным GC. Вот они и стали пилить этот самый .net native.
S> .Net Native сейчас идет под UWP Что такое приложение UWP?
S>Там не только мобильные устройства. .NET Micro Framework это другое Microsoft .NET Framework во встраиваемых приложениях <br />
<span class='lineQuote level1'>S></span>.
А что на мобильниках? Или мобильников с dotnet не было что-ли ещё в природе (до .net native)?
S>·>Зависимость от фреймворка сама по себе ничем не плохо. AOT не означает, что нужно непременно собирать нативные бинарники и распространять их магазином. В ART сделано оптимально — финальная компиляция (из байткода в натив) сделана на девайсе, в момент установки. Т.е. установленная программа — нативный код — проблем с батареей и со стартом приложения нет. .net native предлагает распространять нативные бинарники изначально, что может серьёзно увеличить нагрузку на апп-сторы в случае большого числа вариантов девайсов или версий этого самого .net native.
S> Ну моделей смартфонов то немного, и держать для каждой модели скомпилированные файлы. Это же не миллионы. И речь пока идет только об UWP которые только на продуктах MS, и Xamarin для IPhone. Да даже если для андроида, то это не огромное количестао аппаратов.
Каждая новая модель (точнее платформа) — это ещё по одному бинарику для _каждого_ приложения в апп-сторе. Т.е. десяток платформ (у андроида их вроде даже больше) — десятикратная нагрузка на апп-стор.
Конечно, если MS будет выпускать только одну-две модели (как аппл) или надеяться, что приложений будет не так много (как в вин-мобильном апп-сторе), то может и прокатит.
S>А вот выхлоп за счет более оптимизируещего компилятора он есть.
Какой ещё "более" оптимизирующий компилятор? Более чем что?
S>·>Так что из того что ты написал — нет ничего нового (ну кроме COM для linux), это уже несколько лет успешно работает на java платформе, этот самый .net native просто попытка догнать, и (лично моё мнение) не самая удачная, поживём — увидим.
S> Есть альтернативное решение. По сути это аналог С++ со сборкой мусора. Я уже приводил тебе ссылки на stack stackalloc
Круто конечно, но в java пошли другим путём. Вместо усложнения языка — улучшают JIT. Этот самый stackalloc делается автоматически в некотоых случаях, благодаря escape analysis.
S> Так что развитие идет, и главное увеличивается конкуренция которая стимулирует постоянное улучшение продуктов.
Это да.
