Информация об изменениях

Сообщение Re[9]: C# - from indians by indians от 28.05.2015 23:43

Изменено 28.05.2015 23:44 Артём

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

Aё>>Я бы не был уверен насчёт жита дотнета- взять хотя бы его неспособность житить лишь горячие участки. Насчёт до предела оптимизаций- Matematica написана на Java и умеет CUDA, т.е. работает быстрее, а память- не ресурс.


S>Hotspot jit во многом нужен из-за отсутствия value types в яве.

Это открытие тянет на Нобелевскую премию

S> Без них разница с шарпом непринципиальна (что как бы очевидно, в рамках времени, отводимого на jit, ничего сильно пристойного всё равно не сделать).

Просто уточню, что стандартные коллекции Java боксят любой объект, потому они медленнее, чем в .NET где есть реализация коллекций под встроенные типы. Но для Java есть сторонние коллекции- под встроенные типы. Теперь по JIT-у — .NET-й не может интерпретировать, потому он всё подряд житит. А качественно оптимизировать jit-й код требует ресурсов, значит есть компромиссы. В отличие от Java JIT, где житятся только горячие участки и может неоднократно jit-ть поверх на критических вещах.

S>В свежих релизах с .NetCore и RyuJit положение потихоньку выправляется, особенно с учётом .net native и возможности трансляции в llvm. Но, очевидно, в ближайщую пару релизов ничего сильно не изменится — сначала надо переползти толком на новые платформы, ничего сильно не потеряв. Дальше — будем посмотреть.

В переводе на русский- Майкрософт, как всегда, налажал и не спешит исправляться.
Re[9]: C# - from indians by indians
Здравствуйте, Sinix, Вы писали:

Aё>>Я бы не был уверен насчёт жита дотнета- взять хотя бы его неспособность житить лишь горячие участки. Насчёт до предела оптимизаций- Matematica написана на Java и умеет CUDA, т.е. работает быстрее, а память- не ресурс.


S>Hotspot jit во многом нужен из-за отсутствия value types в яве.

Это открытие тянет на Нобелевскую премию

S> Без них разница с шарпом непринципиальна (что как бы очевидно, в рамках времени, отводимого на jit, ничего сильно пристойного всё равно не сделать).

Просто уточню, что стандартные коллекции Java боксят любой элемент, потому они медленнее, чем в .NET где есть реализация коллекций под встроенные типы. Но для Java есть сторонние коллекции- под встроенные типы. Теперь по JIT-у — .NET-й не может интерпретировать, потому он всё подряд житит. А качественно оптимизировать jit-й код требует ресурсов, значит есть компромиссы. В отличие от Java JIT, где житятся только горячие участки и может неоднократно jit-ть поверх на критических вещах.

S>В свежих релизах с .NetCore и RyuJit положение потихоньку выправляется, особенно с учётом .net native и возможности трансляции в llvm. Но, очевидно, в ближайщую пару релизов ничего сильно не изменится — сначала надо переползти толком на новые платформы, ничего сильно не потеряв. Дальше — будем посмотреть.

В переводе на русский- Майкрософт, как всегда, налажал и не спешит исправляться.