Техническая статья Sun «Делаем Java быстрее чем С, используя LRWP»

> А я жду технической статьи Сана на тему "хотя аппаратный вечный двигатель невозможен, над программным вечным двигателем, написанным на яве, уже ведутся работы"

В яблочко. Вот, один раз наткнулся на занятные плакатики:

http://elementy.ru/posters/perpetuum/light

Думаю можно дополнить ещё одной иллюстрацией, с недалеким жабакодером.

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

>Приличную скорость на интерпретаторе байткода можно получить только вызывая заточенные под конкретный камень сишные библиотеки. Там где ява далеко отходит от собственных примитивов производительность от паттернов не зависит.

Почитай вот это http://www.3dnews.ru/mobile/msi_wind_u100/print про новые процы Atom. Скоро ва любом смартфоне/КПК с 512Мб памяти можно будет гонять старую добрую DOSовскую Civilization. И какие ты думаешь приложения захватят 90% этих x86-совместимых устройств? На .NET? Так, вторая попытка, подумай еще. На Java 7.0.

>Ещё раз. У меня не сервер. И если я когда либо говорил, что Java тормозит, то имел ввиду десктопные приложения.

>CtrlAltBs (*) (24.06.2008 21:16:40)

Еще раз, что имеем в виду под десктопными приложениями? Приложения запущенные на десктопе? Я тебя удивлю сильно, но компьютер я выключаю только на работе. Дома у меня неделями не закрываясь крутятся Firefox, Azureus и IntelliJ IDEA с NetBeans. Так вот пусть лучше будут написаны на Java и жрут по 128Мб и летают, чем написаны на C++ и будут жрать 256Мб и тормозить, как FF 3.0 из-под которого я это пишу. Azurues, NetBeans, IntellJ IDEA написаны на жаве и жрут меньше памяти, чем FF написанный на C++. Это как прикажешь объяснить? И уж запускается Azureus с 250торрентами быстрее, чем FF с 10 открытыми вкладками

Насколько я понял тут сравнивали Си и Java а не С++ и Java
( примера для С++ вроде не было )

так что если бы FF написали бы на Си то он бы наверное летал ;)

>Я тебя удивлю сильно, но компьютер я выключаю только на работе. Дома у меня неделями не закрываясь крутятся Firefox, Azureus и IntelliJ IDEA с NetBeans. Так вот пусть лучше будут написаны на Java и жрут по 128Мб и летают, чем написаны на C++ и будут жрать 256Мб и тормозить, как FF 3.0 из-под которого я это пишу. Azurues, NetBeans, IntellJ IDEA написаны на жаве и жрут меньше памяти, чем FF написанный на C++. Это как прикажешь объяснить? И уж запускается Azureus с 250торрентами быстрее, чем FF с 10 открытыми вкладками

именно так. с большими плюсовыми функциональными программами так.

> Так вот пусть лучше будут написаны на Java и жрут по 128Мб и летают, чем написаны на C++ и будут жрать 256Мб и тормозить, как FF 3.0 из-под которого я это пишу.

С сегодняшнего дня пользуйтесь:

http://lobobrowser.org/

Иначе буду считать вас предателем!

Я приветствую ваш энтузиазм. Однако как человек работающий как с Java с 1999 года, и соответственно не имеющий предубеждения перед этой технологией, хочу вас спросить, какие приложения, написанные на Java, вы используете в повседневной жизни? Какие собираетесь?
Уточню. Не для разработки приложений, а именно в повседневной работе с компьютером.
Я - никаких. но использую несколько написаныхх для mono и .net.

Не думаю, что Java займёт долю рынка настольный приложений больше одного процента в ближайшие 5 лет.

К сожелию Sun просрал аплеты и проигнорировал персональные компьютеры. Теперь поздно. MHO.

FF интерпретатор Javascript. Весь UI скриптован на JS. Соответственно на медленных компьютерах от запускается медленне браузеров у которых UI сделан на C/C++ но страницы рисуются движком FF.
Насколько мне известно планируется новая VM в слудующем поколении FF с JIT компиляцией.

