LINUX.ORG.RU

Java тормозит? А вот и нет! :)


0

3

Попробовал сравнить программы, вычисляющие число пи, написанные на C и Java. Использовал Ряд Лейбница. Вот что получилось:

Java (JRE 1.6): 18 с

C (gcc 4.4.3 с -O2): 24 c

public class Main {
    public static void main(String[] args) {
        double pi = 0.0;
        int z = 1;

        for (int i = 1; i <= 2000000000; i++)
        {
            pi += (1.0 / ((i*2)-1)) * z;
            z *= -1;
        }

        System.out.println(pi*4);
    }
}
#include <stdio.h>

int main(void)
{
    double pi = 0.0;
    int z = 1, i;

    for (i = 1; i <= 2000000000; i++)
    {
        pi += (1.0 / ((i*2)-1)) * z;
        z *= -1;
    }

    printf("%.15f\n", pi*4);
}

PS. Я C программист, к яве отношения не имею :)

Я помню когда-то простой цикл с суммирование так тестировал. Круче всех пошутила MSVS, посчитав цикл на этапе компиляции)

vertexua ★★★★★
()
Ответ на: комментарий от anonymous

да по хорошему бы там надо писать i+=2 а вместо умножения на z разбить на два цикла с разными знаками, но на фоне затрат на деление это все мелочи.

Переполнение инта вряд ли сильно изменит ответ, на хвосте то знакопеременного ряда...

Тест забавный... может ява сама его запараллелила? ;-)

AIv ★★★★★
()
Ответ на: комментарий от arsi

i <= 2000000000
i*2
Я C программист

My bad, sorry :-) Увеличивал счетчик, а про int-то забыл, ага

gvinpin
() автор топика

в данном случае интересно было бы посмотреть на результат icc, как говорят на таких задачах он как раз и дает форы gcc

aho
()
Ответ на: комментарий от gvinpin

А теперь -client -Xbatch, плз.

И еще нюанс. Как ты меряешь? Нужно таймером мерять промежуток выполенияк кода, иначе включаешь во время запуск JVM, а это дофига.

vertexua ★★★★★
()
Ответ на: Java тормозит? от nanoo_linux

Java тормозит?

Да. Запусти эклипсу и убедись.

Эклипс как раз не особо и тормозит. Он же не на Swing. Вот нетбинс, тот да...

gvinpin
() автор топика

> Java (JRE 1.6): 18 с
> C (gcc 4.4.3 с -O2): 24 c

$ time ./test
3.141592658505181

real    0m16.904s
user    0m16.740s
sys     0m0.035s
$ time java Main
3.141592658505181

real    0m17.566s
user    0m18.104s
sys     0m7.667s

одна из черепашек врёт ;)

arsi ★★★★★
()
Ответ на: комментарий от vertexua

> А теперь -client -Xbatch, плз.

Да то же самое. Чуть меньше 18с

И еще нюанс. Как ты меряешь? Нужно таймером мерять промежуток выполенияк кода, иначе включаешь во время запуск JVM, а это дофига.


Ручным секундомером :) Может и смешно, но, увидев такую разницу в первоначальном варианте, решил, что и так нормально. Сейчас попробую замерить по-хорошему.

gvinpin
() автор топика
Ответ на: комментарий от gvinpin

<fatter-than-fat-itself>

Ты что шутишь, нормально? Java должна работать в два раза быстрее!!!

</fatter-than-fat-itself>

vertexua ★★★★★
()
Ответ на: комментарий от arsi

одна из черепашек врёт ;)

Хм, странно...

$ time ./a.out 
3.141592658505181

real	0m25.812s
user	0m25.580s
sys	0m0.220s

$ time java Main
3.141592658505181

real	0m17.555s
user	0m20.070s
sys	0m10.890s

$ time java -server -Xbatch Main
3.141592658505181

real	0m17.576s
user	0m19.950s
sys	0m11.080s

