Здравствуйте, Sinix, Вы писали:

V>>Проблема исключительно и только в рефлексии всего и вся.
S>Ну... не совсем так. Главный затык _сейчас_ — инлайнинг делегатов / интерфейсов (хотя бы итераторов для начала) и stackallock объектов (не факт, что он появится в .native раньше, чем в .net core).

В компиляторе С++ всё это порешали уже лет 15 назад. Т.е. дело лишь за тем, чтобы перенести наработки в дотнетный Native.


S>"Сейчас" — это с хайпом на облака акторов

Что есть выделенное?


S>А вот когда (и если) дело пойдёт в сторону числодробилок, тогда — да, cross-assembly optimizations в полный рост.

Без "числобробилок" платформа не может считаться "зрелой", "взрослой" и т.д.


S>>>* когда по качеству оптимизации транслированный код будет выигрывать у выхлопа JIT-а (ещё позднее).
V>>А вот это тогда, когда перейдут на принципиально другую VM. Собсно, унутре майкрософтных оптимизирующих продуктов есть промежуточное представление навроде LLVM.
S>В смысле перейдут? у .net native свой runtime прямо сейчас.

Модель VM та же.

Я же говорил, что Net Native даёт сразу конечный не-кроссплатформенный результат и это способно немного сбить с толку. Но получают его (конечный результат) через некий промежуточный, который является кроссплатформенным — через модель той же самой VM. Для получения нейтивного кода не надо компилять в облаке, можно компилять локально и смотреть, что происходит. В облаке — это когда отправляешь готовое приложение в Магазин.


V>>Более того, с выпуском VS 15 они теперь могут поддерживать оптимизацию байт-кода LLVM.
S>llilc даже до беты не дошёл ещё. Кто его там в релиз собирался впихивать??? Или речь про IL2CPP от unity?

Речь об этом:
https://blogs.msdn.microsoft.com/vcblog/2016/03/31/clang-with-microsoft-codegen-march-2016-released/

Ноги растут отсюда:
https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-codegen-in-vs-2015-update-1/

Но особый жир тут:
http://llvm.org/docs/GettingStartedVS.html


S>Остальное поскипал, т.к. спор и без меня не заглохнет

Заглохнет ))