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

Ответ 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.