.NET Runtime против Java Hotspot: .NET одного поколения позади?

Question

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

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

• .NET использует JIT или NGEN для генерации собственного кода, но после генерации собственного кода дальнейшая оптимизация (во время выполнения) не выполняется.

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

Answer 1

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

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

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

В действительности Java-приложения имеют тенденцию работать немного лучшево времени и хуже в пространстве по сравнению с .NET.

Answer 2

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

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

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

Существуют также функции, которые полезны для хороших реализаций виртуальной машины:

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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