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

EC>Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое?
Даже виртуальные? Прикол именно в том, что HotSpot может частично либо полностью устранять виртуальность, основываясь на спекулятивных предположениях. На практике это означает отсутствие abstraction penalty и возможность обойтись без архитектурно корявых залепух навроде намеренно невиртуальных методов и публикации полей вместо свойств.

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

EC>>Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое?
S>Даже виртуальные? Прикол именно в том, что HotSpot может частично либо полностью устранять виртуальность, основываясь на спекулятивных предположениях. На практике это означает отсутствие abstraction penalty и возможность обойтись без архитектурно корявых залепух навроде намеренно невиртуальных методов и публикации полей вместо свойств.

Насчёт виртуальных не знаю, но теоретических препятствий этому не вижу.

EvilChild wrote:
> S>Даже виртуальные? Прикол именно в том, что HotSpot может частично либо
> полностью устранять виртуальность, основываясь на спекулятивных
> предположениях. На практике это означает отсутствие abstraction penalty
> и возможность обойтись без архитектурно корявых залепух навроде
> намеренно невиртуальных методов и публикации полей вместо свойств.
> Насчёт виртуальных не знаю, но теоретических препятствий этому не вижу.
И как ты это собираешься делать без HotSpot?

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

C>И как ты это собираешься делать без HotSpot?
Не совсем понял твой вопрос.
По моему у CLR есть достаточно информации, чтобы устранять виртуальность там, где это возможно и откатывать эту оптимизацию, когда она становится невалидной (загрузили тип, где эта функция overriden).
Или ты о том, что это и будет HotSpot?
Если да, то пожалуйста — мне всё равно как это называется.

EvilChild wrote:
> C>И как ты это собираешься делать без HotSpot?
> Не совсем понял твой вопрос.
> По моему у CLR есть достаточно информации, чтобы устранять виртуальность
> там, где это возможно и откатывать эту оптимизацию, когда она становится
> невалидной (загрузили тип, где эта функция overriden).
> Или ты о том, что это и будет HotSpot?
Да, именно это и будет HotSpot.

Но смысл в том, что сейчас .NET VM не выполняет перекомпиляцию кода.

Здравствуйте, Cyberax, Вы писали:
C>И как ты это собираешься делать без HotSpot?
Ну разве что при помощи PGO. Без profile-time информации совершенно нереально выбрать одну из перегруженных версий виртуального метода для инлайнинга. Либо я не понимаю чего-то элементарного.

Sinclair wrote:
> C>И как ты это собираешься делать без HotSpot?
> Ну разве что при помощи PGO. Без profile-time информации совершенно
> нереально выбрать одну из перегруженных версий виртуального метода для
> инлайнинга. Либо я не понимаю чего-то элементарного.
Ну PGO — это тоже своеобразный HotSpot

Самое плохое в том, что PGO не работает с динамической подгрузкой кода.

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

AVK>>Смысл? Рантайм то тот же.

VD>Не тот же делегаты похоже ускорились.

fc /b вам в руки.

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

AVK>fc /b вам в руки.

И где я тебе найду разные версии? Да и суров ты. Я уж лучше какой-нить гуёвой утилитой воспльзуюсь (которая сможет сравнить сразу подкаталоги).

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

IT>Это действительно так. Особенно сильно вырывается вперёд серверный вариант. Это заметно даже по шустрикам на нашем сайте.

В серверном варианте просто доругой ЖЦ. К скорости кода это отношение не имеет. У дотента тоже разный ЖЦ и сравнивать тут так просто нельзя.

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

EC>Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое?

Вот такого не происходит. За-то в релизе почти всегда.

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

EC>>Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое?
S>Даже виртуальные? Прикол именно в том, что HotSpot может ...

На словах он могое может. На деле — нет.

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

C>Да, именно это и будет HotSpot.

Вообще-то HotSpot — это торговая марка. И больше ничего.

C>Но смысл в том, что сейчас .NET VM не выполняет перекомпиляцию кода.

Это да. Но если начнет это делать, то все равно HotSpot-ом не станет.

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

S>Ну разве что при помощи PGO. Без profile-time информации совершенно нереально выбрать одну из перегруженных версий виртуального метода для инлайнинга. Либо я не понимаю чего-то элементарного.

