Для тех кто думает что ява тормозит )

Ребята провели сравнение скорости фреймворков,
для тех кто думает что C# удобно и быстро, посмотрите все раунды сравнения, будете приятно удивлены )))
http://www.techempower.com/blo... s-round-2/

1

diagon, 2 и 3 аргументы выдуманы. Вы слишком недооцениваете современные JVM.

1

Сообщение от diagon .net'овский байткод обязан компилироваться в нейтив, и только затем он может быть выполнен. Джава же живет в своем виртуальном мирке, делает много тяжелых проверок на безопасность кода

Для бенчмарков JVM запускают с опцией -server, когда код сразу компилируется в нативный. Также производительность меряют на "прогретом" состоянии, когда JIT уже вообще не вмешивается в вычисления.

Сообщение от diagon Все методы виртуальны по умолчанию. Это медленно само по себе, да еще и мешает оптимизациям вроде инлайнинга.

Это вообще не по делу, т.к. JVM абсолютно точно знает про все загруженные классы и если виртуальный по умолчанию метод нигде не переопределен, то все может заинлайнить без проблем. Также в специальных случаях, когда переопределений для виртуальной функции очень мало, может генерироваться код с проверкой класса и ветвлениями, который также может быть заинлайнен. Кроме того, при загрузке новых классов, переопределяющих виртуальную функию, будет происходить деоптимизация и нативный код будет перегенерирован.

Также есть escape analysis, когда при инлайнинге анализируется возможность выхода ссылки за пределы текущей области, и в некоторых случаях это позволяет избежать аллокации объектов в куче. Не все так плохо, но с value-типами и generics явный косяк получается...

0

Сообщение от kamre Для бенчмарков JVM запускают с опцией -server, когда код сразу компилируется в нативный.

Вы путаете. -server даже наоборот, увеличивает количество циклов выполнения на прогрев, после которых происходит компиляция в native.

0

diagon, кроме прожорливости по памяти, все утверждения неверны, да и память может быть оптимизирована использованием сторонних коллекций. По поводу женериков вообще нет проблем, так как они существуют только на этапе компиляции, далее в JVM всё стирается и приводится к Object и нет никакой проверки типов. Тормоза могут быть - но только по вине рефлекшена, но это скорее проблема проектирования приложения чем проблема платформы, ну и как вы знаете на 5% батлнеков всегда есть JNI который успешно выводит JVM на 1 уровнь с компилируемыми языками.

удобства/сахар - понятие субьективное, в 8ке вон будут лямбды, но мне кажется это всё от лукавого, так как тем кому надо язык с сахаром больше чем у C# уже давно и успешно ушли на скалу (на ней вообще можно динамически написать свой язык и им потом пользоваться). Генерация байткода у 2.10 версии по оптимизации не уступает javac, в языке примитивов нет вообще, при компиляции всё трансформируется в примитивы по возможности, чем очень ускоряется и при этом остаются все плюсы от java, так как можно юзать либки уже скомпиленые для java. В общем если рассматривать 2 платформы NET и JVM, то ещё неизвестно какая реально прогрессивнее.

0

Сообщение от kamre деоптимизация и нативный код будет перегенерирован

Забавно. Окей, если эти деоптимизации действительно существуют, то к тотальной виртуальности претензий нет.

Сообщение от kamre Для бенчмарков JVM запускают с опцией -server, когда код сразу компилируется в нативный

Для дотнета есть NGEN, он, в принципе, то же самое делает. Но, все-таки, компиляция в нейтив не всегда приемлема, особенно в случае с джавой, одной из главных киллер-фич которой является кроссплатформенность (на джаве же вроде бы не только сервера пишут?). Утверждалось отставание именно в выполнении байт-кода.

Сообщение от mutagen далее в JVM всё стирается и приводится к Object и нет никакой проверки типов

Речь шла не о самих генериках, а о их взаимодействии с примитивными типами. Приходится использовать обертки, каждая из которых считается полноценным объектом с точки зрения GC, да еще и боксится/анбоксится зачем-то.

Сообщение от mutagen есть JNI

Для дотнета есть PInvoke/CLI (иногда можно и unsafe кодом обойтись), но они годны только для оптимизации какого-то специфичного метода. Если приложение жирное и тормозит само по себе, то нейтив тут не поможет.

Сообщение от mutagen скалу

Для дотнета есть F#, но, как и scala, это все же не энтерпрайзный язык - слишком мало людей им владеют.

0

Сообщение от diagon Но, все-таки, компиляция в нейтив не всегда приемлема,

мне кажется вы не разобрались в вопросе JIT, он включается тогда когда вы уже на какой либо платформе и вот тогда JVM по мере разогрева (сбора статистики) компилит самые частые вызовы в нативку и делает их JNI подобными (по утверждениям метров от JVM строительства на сегодняшний день максимально использовать векторизацию интел камня может только компилятор от intel и JIT в JVM) и в принципе даже нет необходимости в ручном JNI
поэтому она всегда приемлема и во всех апп серверах она есть, многие после запуска даже делают стресс тест для разогрева, чтобы JVM вышла на рабочий режим

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