> void main(void){ for(;;){ delay(1); } }

и что же он двигает? скорее вечный тормоз

> И уж запускается Azureus с 250торрентами быстрее, чем FF с 10 открытыми вкладками

а у меня хммс грузится быстрее чем конвертируется видео ffmpeg'ом. некорректное сравнение

>какие приложения, написанные на Java, вы используете в повседневной жизни? Какие собираетесь? Уточню. Не для разработки приложений, а именно в повседневной работе с компьютером.

Azureus, JEdit. И хотел бы больше программ на Java. Например аудиоплеер.

>недавно на ЛОРе я показывал, что банальный пузырёк на Си выполняется в 2 раза быстрее, чем на яве. (а может и более - у меня шина памяти медленная - ддр2 200/400)

>опять дураков понабилось.

Давай на бис тесты в студию, я первый раз не застал. Только у меня не линукс, а винда. Зато DDR2 533/1066.

>оптимизирует атрибуты доступа (final, static где необходимо), выбрасывает не используемые методы, оптимизирует циклы и арифметику,

Ну вот это по умолчанию и делает сама JRE. Большая в смысле, JRE SE, а не на мобилках

>которая в свою очередь снижает колстек, размеры ссылок класпаса (которые хранятся в байт коде в виде строк),

А вот это увы, из-за рефлекшена она сама делать не будет

>К сожелию Sun просрал аплеты и проигнорировал персональные компьютеры. Теперь поздно. MHO.

К сожалению персональные компьютеры по количеству уступают на порядки всяким нетбукам, UMPC, PDA, Mobile PC, Notebooks, Smartphones etc. А в этих нишах с жавой все в порядке и будет в еще бОльшем порядке дальше

резюмирую: Java изначально заточена была под Enterprise appz и соотв их-же масштабируемые серваки как среду для оного. прочее "от лучкавого" и стремления нажиться на [ничем не обоснованном]энтузиасте энтузиастов. как популярная(все еще в PR-е как ни странно) нефактологичная сказка про тн "кросплатформенность" Java.

>Доколе? Доколе я вас спрашиваю?! Доколе Linux будет на убогом и медленном Си? Ведь Си - создан ещё в семидесятых годах! Старье! Убогое старье! Неужели вы не думаете, что за сорок лет не придумали ничего нового, более быстрого? А вы подумайте! Для приближения вендакопеца предлагаю переписать Linux на Java! И тогда система будет обгонять такты процессора!!

Да. Действительно. Недолго, знаешь ли, линксу осталось. Почитай http://code.google.com/android/what-is-android.html Скоро Google заменит Linux в этих девайсах на свое оптимизированное ядро, возможно микроядерной архитектуры, а количества написанных жаба-приложений под Android хватит и на версию Android 2.0, и Android 3.0 и надолго короче. А Linux останется для баловства на курсовых второкурсников, чтобы на его примере объяснять устройство простейшей операционной системы, примерно как нам на 2-м курсе объясняли устройство простейшей атомной бомбы

> Скоро Google заменит Linux в этих девайсах на свое оптимизированное ядро, возможно микроядерной архитектуры

Афигеть, инсайдеры Гугля на ЛОРе O_o

> нам на 2-м курсе объясняли устройство простейшей атомной бомбы

"В общем, с какого курса вас выгнали за неуспеваемость?" почти (c)

> Так подойдёт?

> user@mac:~/1$ hexdump -C a.out

otool -tv дизасм выводит

C: meening

~/test/javac$ gcc cps.c -o cps
~/test/javac$ ./cps
1000000
~/test/javac$ cat cps.c
#include <stdio.h>
#include <time.h>

int main()
{
printf("%ld\n", CLOCKS_PER_SEC);
return 0;
}

~/test/javac$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.5.3
BuildVersion: 9D34

