.NET runtime vs. Java Hotspot: Является ли .NET одним поколением?

В соответствии с информацией, которую я смог собрать в среде исполнения .NET и Java, текущее состояние дел:

Современная Java VM способна выполнять непрерывную перекомпиляцию, что в сочетании с профилированием может привести к большим улучшениям производительности. Старые JVM использовали JIT. Дополнительная информация в этой статье: http://www.ibm.com/developerworks/library/j-jtp12214/ и особенно: Теория и практика Java: динамическая компиляция и измерение производительности
.NET использует JIT или NGEN для генерации собственного кода, но как только сгенерирован собственный код, дальнейших (runtime) оптимизаций не выполняются.

Отличия в сторону и без намерения эскалировать священные войны, означает ли это, что Java Hotspot VM - это одно поколение впереди .Net. Будут ли эти технологии, используемые на Java VM, в конечном итоге найти свой путь в .NET runtime?

Ответ 1

Я никогда не сравнивал эти два сравнения, и я больше знаком с Sun JVM, я могу говорить только в общих терминах о JIT.

Всегда есть компромиссы с оптимизациями, и не все оптимизации работают все время. Однако, вот некоторые современные методы JIT. Я думаю, что это может быть началом хорошего разговора, если мы будем придерживаться технических характеристик:

анализ утечки
intrinsics
- http://bugs.sun.com/view_bug.do?bug_id=6823354
- http://weblog.ikvm.net/CommentView.aspx?guid=0404dd8a-88a8-4d62-9bcb-98324d57a2a9
оптимизация хвостового вызова
замена на стеке
блокировка укрупнения
блокировка elision
многопоточная сборка мусора
сборка мусора с низкой паузой
удаление вызова полиморфного метода
быстрое распределение кучи

Также есть функции, которые полезны, насколько хороши реализации VM:

возможность выбора между GC
реализация настроек каждого GC
параметры распределения кучи (например, рост)
блокировка страницы

На основе этих функций и многих других мы можем сравнивать виртуальные машины, а не только "Java" и ".NET", но, скажем, Sun JVM и IBM JVM в сравнении с .NET против Mono.

Например, Sun JVM не выполняет оптимизацию хвостового вызова, IIRC, но IBM делает.

Ответ 2

Они следуют двум различным стратегиям. Я не думаю, что один лучше другого.

.NET не интерпретирует байт-код, поэтому он должен JIT все, поскольку он выполняется, и поэтому не может сильно оптимизироваться из-за ограничений по времени. Если вам нужна сильная оптимизация в какой-то части кода, вы всегда можете ее активировать вручную или выполнить быстро, но небезопасная. Кроме того, вызов собственного кода легко. Подход, похоже, доставляет достаточно времени выполнения и вручную оптимизирует узкие места.
Современные JVM обычно интерпретируют большую часть кода, а затем выполняют оптимизированную компиляцию узких мест. Обычно это дает лучшие результаты, чем прямой JIT'ing, но если вам нужно больше, у вас нет unsafe в Java, а вызов собственного кода не очень. Таким образом, подход здесь состоит в том, чтобы максимально автоматизировать оптимизацию, поскольку другие параметры не так хороши.

В действительности приложения Java, как правило, во времени и хуже работают в сравнении с .NET.

Ответ 3

Очевидно, кто-то работал над чем-то похожим на ротор. У меня нет доступа к IEEE, поэтому я не могу прочитать реферат.

Динамическая перекомпиляция и оптимизация профиля для компилятора .NET JIT

Цитата из резюме...

Оценка структуры с использованием набор тестовых программ показывает, что производительность может улучшиться максимум 42,3% и в среднем на 9%. Наши результаты также показывают, что накладные расходы сбора точного профиля информации с помощью инструментария степень перевешивает преимущества оптимизация на основе профиля в нашей внедрения, что указывает на необходимость для внедрения методов, которые могут уменьшить такие накладные расходы.

Ответ 4

Вам может быть интересен SPUR, который является компилятором трассировки JIT. Основное внимание уделяется javascript, но он работает на CIL, а не на самом языке. Это исследовательский проект, основанный на Bartok, а не на стандартной .NET VM. В документе есть некоторые тесты производительности, показывающие, что он последовательно работает быстрее, чем SPUR-CLR, который является стандартным 3.5 CLR. Однако в нем не было никаких сообщений о будущем, связанных с текущей виртуальной машиной. Трассировки могут пересекать границы методов, которые не являются чем-то, что HotSpot делает AFAIK, JVM отслеживание JITs упоминается здесь.

Я бы не решался сказать, что .NET VM - это поколение, особенно учитывая все подсистемы, в частности дженерики. Как GC и DLR против invokedynamic compare Я не уверен, но есть много подробностей о них в таких местах, как channel9.