Здравствуйте, Serginio1, Вы писали:
S>>>·>Т.е. вообще тупой интерпретатор с примитивным GC. Вот они и стали пилить этот самый .net native.
S>>> .Net Native сейчас идет под UWP Что такое приложение UWP?
S>>>Там не только мобильные устройства. .NET Micro Framework это другое Microsoft .NET Framework во встраиваемых приложениях <br />
<span class='lineQuote level3'>S>>></span>.
S>·>А что на мобильниках? Или мобильников с dotnet не было что-ли ещё в природе (до .net native)?
S> Был .Net Compact Framework,
Там был NGEN?
S>затем пришел WinRt
А он вообще "был"? Вроде умер не родившись... Там вообще вроде С++. Причём тут сабж?
S> и CoreClr https://msdn.microsoft.com/en-us/library/windows/apps/jj681690(v=vs.105).aspx
S>http://stackoverflow.com/questions/14247142/what-framework-does-windows-phone-7-and-windows-phone-8-support
S>С кучей профилей.
S> http://stackoverflow.com/questions/18164769/windows-phone-8-native-and-clr-runtime
Но там же твой ненавистный JIT. ngen разве был?
S>>> Ну моделей смартфонов то немного, и держать для каждой модели скомпилированные файлы. Это же не миллионы. И речь пока идет только об UWP которые только на продуктах MS, и Xamarin для IPhone. Да даже если для андроида, то это не огромное количестао аппаратов.
S>·>Каждая новая модель (точнее платформа) — это ещё по одному бинарику для _каждого_ приложения в апп-сторе. Т.е. десяток платформ (у андроида их вроде даже больше) — десятикратная нагрузка на апп-стор.
S>·>Конечно, если MS будет выпускать только одну-две модели (как аппл) или надеяться, что приложений будет не так много (как в вин-мобильном апп-сторе), то может и прокатит.
S> Один раз скопилировали под плптформу и её уже устанавливают на миллионы устройств. Какая нафин нагрузка? Найти в Базе нужную модель?
Я не о количестве самих устройств. Почитай внимательно что я пишу. Компилировать _каждое_ приложение под _каждую_ платформу _каждой_ версией фреймворка. Тот же андроид и под армы, и под интелы, и под 32 бита, и под 64. Конечно, если будет одна единственная платформа и версия фреймворка, то проблем со сборкой будет меньше, я это и говорил. Но это имеет свои недостатки.
S>>>А вот выхлоп за счет более оптимизируещего компилятора он есть.
S>·>Какой ещё "более" оптимизирующий компилятор? Более чем что?
Ы?
S>>> Есть альтернативное решение. По сути это аналог С++ со сборкой мусора. Я уже приводил тебе ссылки на stack stackalloc
S>·>Круто конечно, но в java пошли другим путём. Вместо усложнения языка — улучшают JIT. Этот самый stackalloc делается автоматически в некотоых случаях, благодаря escape analysis.
S>Угу вместо того, что бы 1 раз оптимизировать нужно каждый раз оптимизировать.
Это плохо не всегда. Иногда это хорошо.
S>При этом SIMD операций нет.
А в .net native есть?
S>stackalloc программист сам знает где вставить, зачем мучать JIT компилятор.
Компилятор железный, его не жалко мучить. А программисты денег хотят за мучения.
S> Ну да лпадно. По твоему C++ умер. Осталасть только Java в том числе и на симках
Причём тут C++?? Сабж-то читал? stackalloc добавили в Плюсы??