>JEdit. И хотел бы больше программ на Java. Например аудиоплеер.
Да!? И что-же вы в JEdit редактируте?

А что-же не пользуетесь аудиоплеером?

Почему хотите больше программ именно на Java?

>нетбукам, UMPC, PDA, Mobile PC, Notebooks
Расскажите мне, какми программами на Java вы пользуетесь не для разработки на этих устройствах. Уточню. Не слышали, что кто-то пользуется а именно вы лично пользуетесь.

>И тогда проблемы с Linux с дровами больше не будет.

Будут проблемы с производительностью, когда для достижения правильного byteorder в java будет вместо машинно-зависимого 64-битного слова будет читаться восемь раз по байту и делаться восемь операций сдвига. Это не говоря уже о том, что DMA и низкоуровневые порты есть не во всех системах.

Короче, КГ/АМ.

>>JEdit. И хотел бы больше программ на Java. Например аудиоплеер.

>Да!? И что-же вы в JEdit редактируте?

тупой вопрос

>А что-же не пользуетесь аудиоплеером?

foobar2000 под wine

>Почему хотите больше программ именно на Java?

потому что например аудиоплеера под linux нормального ждать уже надоело. может кто из windows программистов напишет, ну например на java.

> $ sw_vers 
> ProductName:	Mac OS X 
> ProductVersion:	10.5.3 
> BuildVersion:	9D34 
> 
> $ ./cps 
> 1000000

У меня тоже самое на Маке.

Java, написанная на Си, действительно тормозит быстрее оного :-)

2kmike ** (*) (24.06.2008 12:12:08):

> По последним данным Netcraft (http://survey.netcraft.com/Reports
> /200806/ ), этого Xitami на горизонте вообще нет. Не преодолел
> планку в 5000 сайтов, бедняга.

Ой-ли? А четвёртое место, позвольте спросить? Может быть Unknown
это оно и есть.

>Теперь я знаю, почему Java так популярна у корпоративщиков. Это ведь просто рай для откатников -- пилителей бюджета: и мега-кластер подавай, вместо пары простеньких сервачков; и на рабочие места несколько компов вместо одного (различным компонентам ПО на стороне клиента разные версии JRE подавай -- с другой они глючат безбожно); и много других хитростей-лазеек для распила бюджета.

Хороший ответ :-)

Если бы после этого ява позволяла распилить еще бабла с помощью программиста, который бы провел оптимизацю JVM под специфику программ заказчика, и таким образом уменьшил вдвое-втрое потребность в железе, ява была бы идеальна. Однако сан не написал JVM настолько модульно, чтобы ее можно было обезжиривать (причем лучше всего находу) :-)

>Ой-ли? А четвёртое место, позвольте спросить? Может быть Unknown это оно и есть.

Во время НАПИСАНИЯ статьи кситами был на более чем 80-м. Пройди по ссылке, Ъ ты наш :-)

> Java, написанная на Си, действительно тормозит быстрее оного :-)

И несправедливо, что только ява оказалась быстрее С !!!

Я советую всем провести соотвествующие тесты, и написать ряд технический статей:

PHP быстрее чем С с использованием протоколов ABRAKADABRA и KRIVYE.RUKI

Python быстрее чем С с использованием протоколов...

... ну вы поняли?

Итак! Продолжим нашу занимательную пенисометрию!

Вынесем функцию суммирования в отдельную .so-шку. В Java-варианте
вынесем это в отдельный класс, да еще и вызывать его будет через
интерфейс. А чтобы совсем усложнить JVM жизнь, мы его грузить будем
по имени. А имя передавать параметром в main.

wfrag@fragentoo ~/1/2 $ cat dosum.c 
int dosum(int a, int b) {
    return a + b;
}
wfrag@fragentoo ~/1/2 $ cat test4.c 
#include <stdio.h>
#include <time.h>

int dosum(int a, int b);

