Статья "Java vs C++ "Shootout" Revisited" опровергает бытующее мнение о низкой производительности Java-приложений. Приводятся результаты сравнения производительности, в котором на некоторых тестах Java ( Sun Java 1.4.2_01 ) выигрывает по скорости у C++ (GCC 3.3.1).
Другие эксперименты по тестированию производительности Java:
- Java vs. C benchmarks (http://members.lycos.co.uk/wjgoh/JavavsC.html);
- Benchmarking Compilers and Languages for ia32 (http://www.coyotegulch.com/reviews/almabench.html) - Intel C++, gnu gcj, gnu g++, sun Java 2 JDK;
- Java vs. C++ for matrix multiplication (http://home.fnal.gov/~kuropat/snap/SNAP.html);
- Nine Language Performance Round-up: Benchmarking Math & File I/O (http://osnews.com/story.php?news_id=5602) - Java 1.3.1, Java 1.4.2, gcc, Python, Visual Basic/C#/C++/J#;
- Java 1.5alfa/1.4.2, vs C# vs Visual C++ vs Intell C++ benchmark (http://www.tommti-systems.de/go.html?http://www.tommti-syste...);
- Java vs. C (http://burk.hax.se/~nils/javavsc_eng.html)URL: http://www.sys-con.com/story/?storyid=45250
Новость: http://www.opennet.ru/opennews/art.shtml?num=3994
Может и быстрее, но сколько при этом сжирается ресурсов?
Вообще то GCC не самый лучщий компилятор в плане качества генерируемого кода. Так что, есть определенные сомнения в объективности...
>Вообще то GCC не самый лучщий компилятор в плане качества генерируемого кода. Так >что, есть определенные сомнения в объективности...А есть альтернативы (кроссплатформенные, бесплатные)?
А я что-то не понял, в каких попугаях там производительность мерялась? А то в табличке времена выполнения, судя по всему, а на графике просто столбцы без подписей, причем где время наибольшее, там столбец самый маленький. И что же этот график доказывает?
Т.е. по данной статье высокоуровневый язык выигрывает у низкоуровнего на низкоуровневой операциии ??? что то я не понимаю в этой жизни. Перехожу на VB
Ну, тут, похоже работает два сценария:1. Очень короткий (по времени выполнения) тест --- т.е. измеряется в основном время работы загрузчика
2. Неэффективное программирование на C++:
можно написатьsrting s( "string" );
for ( int i =......) {
do something
}а можно
for ( int i = .... ) {
string s("string" );
do something
}или вообще довести код до логического маразма.
Абсурд...
Млин...фальсификация:
for (int i=1; i<=n; i++) {
sprintf(buf, "%x", i);
X[strdup(buf)] = i;
}int c = 0;
for (int i=n; i>0; i--) {
sprintf(buf, "%d", i);
if (X[strdup(buf)]) c++;
}сравните с:
for (i = 1; i <= n; i++)
ht.put(Integer.toString(i, 16), new Integer(i));
for (i = 1; i <= n; i++)
// The original code converted to decimal string this way:
// if (ht.containsKey(i+""))
if (ht.containsKey(Integer.toString(i, 10)))
c++;типа, sprintf уж очень шустрая функция по сравнению с Interger.toString()...ага, щаз!
и там оно, наверняка, не единственное.
а ещё красиво: прога с оптимизацией под i386 работает шустрее, чем под i686 (хэши и работа с матрицами)...
Бред полный. Не поленился скачал сырцы. Это не тест это лажа.
Привожу пример (взял поменьше сырец)
#include <iostream>
#include <stdlib.h>
using namespace std;
unsigned long fib(unsigned long n) {
if (n < 2)
return(1);
else
return(fib(n-2) + fib(n-1));
}
int main(int argc, char *argv[]) {
int n = ((argc == 2) ? atoi(argv[1]) : 1);
cout << fib(n) << endl;
return(0);
}
где тут блин итерации с фиксацией времени??? или они меряли запуск-завершение проги? так я тут намеряю такого....
Ой чуушььь
>>JVM startup time was included in these results.
Ну млин это же вообще трындец....
ЗЫ:
А насчет более быстрой работы загрузчика Явы это тоже фигня. Я под Явой не великий спец, но тут на днях пришлось написать маленький хттп сервер на яве и первая загрузка после компиляции яваклассов занимает на глаз заметно времени (я тестил и под WinXP MS JVM и под FreeBSD JDK 1.1.8 - одинаково лагает) не знаю почему - не стал разбираться.
Здесь тупят.
Если так считать числа Фиббоначи, то я щас
хоть чем, например, питоном и C++ и Джаву уделаю влет.=================== fibo.py ==========
#!/usr/bin/env python
import sysdef fib(n):
fn = 1
fp = 1
fpp = 0
for i in range(1,n):
fpp, fp = fp, fn
fn = fp + fpp
return fndef main(argc, argv):
n = (argc == 2) and int(argv[1]) or 1
print >> sys.stdout, fib(n)if __name__ == '__main__':
main(len(sys.argv), sys.argv)
===============================================$ time ./fibo.py 100
573147844013817084101real 0m0.025s
user 0m0.018s
sys 0m0.008sВыводы делайте сами.
>Здесь тупят.
>Если так считать числа Фиббоначи, то я щас
>хоть чем, например, питоном и C++ и Джаву уделаю влет.
>
глянь на это:
http://www.bagley.org/~doug/shootout/bench/fibo/
Тут рекурсия- смотри внимательней.
JDK 1.1.8нашел под чем тестить.
речь идет о 1.4 и выше, а в 1.5 и графика теперь быстро работает.
>JDK 1.1.8
>
>нашел под чем тестить.
>речь идет о 1.4 и выше, а в 1.5 и графика теперь
>быстро работает.Я ж тебе говорю - не спец :) Меня и так уже обстебали - оказывается в пакаджи системные лезть нельзя (хотя не понятно почему???) а я не долго думая сделал класс от PlainSocketImpl.
Когда? Никогда!
Ну да ... автор показал что на С++ если изгалиться то можно написать такой код что будет тормозить не хуже Жабы.
При всем моем уважении к Джаве не могу не сказать в защиту ++:
Посмотрите что делает автор. Он просто не умеет готовить кошек 8-). К примеру, при создании матриц он пользуется malloc через анальное устройство. При нормальном подходе Джава делается раза в 1.5 как минимум. Другие примеры не смотрел и смотреть не буду ибо глупо.
Этого не может быть по поределению. Если кто смотрел сырцы джава машины, то, видимо, видил, что там реализовано прелбразование байт кода в нативный код. При выполнении джава программы всегда это преобразование выполняется, хотя, только один раз для запрашиваемого метода. В С++ это уже сделано компилятором. Код уже нативный. Вот и получается, что у джавы хош-нехош, а есть издержки, от которых ни куда не уйти. При прочих равных условиях JAVA всегда будет проигрывать C++.
Сам я ярый приверженей JAVA и терпеть не могу C++, но факт остается фактом. Конечно, если написать числодробилку, например, обращение разреженной матрицы 10000х10000 то время выполнения программы на джаве и С++ будет примерно одинаковым. Нативный код джава строит неплохой. А вот с ГУИ у джавы более серьезные проблемы. Тут и мерить не кудая.
>Этого не может быть по поределению. Если кто смотрел сырцы джава машины,
>то, видимо, видил, что там реализовано прелбразование байт кода в нативный
>код. При выполнении джава программы всегда это преобразование выполняется, хотя, только
>один раз для запрашиваемого метода. В С++ это уже сделано компилятором.
>Код уже нативный. Вот и получается, что у джавы хош-нехош, а
>есть издержки, от которых ни куда не уйти. При прочих равных
>условиях JAVA всегда будет проигрывать C++.
>Сам я ярый приверженей JAVA и терпеть не могу C++, но факт
>остается фактом. Конечно, если написать числодробилку, например, обращение разреженной матрицы 10000х10000
>то время выполнения программы на джаве и С++ будет примерно одинаковым.
>Нативный код джава строит неплохой. А вот с ГУИ у джавы
>более серьезные проблемы. Тут и мерить не кудая.Для Java есть AOT компиляторы которые компилируют в нативный код.
Dimon,
> Когда? Никогда!
Ну, неправда ваша. Как пример - джава сервлеты против CGI.
CGI скрипты через интерпретатор ессесно будут тормознее, но скажу по-секрету, грамотно написанный perl или php скрипт работают также как и сервлеты, например на участках парсинга (прааальный регэксп на перле вообще супэр, главное не забывать про однократную компиляцию шаблонов и т.п.)
а интересно, много ли народу пишут CGI на плюсах? кроме биллинговых систем, я по-моему и ничего вспомнить не могу... ну не на яве же их писать в самом деле :)
А я вам скажу по секрету - грамотно написанный сервлет и грамотно настроенный сервер - уделают CGI по самые помидоры.На яве пишут много биллинговых систем - это уже обсуждалось.
>А я вам скажу по секрету - грамотно написанный сервлет и грамотно
>настроенный сервер - уделают CGI по самые помидоры.
>
>На яве пишут много биллинговых систем - это уже обсуждалось.Ну естественно у cgi слишком много расходов на запуск.
А вот fastcgi или mod_perl разделают яву под орех.
>Ну естественно у cgi слишком много расходов на запуск.
>А вот fastcgi или mod_perl разделают яву под орех.сюда посмотри большой специалист:
http://www.bagley.org/~doug/shootout/craps.shtml
>CGI скрипты через интерпретатор ессесно будут тормознее, но скажу по-секрету, грамотно написанный
>perl или php скрипт работают также как и сервлеты, например на
>участках парсинга (прааальный регэксп на перле вообще супэр, главное не забывать
>про однократную компиляцию шаблонов и т.п.)
>а интересно, много ли народу пишут CGI на плюсах? кроме биллинговых систем,
>я по-моему и ничего вспомнить не могу... ну не на яве
>же их писать в самом деле :)я пишу на Сях (Не ++), довольно часто.
В основном, компоненты CMS (перекомпиляция данных из бд в статик, например).
Сам пишу на плюсах. Ткните меня носом пожалуйста в тесте methcall - ИМХО плюсовый код написан без ошибок ведущих к потере производительности. И все равно - на плюсах с оптимизацией:
real 0m16.384s
user 0m16.369s
sys 0m0.004s
на яве с серверной ВМ:real 0m2.091s
user 0m1.490s
sys 0m0.034s
Достаточно просто. Первый запуск программы - это подгрузка всяких библиотек. Серверная ВМ заранее их подгружает. Вообще, тесты всячески оптимизированы для того, чтобы показать, какая крутая эта жаба.
Зацените:for (int i=1; i<=n; i++) {
sprintf(buf, "%x", i);
X[strdup(buf)] = i;
}int c = 0;
for (int i=n; i>0; i--) {
sprintf(buf, "%d", i);
if (X[strdup(buf)]) c++;
}Интересно, без strdup здесь никак не обойтись? Ничего, что она динамически выделяет память, копирует строку в новый буффер? Нормально, что память под эти строки нигде не освобождается?
Против Java ничего не имею и очень бы хотел, чтобы она была попроизводительности на уровне(а то и выше) C++. Но тесты не объективны.