На самом деле во многих случаях было бы достаточно анализа потока управления. Ведь часто виртуальные методы и нитерфейсы применяются локально и можно проследить использование этой переменной. Если во время ее использования не делается ни одного изменения ссылки или все изменения делаются на тот же тип объектов, то можно смело создавать специализированную версию фукнции которой передается интерфейс (или класса) и устанять в ней как виртуальность, так и сам вызов. Учитывая, что это можно сделать во время пред-компиляции особых ресурсов (кроме некоторого увеличения расхода памяти под образ кода) тратить не приется, можно говорить о хорошем выигрыше.

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

EC>>Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое?

VD>Вот такого не происходит. За-то в релизе почти всегда.

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

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

VD>>Вот такого не происходит. За-то в релизе почти всегда.

EC>Как-то студия отказалась ставить бряку в теле тривиального сеттера (или геттера) в отладочной версии и сказала, что метод был оптимизирован, вот я и подумал, что инлайнинг случился. Если это не инлайнинг, то что тогда?

Может ты релиз пытался отлаживать?

VladD2 wrote:
> C>Да, именно это и будет HotSpot.
> Вообще-то HotSpot — это торговая марка. И больше ничего.
Я его обычно как термин использую.

Можешь предложить лучший вариант термина?

VladD2 wrote:
> IT>Это действительно так. Особенно сильно вырывается вперёд серверный
> вариант. Это заметно даже по шустрикам на нашем сайте.
> В серверном варианте просто доругой ЖЦ. К скорости кода это отношение не
> имеет. У дотента тоже разный ЖЦ и сравнивать тут так просто нельзя.
Вообще-то, серверная и клиентская JVMы заметно различаются в Java.
Клиентская GC имеет более простые алгоритмы HotSpot'а, оптимизированые
для быстрого запуска приложения.

Физически даже размеры файлов даже различаются:
client/jvm.dll — 2301952
server/jvm.dll — 3276800

Здравствуйте, VladD2, Вы писали:
VD>На самом деле во многих случаях было бы достаточно анализа потока управления. Ведь часто виртуальные методы и нитерфейсы применяются локально и можно проследить использование этой переменной.
В большинстве случаев это сводится к определению наличия вызова конструктора в области видимости. К сожалению, это происходит не так часто, как хотелось бы — это видно на примере современных С++ компиляторов. Они делают всё, что могут в этой области, но в большинстве случаев инлайнинг ограничивается автоматическими объектами.

Есть масса сценариев, в которых устранить виртуальность статическим анализом невозможно. Классы, которые задаются через конфиг файл; традиционная схема вызова виртуального метода из невиртуального, и еще много всего.

А для полей объектов получить строгое доказательство единственности присваивания вообще очень сложно (в смысле complexity) и неоправдвно: в большинстве случаев строгое доказательство вовсе невозможно. Именно тут рулит подход с guarded inlining. Для его применения достаточно нестрогого доказательства: если на практике одна из реализаций вызывается достаточно чаще других, то ее уже можно инлайнить. Строгое доказательство дает лишь небольшое улучшение — убирается guard code, который и так весьма недорог.


VD>Если во время ее использования не делается ни одного изменения ссылки или все изменения делаются на тот же тип объектов, то можно смело создавать специализированную версию фукнции которой передается интерфейс (или класса) и устанять в ней как виртуальность, так и сам вызов. Учитывая, что это можно сделать во время пред-компиляции особых ресурсов (кроме некоторого увеличения расхода памяти под образ кода) тратить не приется, можно говорить о хорошем выигрыше.

Не спорю. Трудно говорить "на пальцах", не имея точных цифр. Это же не выбор да/нет, это всего лишь наличие разнообразной информации у компилятора. Чем ее больше, тем лучшие оптимизации можно в общем случае провести. Но естественно, здесь должно быть применимо правило Парето — 80% выигрыша должно достигаться самыми простыми оптимизациями. А следующие 80% оптимизаций дадут не больше 20% выигрыша.

Здравствуйте, Cyberax, Вы писали:
C>Можешь предложить лучший вариант термина?
"Динамическая оптимизация целевого кода с использованием статистики времени выполнения".