Когда Java быстрее C++ - сравнение производительности

Нечем тут гордится что на C++ писать не умеют !

Абсолютно не объективный тест. Где соотношение количества ресурсов, которые отжирают для этих целей хоть клиентские, хоть серверные приложения java в сравнении с приложениями, закодированными на c++? опкод всегда будет быстрее java и это факт...

Гы гы гы... Оптимизированно написаный Java код работает быстрее чем неоптимально написаный C++ код :-). Реально мужик доказал только то, что человек, который умеет писать нормальный код... может этот код сделать быстрым :-). вне зависимости от платформы :-).

Если при кодировании после каждой строчки кода ставить строку for ( int i = 0 ; i < 65535; i ++); только тогда ява будет быстрее :)))

> опкод всегда будет быстрее java и это факт... Ошибка ;-). Например вызов метода (особенно виртуального) в Java будет быстрее :-). Или например работа с RTTI в C++ на некоторых компиляторах может дать хорошую потерю производительности, а на Java все будет тип-топ :-). Много примеров, но суть в том, что дядька спец по Java, а вот в C++ он не шарит ;-).

Нда, на синтетических тестах действительно бывают такие приколы.

>Если при кодировании после каждой строчки кода ставить строку for ( int i = 0 ; i < 65535; i ++); только тогда ява будет быстрее :)))

Только в том случае, если компилятор эту строчку не оптимизирует)

IMHO нюанс не в качестве кода, а в сборке мусора. С++ вызывает сборщик мусора для обьекта сразу, как тот перстал существовать. Java - как в голову придет.

В остальном код на C++ много эффективнее. Осталось придумать задачу, где требуется серьезная работа для сборщика мусора и С++ начнет проигрывать.

токо вот вопрос... а кто же писал оракловый инсталятор? И чего же он так тормозит? Может лохи писали? (хотя еще не проверял как работают проги под novm java, но думаю чудес не предвидится)

А кто писал KDE? Чего оно тогда так тормозит (особенно при загрузке)?

>С++ вызывает сборщик мусора для обьекта сразу, как тот перстал
>существовать.
Похоже я от жизни отстал. В какой из реализаций C++ появился garbage collector?

Статейка из разряда "На каких этапах наши паровозы быстрее гоночных болидов".Дурилка для маркетологов. Блин когдаж здохнет наконец этат утопия...

верятно имелись ввиду деструкторы

а вот по поводу КДЕ. Думаю, если такую весч напишут на Жаба... будет пипец.

> Блин когдаж здохнет наконец этат утопия...
Никогда. Ибо не утопия это, а весьма хорошая платформа :-).

> а вот по поводу КДЕ. Думаю, если такую весч напишут на Жаба... будет пипец.

Да ничего особенного не будет. Разницы ты не заметишь.

>а вот по поводу КДЕ. Думаю, если такую весч напишут на Жаба... будет
>пипец.
Все будет нормально. Будет Java работать себе и память будет кушать... только что внизу оно будет на GTK или на QT написано... и все будет тип-топ.

Я не понимаю только одного, чтож вам Java как кость в горле? У неё своя ниша, свои задачи с которыми к слову говоря она прекрасно справляется. Мне вот у умников которые её ругают спросить хочется: а на чём они предлагают работать если нужна кроссплатформенность, серверная часть, не зависимость от БД? На С++ что ли? Или на Перле с Питоном? Давайте не будем бредить. То что Жава от релиза к релизу становится всё быстрее и удобнее по моему это всем на руку.

>>В какой из реализаций C++ появился garbage collector

ИМЗО имелось в виду освобождение памяти после того, как объект выходит из зоны видимости

> в котором на некоторых тестах Java ( Sun Java 1.4.2_01 ) выигрывает по скорости у C++ (GCC 3.3.1).

Нда, выбрали самый быстрый компилятор, да уж - ветку 3.4X пробовать не захотели...

Если сравнивать на тех областях, где либы явы быстрее, то тогда конечно... Тест совершенно не обоснованный и бессмысленный - пиар...

