|
| 1.2, Nick (??), 14:03, 17/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Вообще то GCC не самый лучщий компилятор в плане качества генерируемого кода. Так что, есть определенные сомнения в объективности... | | |
| |
| 2.6, Александр (??), 15:28, 17/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
 >Вообще то GCC не самый лучщий компилятор в плане качества генерируемого кода. Так >что, есть определенные сомнения в объективности...
А есть альтернативы (кроссплатформенные, бесплатные)? | | |
|
| 1.3, coctic (?), 14:34, 17/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А я что-то не понял, в каких попугаях там производительность мерялась? А то в табличке времена выполнения, судя по всему, а на графике просто столбцы без подписей, причем где время наибольшее, там столбец самый маленький. И что же этот график доказывает? | | |
| 1.4, Аноним (1), 14:43, 17/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Т.е. по данной статье высокоуровневый язык выигрывает у низкоуровнего на низкоуровневой операциии ??? что то я не понимаю в этой жизни. Перехожу на VB | | |
| 1.5, ptr (??), 15:16, 17/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Ну, тут, похоже работает два сценария:
1. Очень короткий (по времени выполнения) тест --- т.е. измеряется в основном время работы загрузчика
2. Неэффективное программирование на C++:
можно написать
srting s( "string" );
for ( int i =......) {
do something
}
а можно
for ( int i = .... ) {
string s("string" );
do something
}
или вообще довести код до логического маразма.
| | |
| 1.8, Аноним (1), 18:29, 17/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Млин...фальсификация:
for (int i=1; i<=n; i++) {
sprintf(buf, " , i);
X[strdup(buf)] = i;
}
int c = 0;
for (int i=n; i>0; i--) {
sprintf(buf, ", 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 (хэши и работа с матрицами)... | | |
| 1.9, lom (?), 01:17, 18/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Бред полный. Не поленился скачал сырцы. Это не тест это лажа.
Привожу пример (взял поменьше сырец)
#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.
Ну млин это же вообще трындец.... | | |
| |
| 2.10, lom (?), 01:25, 18/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
ЗЫ:
А насчет более быстрой работы загрузчика Явы это тоже фигня. Я под Явой не великий спец, но тут на днях пришлось написать маленький хттп сервер на яве и первая загрузка после компиляции яваклассов занимает на глаз заметно времени (я тестил и под WinXP MS JVM и под FreeBSD JDK 1.1.8 - одинаково лагает) не знаю почему - не стал разбираться. | | |
| 2.19, jah (?), 14:02, 18/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
 Здесь тупят.
Если так считать числа Фиббоначи, то я щас
хоть чем, например, питоном и C++ и Джаву уделаю влет.
=================== fibo.py ==========
#!/usr/bin/env python
import sys
def fib(n):
fn = 1
fp = 1
fpp = 0
for i in range(1,n):
fpp, fp = fp, fn
fn = fp + fpp
return fn
def 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
573147844013817084101
real 0m0.025s
user 0m0.018s
sys 0m0.008s
Выводы делайте сами. | | |
|
| 1.11, Nikolaev D. (?), 07:26, 18/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 JDK 1.1.8
нашел под чем тестить.
речь идет о 1.4 и выше, а в 1.5 и графика теперь быстро работает. | | |
| |
| 2.17, lom (?), 11:49, 18/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
>JDK 1.1.8
>
>нашел под чем тестить.
>речь идет о 1.4 и выше, а в 1.5 и графика теперь
>быстро работает.
Я ж тебе говорю - не спец :) Меня и так уже обстебали - оказывается в пакаджи системные лезть нельзя (хотя не понятно почему???) а я не долго думая сделал класс от PlainSocketImpl. | | |
|
| 1.13, Andrey (??), 09:32, 18/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну да ... автор показал что на С++ если изгалиться то можно написать такой код что будет тормозить не хуже Жабы.
| | |
| 1.14, Сергей (??), 09:58, 18/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 При всем моем уважении к Джаве не могу не сказать в защиту ++:
Посмотрите что делает автор. Он просто не умеет готовить кошек 8-). К примеру, при создании матриц он пользуется malloc через анальное устройство. При нормальном подходе Джава делается раза в 1.5 как минимум. Другие примеры не смотрел и смотреть не буду ибо глупо. | | |
| 1.15, Вадя (?), 10:53, 18/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Этого не может быть по поределению. Если кто смотрел сырцы джава машины, то, видимо, видил, что там реализовано прелбразование байт кода в нативный код. При выполнении джава программы всегда это преобразование выполняется, хотя, только один раз для запрашиваемого метода. В С++ это уже сделано компилятором. Код уже нативный. Вот и получается, что у джавы хош-нехош, а есть издержки, от которых ни куда не уйти. При прочих равных условиях JAVA всегда будет проигрывать C++.
Сам я ярый приверженей JAVA и терпеть не могу C++, но факт остается фактом. Конечно, если написать числодробилку, например, обращение разреженной матрицы 10000х10000 то время выполнения программы на джаве и С++ будет примерно одинаковым. Нативный код джава строит неплохой. А вот с ГУИ у джавы более серьезные проблемы. Тут и мерить не кудая. | | |
| |
| 2.21, Бизон (?), 14:54, 18/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Этого не может быть по поределению. Если кто смотрел сырцы джава машины,
>то, видимо, видил, что там реализовано прелбразование байт кода в нативный
>код. При выполнении джава программы всегда это преобразование выполняется, хотя, только
>один раз для запрашиваемого метода. В С++ это уже сделано компилятором.
>Код уже нативный. Вот и получается, что у джавы хош-нехош, а
>есть издержки, от которых ни куда не уйти. При прочих равных
>условиях JAVA всегда будет проигрывать C++.
>Сам я ярый приверженей JAVA и терпеть не могу C++, но факт
>остается фактом. Конечно, если написать числодробилку, например, обращение разреженной матрицы 10000х10000
>то время выполнения программы на джаве и С++ будет примерно одинаковым.
>Нативный код джава строит неплохой. А вот с ГУИ у джавы
>более серьезные проблемы. Тут и мерить не кудая.
Для Java есть AOT компиляторы которые компилируют в нативный код. | | |
|
| 1.16, Аноним (1), 11:48, 18/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Dimon,
> Когда? Никогда!
Ну, неправда ваша. Как пример - джава сервлеты против CGI. | | |
| 1.18, screepah (??), 13:18, 18/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
CGI скрипты через интерпретатор ессесно будут тормознее, но скажу по-секрету, грамотно написанный perl или php скрипт работают также как и сервлеты, например на участках парсинга (прааальный регэксп на перле вообще супэр, главное не забывать про однократную компиляцию шаблонов и т.п.)
а интересно, много ли народу пишут CGI на плюсах? кроме биллинговых систем, я по-моему и ничего вспомнить не могу... ну не на яве же их писать в самом деле :) | | |
| |
| 2.20, Бизон (?), 14:51, 18/06/2004 [^] [^^] [^^^] [ответить]
| +/– | |
А я вам скажу по секрету - грамотно написанный сервлет и грамотно настроенный сервер - уделают CGI по самые помидоры.
На яве пишут много биллинговых систем - это уже обсуждалось. | | |
| |
| 3.22, user (??), 20:08, 18/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
>А я вам скажу по секрету - грамотно написанный сервлет и грамотно
>настроенный сервер - уделают CGI по самые помидоры.
>
>На яве пишут много биллинговых систем - это уже обсуждалось.
Ну естественно у cgi слишком много расходов на запуск.
А вот fastcgi или mod_perl разделают яву под орех.
| | |
|
| 2.25, Promka (?), 13:00, 20/06/2004 [^] [^^] [^^^] [ответить]
| +/– |
 >CGI скрипты через интерпретатор ессесно будут тормознее, но скажу по-секрету, грамотно написанный