$ time java -client -Xbatch Main
3.141592658505181

real	0m17.522s
user	0m19.850s
sys	0m11.110s

gvinpin
() автор топика
Ответ на: комментарий от gvinpin
$ /opt/sunstudio12.1/bin/c89 -O test.c -o test_sun
bash-4.1$ time test_sun
3.141592658505181

real    0m16.391s
user    0m16.196s
sys     0m0.009s
$ /opt/intel/Compiler/11.1/069/bin/intel64/icc -O2 test.c -o test_icc
$ time test_icc
3.141592658505181

real    0m16.862s
user    0m16.738s
sys     0m0.017s
$ time java -server -Xbatch Main
3.141592658505181

real    0m18.096s
user    0m18.752s
sys     0m8.033s
$ _
arsi ★★★★★
()
Ответ на: комментарий от vertexua

> Нужно таймером мерять промежуток выполенияк кода

По 3 попытки на каждый вариант. В миллисекундах:

java Main

17395, 17396, 17402

java -server -Xbatch Main

17508, 17408, 17416

java -client -Xbatch Main
17466, 17403, 17408

gvinpin
() автор топика

Ну толсто же, ну. Там баян, а тут пила. Как можно сравнивать то?

darkshvein ☆☆
()

А включен ли в GCC Graphite Loop Optimizaions?
А если включен, поменяется ли результат, если декларацию i внести внутрь цикла, так же, как в Java (разрешено в C99)?

proud_anon ★★★★★
()
Ответ на: комментарий от gvinpin

Оба :)

Но это моё личное, субъективное, мнение. Пруфов нет. И не будет.

nanoo_linux
()
Ответ на: комментарий от proud_anon

А включен ли в GCC Graphite Loop Optimizaions? А если включен, поменяется ли результат, если декларацию i внести внутрь цикла, так же, как в Java (разрешено в C99)?

Попробовал включить. Всё едино:

daniil@book:~/tmp$ g++ -O2 -ftree-loop-linear pi.c
daniil@book:~/tmp$ time ./a.out 
3.141592658505181

real	0m25.664s
user	0m25.630s
sys	0m0.030s
daniil@book:~/tmp$ g++ -O2 pi.c
daniil@book:~/tmp$ time ./a.out 
3.141592658505181

real	0m25.664s
user	0m25.650s
sys	0m0.010s
gvinpin
() автор топика

говно ваша джава! аминь

anonymous
()
Ответ на: комментарий от anonymous

> ты запихнул в инт 2000000000? ауч.

2^31-1 = 2147483647

Сюрприз?

gvinpin
() автор топика

У меня gcc-4.6. Если компилировать с -O3 - то примерно также. Но если сделать -Ofast - результат одинаков в пределах погрешности.

sergej ★★★★★
()

java:

fads@extensa /tmp $ time java Main -server -batch
3.141592658505181

real	0m19.231s
user	0m21.970s
sys	0m12.140s

c:

fads@extensa /tmp $ gcc -O3 -funroll-loops -ftree-loop-linear -fomit-frame-pointer pi.c -o cpif
fads@extensa /tmp $ time ./cpif
3.141592658505181

real	0m18.381s
user	0m18.360s
sys	0m0.000s

fads ★★
()
Ответ на: комментарий от AIv

да по хорошему бы там надо писать i+=2 а вместо умножения на z разбить на два цикла с разными знаками, ...

... и получить накопление ошибок — каждая сумма будет больше пи/4 примерно в ln 1 000 000 000 ~ 20 раз

double pi_4=1;
for(int i=1; i< ... ; i++) {
  pi_4 -= 1.0 / (4*i+1) / (4*i-1) ;
}

З.Ы. тут можно и i+=4, но компилятор должен до этого догадаться, не?

www_linux_org_ru ★★★★★
()

тред горе оптимизаторов

double pi = 0;
for(double i = 2 - 1; i <= 4000000000 - 1; i += 4.)
  pi += 1.0 / i;