int main(int argc, char** argv) {
    int count1 = atoi(argv[1]);
    int count2 = atoi(argv[2]);
    long c = clock();
    int l = 0, i, j;
    for( j = 0; j < count1; ++j ) {
        for( i = 0; i < count2; ++i ) {
            l = dosum(l, i);
        }
    }
    long end = clock(); 
    printf( "l = %d\n", l );
    printf("%f\n", (float)(end - c) / (float)CLOCKS_PER_SEC);
    return 0;
}
wfrag@fragentoo ~/1/2 $ cat DoSum.java 
public interface DoSum {
    int dosum(int a, int b);
}
wfrag@fragentoo ~/1/2 $ cat DoSumImpl.java 
public class DoSumImpl implements DoSum {
    public int dosum(int a, int b) {
        return a + b;
    }
}
wfrag@fragentoo ~/1/2 $ cat Test4.java 
import java.lang.management.ManagementFactory;
import java.lang.management.ThreadMXBean;


public class Test4 {
    public static void main(String[] args) throws Exception {
        int count1 = Integer.parseInt(args[1]);
        int count2 = Integer.parseInt(args[2]);
        String clazz = args[0];
        DoSum d = (DoSum) Class.forName(clazz).newInstance();
        test(d, count1+1, count2+1);
        test(d, count1+2, count2+2);
        System.err.println("Real results");
        test(d, count1, count2);
        test(d, count1, count2);
 
    }

    public static void test(DoSum d, int count1, int count2) throws Exception {
        ThreadMXBean mx = ManagementFactory.getThreadMXBean();
        long c = mx.getCurrentThreadCpuTime();
        int l = 0, i, j;
        for( j = 0; j < count1; ++j ) {
            for( i = 0; i < count2; ++i ) {
                l = d.dosum(l, i);
            }
        }
        long end = mx.getCurrentThreadCpuTime(); 
        System.err.println( "l = " + l);
        System.err.println((float)(end - c) / 1000000000);
    }
}

wfrag@fragentoo ~/1/2 $ gcc -O3 -funroll-loops -finline-functions -shared dosum.c -o libdosum.so
wfrag@fragentoo ~/1/2 $ gcc -O3 -funroll-loops -finline-functions -ldosum -L. test4.c 
wfrag@fragentoo ~/1/2 $ javac DoSum.java DoSumImpl.java Test4.java 
wfrag@fragentoo ~/1/2 $ LD_LIBRARY_PATH=. ./a.out 10 1000000000
l = 451808768
36.630000
wfrag@fragentoo ~/1/2 $ /opt/sun-jdk-1.6.0.06/bin/java -cp . -Xss16m -XX:CompileThreshold=10 -server  Test4 DoSumImpl 10 1000000000
l = 1618564864
27.84
l = 490353676
30.19
Real results
l = 451808768
5.64
l = 451808768
5.63
wfrag@fragentoo ~/1/2 $ 


Ну, что еще подкрутить у gcc? Жду ответного теста от LLVM, AFAIK, он
тоже такой финт ушами делать умеет.

> Ну, что еще подкрутить у gcc? Жду ответного теста от LLVM, AFAIK, он тоже такой финт ушами делать умеет.

Ты уже раз обкакался. И если тебе сейчас опять ткнут носом (что будет несомненно), то придумаешь новый искусственный тест.

>>>JEdit. И хотел бы больше программ на Java. Например аудиоплеер.
>>Да!? И что-же вы в JEdit редактируте?
>тупой вопрос
Что, так, ничего и не редактируете? А с какой целью его тогда используете в повседневной, не связанной с програмированием, рутине?

>>А что-же не пользуетесь аудиоплеером?
>foobar2000 под wine
ок. извиняюсь. недостаточно развёрнуто выразился.
А что-же не пользуетесь аудиоплеером НАПИСАННЫМ НА JAVA?

>>Почему хотите больше программ именно на Java?
>потому что например аудиоплеера под linux нормального ждать уже надоело. может кто из windows программистов напишет, ну например на java.
А почему не на питоне или .Net? Вы видите каке-то специфические преимущества у desktop application на java?

