Сообщение 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. Но, очевидно, в ближайщую пару релизов ничего сильно не изменится — сначала надо переползти толком на новые платформы, ничего сильно не потеряв. Дальше — будем посмотреть.
В переводе на русский- Майкрософт, как всегда, налажал и не спешит исправляться.
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. Но, очевидно, в ближайщую пару релизов ничего сильно не изменится — сначала надо переползти толком на новые платформы, ничего сильно не потеряв. Дальше — будем посмотреть.
В переводе на русский- Майкрософт, как всегда, налажал и не спешит исправляться.
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. Но, очевидно, в ближайщую пару релизов ничего сильно не изменится — сначала надо переползти толком на новые платформы, ничего сильно не потеряв. Дальше — будем посмотреть.
В переводе на русский- Майкрософт, как всегда, налажал и не спешит исправляться.