>perl или php скрипт работают также как и сервлеты, например на
>участках парсинга (прааальный регэксп на перле вообще супэр, главное не забывать
>про однократную компиляцию шаблонов и т.п.)
>а интересно, много ли народу пишут CGI на плюсах? кроме биллинговых систем,
>я по-моему и ничего вспомнить не могу... ну не на яве
>же их писать в самом деле :)
я пишу на Сях (Не ++), довольно часто.
В основном, компоненты CMS (перекомпиляция данных из бд в статик, например).
| | |
|
| 1.26, dutchman (?), 16:41, 21/06/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Сам пишу на плюсах. Ткните меня носом пожалуйста в тесте methcall - ИМХО плюсовый код написан без ошибок ведущих к потере производительности. И все равно - на плюсах с оптимизацией:
real 0m16.384s
user 0m16.369s
sys 0m0.004s
на яве с серверной ВМ:
real 0m2.091s
user 0m1.490s
sys 0m0.034s
| | |
| |
| 2.27, Alex Povolotsky (?), 11:17, 05/11/2005 [^] [^^] [^^^] [ответить]
| +/– |
 Достаточно просто. Первый запуск программы - это подгрузка всяких библиотек. Серверная ВМ заранее их подгружает. Вообще, тесты всячески оптимизированы для того, чтобы показать, какая крутая эта жаба. | | |
|
| 1.28, Аноним (-), 19:46, 27/03/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Зацените:
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++. Но тесты не объективны. | | |
|
