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

S>"с соблюдением _всех_ контрактов современного фреймворка часть оптимизаций практически невозможна"

Да.

S>"с отказом от части контрактов в плане оптимизаций дотнет принципиально ничем не отличается от нативного кода".

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

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

А будет ли затем этот переносимый код пре-джиттен в родной (т.е. в тот самый нейтивный образ конкретного процессора ) — да абсолютно не принципиально. Львиная доля агрессивных оптимизаций при отказе от соблюдения приватных контрактов уровня исходника (вплоть до сохранения разметки памяти) может быть выполнена еще на стадии управляемого кода.

Собсно, принципиальное отличие проталкиваемой VM от гугла для веба — в этом и ни в чем более.

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

Так вот, в нынешней реализации дотнетной VM каждый метод должен возвращать указатель стека к исходной точке к концу метода по всем своим веткам. Если предположить, что оптимизатор "видит", что некий приватный код вызывается из вполне счетного кол-ва мест и нет никакой возможности вызывать этот код извне, то для такого кода сие правило уже НЕ является необходимым. Тут уже можно начать оптимизировать — жонглировать порядком аргументов в стеке и самим способом работы со стеком.

Ну и, С++ тоже ограничен в плане редукций — для целей совместимости различные компиляторы ничего не делают даже с приватными полями, т.е. никак не оперируют с исходной разметкой памяти. Такая разметка детерминирована прямо в стандарте, ес-но. И этот больной мозоль тоже периодически обсасывают, бо выходит так, что в обозримой перспективе у нас есть лишь оптимизация/редукция только кода, но не данных+кода. А последнее мощнее на порядки. Сейчас оптимизатор С++ редуцирует промежуточные данные только в том случае, если видит их полный жизненный цикл. Но это своего рода тупик. Именно поэтому я одно время, скажем так, был весьма мотивирован на изучение низкоуровневой механики дотнета и пытался увидеть, к чему всё идёт. К сожалению, первые 8 лет — вообще не туда. Дотнет был разработан полупрофессиональными программистами, полуинженерами. Почти нубами. Это не попытка наезда, это медицинский факт. Эти люди получили почти безграничный кредит доверия на волне той самой шумихи "ява в интернете". Они оказались неспособны рассмотреть вопросы организации вычислений в комплексе, не смогли промоделировать реальные пути развития вычислительных сугубо программных технологий. Сам проект дотнета "выстрелил" лишь благодаря фантастическим потраченным на проект человекочасам в сочетании с, скажем прямо, недостижимым авторитетом MS на начало 2000-х.


S>Причём с ними согласны все стороны, вы их просто повторяете друг другу. Заело

Тут я могу согласиться лишь с тем, что любой спор в стиле "или всё или ничего" чаще всего бесполезен.
Но здесь не тот случай.


S>Особый юмор ситуации в том, что вторая мысль проверена практикой уже несколько лет как.

Что немного сбивает с толку, верно?
Т.е., когда дают ответ сразу, без демонстрации хода решения, то сгоряча можно принять теорему за аксиому. ))

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

Последнее — ключевое. Функции обеспечения "доверенности" выносятся из каждого экземпляра пользовательской ОС и переносятся на некую внешнюю, по отношению к ОС, инфраструктуру.


S>Приложения под WP 8 — managed с прекомпиляцией. Почти все встроенные метро-приложения Win 10 — шарп + .net native. нетормозят™.

Да. Поставляемые из доверенного источника, заметь. Конкретное устройство не мучается над вопросом верификации кода, а получает на него готовый ответ. А верифицируется в этой схеме лишь слой транспорта (и всё вокруг него), по которому готовый ответ доставляется до устройства.


S>Вопрос по сути в следующем:
S>* когда аналог .native будет доступен для прочих форков дотнета (ориентировочно — через релиз).

Это текущие рабочие моменты и не более того.
Т.е. акцент де-факто сместился — ОК, в первую очередь надо по-бырому переделать инфраструктуру.


S>* когда по качеству оптимизации транслированный код будет выигрывать у выхлопа JIT-а (ещё позднее).

А вот это тогда, когда перейдут на принципиально другую VM. Собсно, унутре майкрософтных оптимизирующих продуктов есть промежуточное представление навроде LLVM.

Более того, с выпуском VS 15 они теперь могут поддерживать оптимизацию байт-кода LLVM. Т.е. уже был сделан некий шаг по абстрагированию наработок оптимизаций от частностей базовой выч.архитектуры для исходного байткода (угу, в этом месте байткод — лишь "исходник"). Вангую, что наработки из разных областей будут топливом для развития именно этих моментов. Всё-таки, в плане агрессивной оптимизации программ, MS является одним из лидеров индустрии (или даже абсолютным лидером, я 3 года назад плотно гонял коммерческий компилятор от интел в сравнении с MS под винды — результаты MS часто были заметно лучше).