0

Сообщение от turbanoff Вы путаете. -server даже наоборот, увеличивает количество циклов выполнения на прогрев, после которых происходит компиляция в native.

Да, перепутал... Эту опцию для более агрессивных оптимизаций включают. А для более быстрого "прогрева" есть отдельные опции.

0

Сообщение от mutagen компилит самые частые вызовы в нативку и делает их JNI подобными

Дотнетовский джит работает по другому принципу - он особо не собирает статистику и просто молча все компилирует в нейтив, причем не более одного раза. За счет этого джит от дотнета быстрее. Вот касательно качества генерируемого кода - не совсем понятно, как накапливаемая статистика может помочь его оптимизировать. Что касается векторизации - виртуальная машина и без всякой статистики знает, на каком компьютере она находится. Однако, я как-то не верю, что java-jit умеет векторизацию - ведь для нее надо либо узнавать нужную информацию на этапе компиляции и забивать ее в байткод (но, насколько я знаю, этого не происходит), либо таки использовать накопленную статистику чтобы определить эффективность векторизации, но для этого потребуется накапливать действительно много статистики (не думаю, что джит может себе это позволить). Окей, предположим, что все-таки используется рантаймовая статистика, корректно распознаются и оптимизируются циклы. На это уходит немало рантаймового времени. Вопрос - зачем? Векторизация обычно дает выигрыш в достаточно специфичных случаях, и если она действительно нужна, то проще отпрофилировать и использовать JNI. На мой первый взгляд это просто жалкая попытка избавится от нативных оптимизаций и пустая трата рантаймового времени. Впрочем, меня это заинтересовало, попробую погонять бенчмарки на досуге.

поэтому она всегда приемлема и во всех апп серверах она есть

Но, повторюсь, джава ведь не только для разработки серверов используется? Впрочем, видимо, в основном именно для этого, тогда все эти динамические оптимизации приобретают смысл. Дотнет же не сконцентрирован на серверах и ему это не нужно.

а так как по утверждениям метров от JVM строительства на сегодняшний день максимально использовать векторизацию интел камня может только компилятор от intel и JIT в JVM

А можно пруф? Просто я знаю как минимум 2 плюсовых компилятора (один из них, кстати, компилирует в свой байткод), которые обходят интеловский компилятор в некоторых кейсах.

0

Сообщение от diagon А можно пруф?

не уверен что в этом посте и каментах много, но чесслово больше лень искать
http://elizarov.livejournal.com/23698.html
а тут можно зарыться вглубь http://people.apache.org/~xli/... zation.pdf
старовато но факт

0

diagon, почему-то вы упомянули только векторизацию. Наверно потому что, это основное средство оптимизации native/AOT компиляторов?
У JVM есть намного больше данных, и доступ к оптимизациями прямо в рантайте, что не доступно для других компиляторов.

Вообще-то этот спор .net vs java довольно странен, учитывая свободу которую дает стандарт для реализации JVM, который даже позволяет компилировать код в натив(Excelsior JET) или использовать AOT + JIT(JRockit).

0

Сообщение от turbanoff почему-то вы упомянули только векторизацию

Например потому, что дотнет ее не умеет. Моно вроде умеет, но она там не автоматическая (т.е. приходится ручками хардкодить нужные инструкции). Ну и это таки вполне ощутимая оптимизация.

Сообщение от turbanoff У JVM есть намного больше данных, и доступ к оптимизациями прямо в рантайте, что не доступно для других компиляторов.

Ну вот мне и интересно, что это за "рантаймовые" оптимизации. Насколько я понял, это что-то вроде profile-driven оптимизаций, только профилятор при этом работает не перед компиляцией, а прямо в рантайме. Ну и опять же много информации в рантайме не соберешь - плюсовые программы замедляются иногда в несколько раз при включенном профилировании, для рантайма это неприемлемо.

Как-нибудь попробую переписать это на джаву, чтобы проверить векторизацию.

0

Сообщение от diagon Как-нибудь попробую переписать это на джаву, чтобы проверить векторизацию.

главное перед замерами погонять этот же код сотню тыщ раз при запуске с java -server и потом уже выполнять замеры (при этом не стоит форсить JVM на более скорый JIT, надо дать собрать статистику)

0

Сообщение от diagon Ну вот мне и интересно, что это за "рантаймовые" оптимизации.

Вот, вроде нашел список - https://wikis.oracle.com/displ... acticIndex

Добавлено через 2 минуты

Сообщение от diagon плюсовые программы замедляются иногда в несколько раз при включенном профилировании

Так нативные профайлеры вынуждены подстраиваться под железо/ОС. Они не могут, как JVM, при загрузке класса встроить некоторые инструкции прямо в код.

0

из Википедии, можете не верить

Миниатюры

 

0