>Ты уже раз обкакался.

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

Для Жавы я крутил опции лишь чтобы уменьшить время "прогрева", реально все эти оптимизации сработают и так.

>И если тебе сейчас опять ткнут носом (что будет несомненно), то придумаешь новый искусственный тест.

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

Последний искусственный тест, между прочим, показывает, чего стоят всякие раскрученные циклы в приложении, котороые делает много вызовов в .so-шки. Возьми тот же GTK+, например -- куча функций.

>> А что-же не пользуетесь аудиоплеером?

> foobar2000 под wine

> аудиоплеера под linux нормального ждать уже надоело. может кто из windows программистов напишет, ну например на java.

А сам foobar2000 - он на Яве? :D

А почему Вы тестируете С с динамически подгружаемой библиотекой а жабасорцы статически скомпилили? Самому не смешно? Теперь сделайте с .a место .so.

>А почему Вы тестируете С с динамически подгружаемой библиотекой а жабасорцы статически скомпилили? Самому не смешно? Теперь сделайте с .a место .so.

LOL. Где тут статическая компиляция в Java? Я могу DoSumImpl.java скомпилировать вообще на другой машине и подложить его моему приложению. Могу вообще через URLClassLoader загрузить его с сервера в момент выполнения. Разницы не будет (ща проверю).

В Java классы _всегда_ подгружаются динамически :)

А расшифровка теста очень простая. Hotspot осознал, что на некоторый момент есть только одна реализация интерфейса DoSum и совершенно справедливо заинлайнил вызов _виртуального_ метода. Но как только мы загрузим другую имплементацию, скорость естественно опять упадет -- хотспот перекомпилирует метод, ибо старая оптимизация уже будет не валидна. Но главное то, что эти оптимизации происходят совершенно прозрачно и не влияют на семантику.

> В Java классы _всегда_ подгружаются динамически :)

А потом происходит процесс, больше всего похожий на глобальную link-time оптимизацию статически скомпилированной "родной" программы.

P.S. Плюс я специально сделал так, что класс грузится по имени, которое передается параметром. Ты можешь написать DoSumImpl2.java:

public class DoSumImpl2 implements DoSum { public int dosum(int a, int b) { return a - b; } }

И передать его параметром. Численный результат, естественно, будет иной. Где тут "статическая компиляция"? Конкретная функция определяется параметром теста :)

>А потом происходит процесс, больше всего похожий на глобальную link-time оптимизацию статически скомпилированной "родной" программы.

Именно. Поэтому я сразу про LLVM оговорился, насколько я знаю, он как раз такое делать умеет.

>foobar2000 под wine

Что такого есть в фубаре? Что-то не понял я эту программу. Скрипт deaudiophilize.sh для превращения cue+ape в пачку ogg 256kb с тегами написал. Больше проблем с аудиофилией не имею.

>Разницы не будет (ща проверю). 

Сделал загрузку класса по HTTP. Разницы в скорости, как и ожидалось, -- нет.

Код: http://paste.org.ru/?vr0u8d (Test4.java) и http://paste.org.ru/?0pk8ps (DoSum.java). Конкретной имплементации сумматора нет -- он с сервера скачается.

Результат: 

wfrag@fragentoo ~/1/2/3 $ javac Test4.java DoSum.java
wfrag@fragentoo ~/1/2/3 $ /opt/sun-jdk-1.6.0.06/bin/java -cp . -Xss16m -XX:CompileThreshold=10 -server  Test4 DoSumImpl 10 1000000000
<хитро вырезано>
l = 1618564864
28.0
l = 490353676
30.25
Real results
l = 451808768
5.63
l = 451808768
5.64

> Жду ответного теста от LLVM, AFAIK, он
> тоже такой финт ушами делать умеет.

Хм, для этого надо знать как делать такой финт. В лоб - не работает, а даже сливает:

