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

S>А почему, что мешает? Runtime статистики не хватает или еще чего?

Первое, что хочется предположить, что это все больше треб на будущее. У МС много говорят о мифических потенциальных оптимизациях, которых на практике не делается. По крайне мете так было в докорочном дотнете.

Теоретически у джит-компиляции есть много способов создать более производительный код.

1. Джит компилирует код для конкретного процессора и даже конкретной системы. Он может использовать любые инструкции. И даже перенести вычисления на видюху (но это пока только совсем в теории).

2. Джит работает в момент когда все сборки или уже загружены или может быть перджитен когда появятся новые сборки. Отсюда становятся доступны оптимизации вроде агрессивного инлайнинга или переписывания объектов из кучи в стэковые объекты. Эти оптимизации открывают дорогу другим, которые нельзя сделать без предыдущих.

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

4 Оптимизированный код может разбухнуть. А это хреново влияет на скорость загрузки приложений. Этот ReadyToRun предназначен для ускорения старта приложения. Я не пробовал ReadyToRun, но NGen существенно сокращал скорость загрузки приложения в котором имеется большое количество типов и много мелких методов. Скорость загрузки росла даже не в разы, а в десятки раз. Но это специфично для приложения. А вот наш современный продукт не может использовать Ngen из-за уязвимостей которые несет загрузка неподписанных бинарей. ReadyToRun может оказаться хорошей альтернативой (надеюсь, что его бинари удастся подписать).

Когда же компилируется нативный код для всей сборки, то он не может использовать всего перечисленного, не может работать очень долго (хотя это можно было бы отрегулировать опциями компиляции) и не может производить тех оптимизаций, которые требуют знаний о наличии загруженных сборках (наследников типов и т.п.).

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

Судя по написанному в МС хотя получить и ускорение загрузки, и джит-компиляции отдельных функций, и высокую скорость работы отдельных методов за счет реджита отельных, часто выполняемых методов, и не сильное раздувание памяти, так как перекомпилируются только отдельные методы.

Звучит красиво. Ну, а как оно будет на практике нужно смотреть на практике.

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

S>А почему, что мешает? Runtime статистики не хватает или еще чего?

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

Теоретически у джит-компиляции есть много способов создать более производительный код.

1. Джит компилирует код для конкретного процессора и даже конкретной системы. Он может использовать любые инструкции. И даже перенести вычисления на видюху (но это пока только совсем в теории).

2. Джит работает в момент когда все сборки или уже загружены или может быть перджитен когда появятся новые сборки. Отсюда становятся доступны оптимизации вроде агрессивного инлайнинга виртуальных методов или переписывания объектов из кучи в стековые объекты. Эти оптимизации открывают дорогу другим, которые нельзя сделать без предыдущих.

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

4 Оптимизированный код может разбухнуть. А это хреново влияет на скорость загрузки приложений. Этот ReadyToRun предназначен для ускорения старта приложения. Я не пробовал ReadyToRun, но NGen существенно сокращал скорость загрузки приложения в котором имеется большое количество типов и много мелких методов. Скорость загрузки росла даже не в разы, а в десятки раз. Но это специфично для приложения. А вот наш современный продукт не может использовать Ngen из-за уязвимостей которые несет загрузка неподписанных бинарей. ReadyToRun может оказаться хорошей альтернативой (надеюсь, что его бинари удастся подписать).

Когда же компилируется нативный код для всей сборки, то он не может использовать всего перечисленного, не может работать очень долго (хотя это можно было бы отрегулировать опциями компиляции) и не может производить тех оптимизаций, которые требуют знаний о наличии загруженных сборках (наследников типов и т.п.).

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

Судя по написанному в МС хотя получить и ускорение загрузки, и джит-компиляции отдельных функций, и высокую скорость работы отдельных методов за счет реджита отельных, часто выполняемых методов, и не сильное раздувание памяти, так как перекомпилируются только отдельные методы.

Звучит красиво. Ну, а как оно будет на практике нужно смотреть на практике.