>>С++ вызывает сборщик мусора для обьекта сразу, как тот перстал
>>существовать.
>Похоже я от жизни отстал. В какой из реализаций C++ появился garbage
>collector?

Наверное, уважаемый eda вспоминал поговорку "чисто не там, где убирают, а там, где не мусорят" :)

>ИМЗО имелось в виду освобождение памяти после того, как объект выходит
> из зоны видимости
Теперь остается только гадать :-).

> Если при кодировании после каждой строчки кода ставить строку for ( int i = 0 ; i < 65535; i ++); только тогда ява будет быстрее :)))

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

Спецязыки для этого и делают - для применения в своей области... А Java вообще сразу писали для embedded system... нда... :)))))))

У Ораклового инсталятора JDK "Oracle JDK 1.1.7.30o (JDK 1.1.7B based)", потому и тормозит.

>Наверное, уважаемый eda вспоминал поговорку "чисто не там, где
>убирают, а там, где не мусорят" :)
Да да да ;-).

ММММ не расчехлился.... причем сборщтк мусора и С++ ??? Мусорщик - есть примочка ВМов. Хотя конечно если мусорщиком считать free() ?! То вряд ли гарбаж коллектор (мля слово то какое) тут вряд ли сие обскачет

> IMHO нюанс не в качестве кода, а в сборке мусора. С++ вызывает сборщик мусора для обьекта сразу, как тот перстал существовать. Java - как в голову придет.

Это тоже верно - если сборщик ни разу не запустится, то потом система просто пометит память как пустую, одним махом, и скорость будет приличной :)))) Чем каждый раз вызывать деструктор, который объявлен например, но ничего не делает.

> Это тоже верно - если сборщик ни разу не запустится, то потом система просто пометит память как пустую, одним махом

"Потом" -- это после выключения компьютера чтоли :) ?

> "Потом" -- это после выключения компьютера чтоли :) ?

В самую точку! После завершения работы программы - когда VM выключат :))))

Ну если делать так:

if (++this->counter >= this->count_max)

и так:

Toggle *toggle = new Toggle(val);
for (int i=0; i<n; i++) {
val = toggle->activate().value();
}
cout << ((val) ? "true" : "false") << endl;
delete toggle;

вместо того чтобы разместить toggle на стеке, то конечно C++ окажется медленнее. Вообще во всём этом "сравнении производительности" чувствуется явно предвзятое отношение к C++ и код на последнем подгоняется под код на джаве...

> вместо того чтобы разместить toggle на стеке, то конечно C++ окажется медленнее.

Как насчет того, что в Java объекты всегда создаются именно способом "Toggle toggle = new Toggle()" ? Вроде ж нет априорного преимущества перед C++?

> око вот вопрос... а кто же писал оракловый инсталятор? И чего же он так тормозит? Может лохи писали? (хотя еще не проверял как работают проги под novm java, но думаю чудес не предвидится)

Оракл гордится своими старыми jdk. Замечательный пример - jdk 1.1.8.113, стоявший у нас на работе =)))

>>С++ вызывает сборщик мусора для обьекта сразу, как тот перстал
>>существовать.
>Похоже я от жизни отстал. В какой из реализаций C++ появился garbage collector?

Вот честно, не знаю. Завершение жизни обьекта в JAVA устроено иначе. Цитировать книжки Java не хочеться, а в моей голове без практики ничего не задерживаеться ;-).
Могу приврать, но в Java можно как-то оживить умерший обьект, до которого не дошли руки сборщика мусора. Так что есть некоторый маневр и в этом.

А какие РЕАЛЬНЫЕ идеи есть по поводу этого теста ? Байт код не может выполняться быстрее чем машкод.
Эффективность сборки мусора, единственное, что пришло в голову.

Не забывайте ставить ссылки на первоисточник текста новости !!!

http://www.opennet.ru/opennews/art.shtml?num=3994

2 eda:
> а в моей голове без практики ничего не задерживаеться ;-).
Угу. Все, кому надо уже поняли :-).

> Мусорщик - есть примочка ВМов.
В корне не верно :-). Но в C++ его-таки нативного нет и быть не может ;-)...