for(double i = 2 - 1 + 2; i <= 4000000000 - 1; i += 4.)
  pi -= 1.0 / i;

_log(pi*4)
bga_ ★★★★
()
Ответ на: комментарий от bga_
fads@extensa /tmp $ gcc pi.c -o cpistd -std=c99
fads@extensa /tmp $ time ./cpistd 
3.141592653082270

real	0m18.474s
user	0m18.450s
sys	0m0.010s

кстати говоря, все посчитанные числа в этом треде не соответствуют числу пи:
pi = 3.141592653589793238462643.. proof

fads ★★
()
Ответ на: комментарий от www_linux_org_ru

компилятор явы, если не указать иное, ничего оптимизировать не будет

note173 ★★★★★
()

pgo

И никто не осилил собрать с PGO.

uzbl
()
Ответ на: комментарий от bga_

> кстати говоря, все посчитанные числа в этом треде не соответствуют числу пи

переполнение инта, че

а вообще должны соответствовать с точностью до 1/ 4 000 000 000

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от bga_

насчет кастов, наверно, соглашусь

а вот насчет точности  — ты тоже теряешь один десятичный знак (хотя это и не будет видно при i<10^15)

www_linux_org_ru ★★★★★
()

А как насчет распараллелить для CUDA и посчитать на среднебюджетной видеокарте (тысячи за 3-4 деревянных)?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от note173

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от note173

Ну как вам доказать, что ява тормозит? ИМХО вы не принимаете, а объективных тестов не существует (т.к. они сильно зависят от платформы, версии ява-глюконавта и фазы Луны).

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Не нужно ничего доказывать.
Ява имеет известный оверхед на некоторых операциях, и это очевидно. Применяется она традиционно в таких задачах, для которых этот оверхед совсем не критичен.
Но это не значит, что любая программа, написанная на яве будет тормозить на порядок больше такой же на с++.
Кроме того, jit сильно ускоряет тяжелые для интерпретации операции (вызов через интерфейс, чтение/запись поля, например).
Реальные приложения, имеющие больше логики, чем вычислений, программа тормозит из-за программиста, а не из-за сборщика мусора.

note173 ★★★★★
()

С zsh выглядит слишком толсто.

@madoka~>time java -client -Xbatch Main
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on
3.141592658505181
java -client -Xbatch Main  11.71s user 5.35s system 158% cpu 10.731 total
@madoka~>time ./a.out                  
3.141592658505181
./a.out  19.07s user 0.00s system 99% cpu 19.089 total

2 ядра. java юзает оба.

x3al ★★★★★
()
Ответ на: комментарий от note173

программа тормозит из-за программиста, а не из-за сборщика мусора.

Да ладно вам, говорите уж прямо: ява, как и дерьмомоно, была придумана для написания кроссплатформенных легких игрулек, или же элементарных граф-морд. И ни для чего другого не годится.

Eddy_Em ☆☆☆☆☆
()
Ответ на: С zsh выглядит слишком толсто. от x3al

Хм.

@madoka~>\time ./a.out  #оно же с -O3 -ffast-math
3.141592658505181
14.06user 0.00system 0:14.06elapsed 99%CPU (0avgtext+0avgdata 1856maxresident)k
0inputs+0outputs (0major+140minor)pagefaults 0swaps
java — тормоз. Она на двух ядрах работает 11 секунд, программа на C — 14 секунд на одном ядре.

x3al ★★★★★
()
Ответ на: комментарий от Eddy_Em
fads@extensa ~/Dev/cuda/mipt/pi $ time ./nvpi 
Kernel time: 0.010000 (s)
PI = 3.141599416733

real	0m0.099s
user	0m0.000s
sys	0m0.060s

nvidia g105m (8 cores), интегрирование четверти окружности методом трапеций

fads ★★
()
Ответ на: комментарий от Eddy_Em

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

note173 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.