Развенчание мифов о джаве

>накладные расходы на уборку говна легко перекроют все «оптимизации»

усматривая здесь неявный ∀ предлагаю самозакопаться

> Половина пользователей ноет о тормозах, у другой половины «не тормозит».

Просто эти пользователи, видать, Эклипс не юзали, и им сравнить не с чем.

Займитесь чем-нибудь полезным, блджад.

чем?

специально под это дело заточенный «тестик»

специально заточенный :)

чуть-ли не заинлайнил все вызовы

запишем: жаба отлично подходит для написания говнокода вида int f(int x, int y){return x+y;}

>специально заточенный :)

а как ты покажешь работу некой фичи без «специально заточенного» теста?

запишем: жаба отлично подходит для написания говнокода вида int f(int x, int y){return x+y;}

запишем, чукча^Wckotinko писатель а не читатель - я ни слова не сказал про «суперскорость» java-монстров, а лишь подтвердил наличие оптимизатора в JIT-е, который срабатывает при определённых оговоренных ситуациях. Анон спрашивал именно про него

Интересная работа сборщика мусора http://habrahabr.ru/blogs/java/68577/ «Явой занялся я недавно, и столкнулся с интересной проблемой связанной с динамическим переопределением методов во время исполнения. После выхода из переопределенного метода терялась ссылка на объект»

100% программ состоят из подобного говнокода

скандалы, интриги, расследования, развенчания мифов о джаве: http://habrahabr.ru/blogs/java/61658/

> В результате jvm сообразил, что реализация интерфейса единственная и нахрен чуть-ли не заинлайнил все вызовы тестового класса.

То есть все йоба-оптимизации исчерпываются агрессивный инлайнингом, я верно понял? А инлайнинг рекурсивных ф-й жабоканпелятор хотя бы умеет?

>То есть все йоба-оптимизации исчерпываются агрессивный инлайнингом, я верно понял?

Я ничего не говорил про «все». Значит - ты понял не правильно. На счёт «агрессивнго инлайнинга» - какой ещё ООПэшный компилятор сможет заменить вызов виртуального метода «прямым вызовом»? А инлайнинг небольших «статик-методов» - это банальщина.

А инлайнинг рекурсивных ф-й жабоканпелятор хотя бы умеет?

спеки jvm/javac тебе в помощь

P.S. Ещё раз для чукчей-писателей: на кой вам эти жабкины «плюшки»? Ни эклипс, ни нетбинс, ни прочие «десктопные» приложения от этого на вашем компьютере быстрее работать не станут. Равно как вся «нативность» [open|libre]office ни как не спасает его от тормозов. Ну и?

> На счёт «агрессивнго инлайнинга» - какой ещё ООПэшный компилятор сможет заменить вызов виртуального метода «прямым вызовом»?

Там еще и деоптимизация этого «инлайнинга» должна быть, т.к. если в runtime загрузится еще один класс-наследник, переопределяющий вирутальную функцию, то сгенерированый код с «инлайнингом» уже некорректен. Кстати, в .NET такое тоже есть?

> какой ещё ООПэшный компилятор сможет заменить вызов виртуального метода «прямым вызовом»?

gcc + lto

А он уже работает?

да

>gcc + lto

оопс, рад за них

«отдельные ситуации» в жизни встречаются обычно в тех случаях, когда программер на с++ не знает слов inline pure и const. а их жыды придумали не только для того, чтоб есть младенцев.

man http://gcc.gnu.org/wiki/LinkTimeOptimization

Despite the «link time» name, LTO does not need to use any special linker features.

просто стадию кодогенерации поставили позже сброса в объектный файл.

к убогой реализации с++ abi это никак не относится

>«отдельные ситуации» в жизни встречаются обычно в тех случаях, когда программер на с++ не знает слов inline pure и const.

это отменяет наличие оптимизатора в jvm?

>к убогой реализации с++ abi это никак не относится

не представляю, как _ничего не зная_ о структуре программы на с++ пытаться оптимизировать вызов виртуальных методов. Или я чего-то не догоняю?

Это просто страницы в память поднимаются и кеш процессора наполняется чем надо.

Никакой не JIT.

JIT вообще мало что умеет оптимизировать, потому что в байткоде оптимизировать особо нехрен, не надо верить маркетоидным сказкам Oracle и жабофанатиков.

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

Для хоть сколько-нибудь вменяемых оптимизаций нужна куча метаинформации о структуре кода, и такие оптимизации могут проводиться только самим первичным компилятором высокоуровневого языка. К тому же, многие оптимизации - дико ресурсозатратны, производятся в несколько проходов и т.д., и в JIT их просто не впихнуть.

JIT вообще единственно что делает полезного, так это компилит байткод и отдает его на исполнение процессору, вместо интерпретации виртуальной машиной, и вот это единственно что скорость значительно повышает(ну по сравнению с интерпретацией).

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

lovesan

такое впечатление, что тебя кто-то жабкой трахнул, и от этого у тебя вот такой понос

Ну просто видишь, про плюсы толкать телеги уже не модно, все и так понимают что они говно. Другое дело жаба.

Так и жаба говно, и у хаскеля с лиспами проблем хватает... Или обеспечивать мир газом - национальная черта?