Я о том и говорю, что в java объекты создаются исключительно в куче, тогда как в C++ их можно создавать и на стеке и это зачастую (и уж точно в данном конкретном случае) гораздо быстрее. Код на C++ подгонялся под java, а не наоборот.

>А какие РЕАЛЬНЫЕ идеи есть по поводу этого теста ? Байт код не может >выполняться быстрее чем машкод. >Эффективность сборки мусора, единственное, что пришло в голову.

Повторить! Что-он попутал.... гадом буду!

> for ( int i = 0 ; i < 65535; i ++);

я долго думал, почему именно "65535" ?? это ведь 2^16-1, а int, наскоко мне известно (даже более того - я в этом уверен) - 4-х байтовый... (по крайней мере в нормальных системах - aka linux))

> Вот честно, не знаю. Завершение жизни обьекта в JAVA устроено иначе.

> Эффективность сборки мусора, единственное, что пришло в голову.

Способность к аналитическому мышлению -- очень хорошее качество, но в данном случае оно вас несколько подвело: в C++ нет "легализованного" сборщика мусора. Оговорки: под сборкой мусора мы понимаем автоматическое (без участия человека) освобождение неиспользуемой памяти в куче; существующим для C++ "third-party" реализациям сборщиков мусора мы выражаем наше почтение, но не считаем их частью стандартной технологии.

> Могу приврать, но в Java можно как-то оживить умерший обьект, до которого не дошли руки сборщика мусора. Так что есть некоторый маневр и в этом.

Вы не приврали, получить ссылку на объект после освобождения всех иных ссылок можно. Но непонятно, в чем тут "маневр".

> А какие РЕАЛЬНЫЕ идеи есть по поводу этого теста ? Байт код
> не может выполняться быстрее чем машкод. Эффективность сборки
> мусора, единственное, что пришло в голову.

Вообще-то на этот вопрос должен был ответить сам автор "исследования". И то, что он такого ответа не дал ещё раз подчеркивает его "ценность".

я где-то бенчмарк компайлеров видел - там идея та же: Жаба рулит.

но даже там на графиках видно, что тригонометрия /да и не только - всё что связано с фпу/ нуууу оооочень тормозииит...

> 4-х байтовый... (по крайней мере в нормальных системах - aka linux))

4 байта = 32 бита (i386), на 64 битной системе инт буит 8 байт занимать...

hash.cpp: for (int i=1; i<=n; i++) { sprintf(buf, "%x", i); X[strdup(buf)] = i; }

ясно понятно что X[a]=.. гораздо медленей чем просто ht.put в java и X.insert в с++

> Я о том и говорю, что в java объекты создаются исключительно в куче, тогда как в C++ их можно создавать и на стеке и это зачастую (и уж точно в данном конкретном случае) гораздо быстрее. Код на C++ подгонялся под java, а не наоборот.

Кстати, много ли вы в этих тестах увидели операторов 'new' (я о C++ коде) ? Я вот ткнулся наудачу в несколько файлов и ни одного не обнаружил. Если кому интересно, где исходники, ходите сюда:

http://www.kano.net/javabench/src/cpp/

2 nelapsi:
"О сколько нам открытий чудных..."

>а int, наскоко мне известно (даже более того - я в этом уверен) - 4-х
>байтовый...
Ты абсолютно не прав. int - размером в маш. слово. а оно может быть 1/2/3/4/5/6/7/8/9 байт. В зависимости от платформы :-). Думаешь для чего в кроссплатформенных аппликухах введены типы int16/int32 итд? ;-)

int - двцхбайтовый long - четырех

Pi (17.06.2004 14:05:22):

> на 64 битной системе инт буит 8 байт занимать...

Нет.

На большинстве современных 64-битных систем int занимает 4 байта.

2 Die-Hard:
Можно списочек? :-). Я вот помню что на i86 int был 2 байта ;-).

есть такое правило
sizeof(int) == sizeof(void *)
:-) если у вас на 64 битной платформе sizeof(void *) == 4 то хм ;-)... нахрена вам 64 битная платформа? :)

Именно на С++ это и пишут