> А ваш допиг на C++, изменяет порядок объектов, хотя на результат в данной задаче это не влияет, но это уже попахивает дисквалификацией ;-)

Ну... отпарирую так: можно применить более сложную в реализации, не меняющую порядок обьектов оптимизацию, перегрузив операторы new & delete.

> А куда же у нас делся virtual ? Кючики gcc и результат gcc -S слабо привести ?

Ничего больше не менял, чесслово. :) Ключики: -O3 -march=athlon-xp -ffast-math. Коли интересно, g++ -S: http://rafb.net/paste/results/2jZPb044.html. Честно говоря, сам удивлен результатами явы. :\

> Попробуйте своим способом ускорить OpenOffice ;-), у него как раз тормоза при запуске по этому поводу.

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

> отпарирую так: можно применить более сложную в реализации, не меняющую порядок обьектов оптимизацию, перегрузив операторы new & delete.

А что будет если потребуется удалить 90% обьектов, в произвольном порядке ?

Конечно, перегрузив операторы new & delete, можно реализовать специальный алгоритм allocator-а на этот случай, но не стоит забывать что процессор может быть и не один, и если вы хотите конкурировать с jvm allocator одним глобальным mutex вы не отделаетесь, а условие задачи (требования заказчика в реальной жизни) в процессе раелизации этого всего может и изменится.

Будем изобритать велосипед или признаем что для реальных задач jvm allocator эффективнее ?

Да не забудьте о времени на тестирование и отладку, даже ваш не очень сложный допинг не лишен ошибок:
const int count = 10000000;
int a = count / 3;
for (int i = 0; i < count; i+=3) {
a--;
printf("%d\n", a); /* ;-) */
> Ничего больше не менял, чесслово. :)
.L149:
.L137:
.L142:
leal 0(,%ebx,4), %edi
addl -40(%ebp), %edi
movl (%edi), %edx
movl (%edx), %ecx
movl %edx, (%esp)
call *(%ecx) # virtual call
faddl -104(%ebp)
incl %ebx
cmpl $9999999, %ebx
fstpl -104(%ebp)
jle .L149
Верю ;-)
bash-2.05b$ g++ a.s
bash-2.05b$ ./a.out
summa: 1600535735700.000000
init: 393, calc: 19978
bash-2.05b$ /opt/ibm-jdk-bin-1.4.2/bin/java -Xmx512m -Xms512m Test
summa: 1.6087864848E12
init: 798, calc: 17973
Но мой jdk все равно быстре ...
> Честно говоря, сам удивлен результатами явы. :\
Я скорее удивлен скоростью работы именно вашего jdk, обьясняю почему:
у вас
> $ uname -a
> Linux earth 2.6.7 #1 Mon Aug 9 16:17:07 MSD 2004 i686 AMD Athlon(tm) XP
> 1500+ AuthenticAMD GNU/Linux
у меня
bash-2.05b$ uname -a
Linux meteor 2.6.7-gentoo-r6 #11 Wed Aug 4 20:53:28 VLAST 2004 i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
в 32 разрядном режиме

отношение результатов C++ теста: 35589 / 20371 = 1.74704 (вполне правдоподобно)
отношение результатов Java теста: 73927 / 18771 = 3.93836 (AMD нужно было назвать мой процессор Athlon64 6000+ ???)

А может я эти цифры придумал ? Поищите в google другие benchmark-и почему то их результаты схожи с моими, а такой провал в скорости jdk похоже только у вас :?

Возможно у вас патч на ядре, для софтварной защиты от переполнения стека, который тормозит jdk.

> Вообще хотелось показать, что сравнивать яву и C++ на синтетических тестах довольно сложно, нужно учитывать массу факторов. Это если действительно сравнивать, а не миссионерством заниматься.

Я не говорил что претендую на многофакторное сравнение. В этом тесте специально сделал упор на то что используется в С++ и Java программах примерно одинаково (как показывает практика, в C++ очень редко применяют механизмы используемые в вашем допинге, т.к. они серьезно затрудняют разработку) и в большом колличестве.

Если бы я хотел сделать синтетических тест в котором Java порвала бы C++, я бы активно использовал garbage collector. Но на C++ тоже легко можно порвать Java, например масивом классов как было предложено выше.

Исходя из этого в реальных бизнес проектах (хотя бывают исключения) Java будет быстре как по скорости работы, так и по скорости разработки, я уже не говорю про отладку ;-)

>> отпарирую так: можно применить более сложную в реализации, не меняющую порядок обьектов оптимизацию, перегрузив операторы new & delete.
>А что будет если потребуется удалить 90% обьектов, в произвольном порядке ?
Ну будет список из count*0.9 указателей на память, которую можно занять.

> Конечно, перегрузив операторы new & delete, можно реализовать специальный алгоритм allocator-а на этот случай, но не стоит забывать что процессор может быть и не один, и если вы хотите конкурировать с jvm allocator одним глобальным mutex вы не отделаетесь, а условие задачи (требования заказчика в реальной жизни) в процессе раелизации этого всего может и изменится.

А вообще... ни на одном другом языке нельзя написать аллокатор, похожий на аллокатор jvm? :\ Чем же ограничены C++ программисты?

> Да не забудьте о времени на тестирование и отладку, даже ваш не очень сложный допинг не лишен ошибок: ...
Забавно, да... но это не относится к тому, кто быстрее. Как раз с тем, что на java быстрее и дешевле разрабатывать программки, никто не спорит.

> Возможно у вас патч на ядре, для софтварной защиты от переполнения стека, который тормозит jdk.

Никаких патчей, vanilla kernel. Единственное - glibc поддерживает nptl.

> А может я эти цифры придумал ? Поищите в google другие benchmark-и почему то их результаты схожи с моими, а такой провал в скорости jdk похоже только у вас :?

Попросил проверить приятеля... получилось примерно то же самое.
Цифры я не придумывал, может быть кто-нибудь еще их подтвердит?

> Ну будет список из count*0.9 указателей на память, которую можно занять.

Занять ее к сожелению можно будет далеко не всем и не стандартным способом.

> А вообще... ни на одном другом языке нельзя написать аллокатор, похожий на аллокатор jvm? :\ Чем же ограничены C++ программисты?

Тем что у них нет C++ VM ;-) т.е. аллокатор не может знать и использовать runtime информацию, а так же прозрачно "двигать" объекты в памяти.

Вообще, в теории, VM доступно на порядок больше оптимизаций чем обычному компилятору. Хотя jvm относительно не давно стала конкурировать с C/C++, у нее еше большой потенциал для развития.

> Попросил проверить приятеля... получилось примерно то же самое. Цифры я не придумывал, может быть кто-нибудь еще их подтвердит?

Может дело в памяти ? У меня 1 гиг, расход памяти 512 + jvm, может стоит уменьшить count и -Xm...

Почему Чайник — это не круто

1. им нельзя пылесосить
2. в чайнике нельзя варить креветок
3. Никаких сюрпризов и хитрых фич - только одна кнопка
4. Чайники попульрны и это не круто, то ли дело кипятильник!