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

Сообщение Re[51]: dotnet vs java 2016-2020 от 19.10.2016 12:15

Изменено 19.10.2016 12:33 Serginio1

Старый текст
Новый текст
Разница

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

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

S>>·>inline тоже делается. Притом после virtual call elimination. Круто ведь — возможность инлайна виртуальных функций!
S>>·>https://blog.jooq.org/2016/07/19/the-java-jit-compiler-is-darn-good-in-optimization/
S>> То есть это для мобильников? И это касается только итераторов. Это и в .Net есть
S>> Интерес представляет инлайнинг компараторов и прочих делегатоа прежде всего в дженериках.
S>>На подобии roslyn-linq-rewrite
·>На уровне байткода никаких дженериков и делегатов нет, JIT-у пофиг что инлайнить. Компаратор такой же класс, имплементирующий интерфейс, как и всё остальное.
В том чиле и метод. Это касается прежде всего int, byte, Int64 где вызов метода 1+1, значительно дольше самого сложения, сравнения

S>>>>·>Покажи.
S>>>> https://msdn.microsoft.com/ru-ru/library/dn643729(v=vs.110).aspx
S>>>>https://social.msdn.microsoft.com/Forums/en-US/f650e4d4-578f-4ef9-84d1-0d3eac9147c9/uwp-net-native-vs-net-jit-benchmark?forum=wpdevelop
S>>>> По сборке мусора здесь
S>>>>https://msdn.microsoft.com/pl-pl/windows/uwp/debug-test-perf/improve-garbage-collection-performance
S>>·>А, фу-ты. Я думал быстрее, чем java. А так это просто значит, что обычный fw медленно работает, native fw — нормально, наконец-то.
S>> То есть ты сравнивал мобильниках на java 5 и 6 с .Net Native?
·>Нет, не сравнивал. Я вообще с мобильниками дела не имею. Но я бы удивился, если бы джава отстала по перформансу.
Для мобильных платформ там совсем другие VM.

S>>>> Так компилируется на стороне магазина. С мобильного указываются параметры и под него уже компилится или бертся из уже скомпиленных. Количество марок аппаратов ограничено.
S>>·>Можно и так, запускай ART-конверсию на серваке... Но непонятно что это даёт, кроме как лишнюю нагрузку на сервера магазина.
S>>·>И представь себе — выходит очередная версия компилятора с новыми фичами оптимизации и весь мир ломится на несчастные сервера магазина для обновления _всех_ приложений под _все_ платформы.
S>> Угу. Весь мир Андроида сидит на java 5 или как раз с 6.
·>Какая разница кто на чём сидит? Комбинации, однако: dotnet vs java 2016-2020.
То есть VM для вех версий одна? Да и андроидов разных полно.
S>>>>>> Нужна. Здесь на форуме много копий по этому поводу сломано.
S>>>>·>Обсускаторы для java тоже есть.
S>>>> Есть но машинный код лучше.
S>>·>И компилятор тоже есть, для особо страждущих. https://www.excelsiorjet.com/
S>> Еще раз смотрим версию, и вспоминаем на чем народ на Андроид до сих пор сидит
·>https://www.excelsior-usa.com/jetdladdon.php?jetversion=700

А где Андроид? Мы то говорим про мобильные платформы. .Net Native выгоден прежде всего для мобильных устройств.
Опять же для .Net Native не нужна установка .Net Core или CLR

Re[51]: dotnet vs java 2016-2020

NET Native и NGEN

Генератор образов в машинном коде (NGEN) компилирует сборки в машинный код и устанавливает их в кэш образов в машинном коде на локальном компьютере. Однако хотя NGEN, как и .NET Native, создает машинный код, NGEN имеет существенные отличия от .NET Native:

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

• NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.

• Образы NGEN, как правило, хрупкие. Например, обновление или изменение зависимости обычно требует, чтобы сборки, которые его используют, также были пересозданы NGEN. Это особенно верно для системных сборок в библиотеке классов .NET Framework. В противоположность этому .NET Native позволяет обслуживать приложения независимо друг от друга.