$ gcc -O3 -funroll-loops -finline-functions -shared dosum.c -o libdosum.dll

$ gcc -O3 -funroll-loops -finline-functions -ldosum -L. test4.c

$ javac DoSum.java DoSumImpl.java Test4.java

$ LD_LIBRARY_PATH=. ./a 10 1000000000
l = 451808768
55.546000

$ llvm-gcc -O3 -funroll-loops -finline-functions -shared dosum.c -o libdosum.dll

$ llvm-gcc -O3 -funroll-loops -finline-functions -ldosum -L. test4.c

$ LD_LIBRARY_PATH=. ./a 10 1000000000
l = 451808768
68.171000

Т.е. надо через байт-код. Позже проверю.
Для справки - java:

$ java -cp . -Xss16m -XX:CompileThreshold=10 -server  Test4 DoSumImpl 10 1000000000
l = 1618564864
22.359375
l = 490353676
38.359375
Real results
l = 451808768
3.609375
l = 451808768
3.609375

> Поэтому я сразу про LLVM оговорился, насколько я знаю, он как раз такое делать умеет.

Хм, там опять "засада":

Без оптимизации:

$ llvm-gcc -O3 -funroll-loops -finline-functions -emit-llvm -c dosum.c -o libdosum.bc

$ llvm-gcc -O3 -funroll-loops -finline-functions -emit-llvm -c test4.c -o test4.bc

$ llvm-link -o test4full.bc libdosum.bc test4.bc

$ llc test4full.bc

$ llvm-gcc test4full.s -o test4full.exe

$ ./test4full.exe 10 1000000000
l = 451808768
47.437000

Чуть лучше, но...

Теперь оптимизируем:

$ opt -std-compile-opts -o test4opt.bc test4full.bc

$ llc test4opt.bc

$ llvm-gcc test4opt.s -o test4opt.exe

$ ./test4opt.exe 10 1000000000
l = 451808768
0.000000

Опять 25! =D

>Опять 25! =D

Ну чо я могу сказать, молодцы, зачет. Наверное, он просто вывел формулу.

>А почему Вы тестируете С с динамически подгружаемой библиотекой а жабасорцы статически скомпилили?

Это надо в квотес.

Что такое, когда нормально протестировали и жаба снова всосала сказать больше умного нечего?

>Что такое, когда нормально протестировали и жаба снова всосала сказать больше умного нечего?

Эммм. Нормально протестировали -- это на LLVM-то? Ты сходи хоть, почитай, что это. По-моему, это показательно, что одна Virtual Machive проиграла другой, пусть и более лёгкой :)

Если использовать LLVM только для compile-time оптимизаций + генерировать обычную .so-шку, никакого чуда не будет. Оно сгенерит такой же код, что и gcc, который будет вызывать функцию по указателю. У него нет другого выбора, заинлайнить нельзя, ибо .so-шку могут подменить.

Чудо будет, если .so-шки на пару с ld-linux выкинут нахер, заменив их LLVM-ными эквивалентами. С егойным байт-кодом и прочей метаифнормацией, которая и будет использоваться для вот таких хитрых глобальных оптимизаций в момент запуска :)

Дадада. Еще раз: скомпиль Цшный код статически и успокойся.

>С егойным байт-кодом и прочей метаифнормацией, которая и будет использоваться для вот таких хитрых глобальных оптимизаций в момент запуска :)

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

В принципе, идея для исследовательского дистрибутива. Впрочем, это немного уже оффтопик.

>Дадада. Еще раз: скомпиль Цшный код статически и успокойся.

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

У тебя много софта слинковано статически, скажем, с GTK/Qt?

Причем Java код-то гораздо более динамический получился -- последний вариант вообще с сервера код во время выполнения скачивает :)

> в том-то смысл теста и был. Динамический вызов.

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

Тоесть предоставить пример кода где Ваша жаба выигрывает у Ц по скорости Вы не можете и остается выкручиватся такими способами?