> Именно на С++ это и пишут

А на Java -- переписывают...

eXOR (17.06.2004 14:11:16):

> Можно списочек? :-).

Ну, скока вспомню:

True64, IRIX, AIX, HP-UX, Солярка, все известные мне системы на Итаниумах и Оптеронах.

Больше в голову не приходит. Возможно, что-нибудь забыл.

Кому интересно, лет 10 назад была на эту тему бурная дискуссия, результатом которой явился сий документ:

http://www.opengroup.org/public/tech/aspen/lp64_wp.htm

2dOBRiy:


[nelapsi@nelapsi C]$ cat test.c
#include <stdio.h>
int main(){
        short i;
        printf("q = %d\n",sizeof(int));
//      for(i = 0 ; i< 100000; i++)
//              printf("i = %d\n", i);
        return 0;
}
[nelapsi@nelapsi C]$ gcc test.c
[nelapsi@nelapsi C]$ ./a.out
q = 4
[nelapsi@nelapsi C]$

> есть такое правило sizeof(int) == sizeof(void *)

Нет такого правила. Есть общеизвестные грабли.

и вообще int должен быть 4 байта и никак иначе..- остальное от дукавого... (или старье)

eXOR (17.06.2004 14:16:16):

> есть такое правило ...

Да, такое правило БЫЛО до прихода Юнихов на 64-битное железо. Теперь такого правила нет -- кстати, для Це факт весьма печальный, ибо разница поинтеров более не лезет в интеджер.

>Кому интересно, лет 10 назад была на эту тему бурная дискуссия,
>результатом которой явился сий документ:
Пасибки. Почитаем :-)

> Байт код не может выполняться быстрее чем машкод.

JIT

Очень приличная, как по мне, статья на эту тему.
Стоит прочитать и принять к сведению
http://www.osp.ru/os/2000/12/045_print.htm

Ога было такое ;-). Так-таки sizeof(int) чему получился у нас равен? :-)

> А какие РЕАЛЬНЫЕ идеи есть по поводу этого теста ? Байт код не может выполняться быстрее чем машкод.

Еще как может. Не забывайте, что там нынче не интерпретаторы, а JIT-компиляторы - то есть выполняется как раз машкод. Причем, поскольку компиляция байткода в нативный происходит на машине юзера, можно включить некоторые machine-dependent оптимизации (скажем аналог -march=i686 или даже повыше в GCC). Больше того, JIT может динамически профилировать программу при ее выполнении, и перекомпилировать отдельные ее части на лету с очень специфическими оптимизациями. При таком раскладе, байткод очень даже может обогнать машкод... но это если мы будем в байткод компилить программы на скажем C =) D жабе на это дело накладываются затраты на GC, выделение памяти (т.к. всякая мелочь живет не на стеке, как надо бы, а в куче), проверка границ массивов etc etc. Так что сделать какие-либо выводы на основе чисто теоретических построений тут трудно - нужны тесты.

> Так-таки sizeof(int) чему получился у нас равен? :-)

А в жабе он всегда равен четырем, хоть и на 8-битной платформе =) Так что нам пофиг =)

Вы, господа, не в куриваете что с 1.2 появился JIT, а в 1.4 уже нет classic и потому проспали что в java байткод уже давно не интерпретируеться, а компилируеться в натив Just In Time компилером. И если бы не многие грабли в спеке VM пирожки бы пеклись еще быстрее... Но по спеке не положено. И еще перед тем как приводить результаты надо кое что прочитать про JITы. Насколько я вижу шансов им не дали. Вот если бы для server jit код испольнился хотя бы 8000раз до замера пирожки выпеклись бы еще быстрее. А с тригонометрией да - в Sun 1.4 там какое-то прогонялово.

про тригонометрию

> но даже там на графиках видно, что тригонометрия /да и не только - всё что связано с фпу/ нуууу оооочень тормозииит...

Если не пользовать специальных ( сильно платформозависимых ) библиотек и/или компиляторов, то оно и на C++ тормозит (если, конечно, не извращаться с inline asm'-ом)

>А в жабе он всегда равен четырем, хоть и на 8-битной платформе =) Так
>что нам пофиг =)
А у вас вообще указателей нету, так что вы в пролете :-)....

> А у вас вообще указателей нету, так что вы в пролете :-)

А у вас зато нету нормальной сериализации и RTTI =)

>Вот если бы для server jit код испольнился хотя бы 8000раз до замера
>пирожки выпеклись бы еще быстрее.
:-). не JIT'ом единым Java жива :-), но и компилятором разным:
http://www.excelsior-usa.com/jet.html

кстати, о птичках: Garbage Collection Can Be Faster Than Stack Allocation. Andrew W. Appel 1986 http://www.cs.princeton.edu/~appel/papers/45.ps

Круто!!!
Язык написаый на С быстрее С++

> А у вас зато нету нормальной сериализации и RTTI =)
А у вас виджеты нативные фиг сделаешь :-). Да и аппликуху в 5Kb не напишешь :-).

Re:

Читать про smartptr?

> Язык написаый на С быстрее С++
Java (язык) не написана на C, компилятор - да. JVM тоже, а язык :-)... хм хм... я даже себе представить боюсь как это можно сделать. ;-).

> А у вас виджеты нативные фиг сделаешь :-)

Да запросто! =)

http://www.livejournal.com/users/trejkaz/78893.html

> Да и аппликуху в 5Kb не напишешь :-).

HelloWorld.class занимает 427 байт! =)

> HelloWorld.class занимает 427 байт! =)
Ты JRE посчитал? ;-).

> А у вас виджеты нативные фиг сделаешь :-)
Ога ;-). Еще и Eclipse SDK потащили :-). Ню-ню :-).

> Ты JRE посчитал? ;-).

При большом количестве (объеме) жабских прог накладными расходами на JRE можно пренебречь - это константа:)))

> Ты JRE посчитал? ;-).

Гм... а ты ядро + glibc (ну или msvcrt.dll) посчитал?

> Ога ;-). Еще и Eclipse SDK потащили :-). Ню-ню :-).

Если кто не понял - по приведенной мной ссылке тот скрин что наверху (нормальный) - это Swing! А нижний, убогий - SWT.

А вообще с доведением до ума Windows look'n'feel в 1.4.x, под винду Swing сейчас очень даже нативно смотрится. Линухи всякие, как тут кто-то уже упомянул, не в счет, а для взрослых дядей есть мотиф =)

Вообще-то Автор не хотел показать какой компайлер эффективней.
Он хотел показать что запуская java приложение by default in the CLIENT VM будет намного медленнее чем запуская тотже код под SERVER VM.

CLIENT VM != SERVER VM.

т.е. в тех тестах где java быстрее С++ код был запущен под SERVER VM.

например java -server -jar beanshell.jar

>>>>
"Unfortunately, Java applications and applets run by default in the client VM," Lea observes. "The Server VM is much faster than the Client VM, but it has the downside of taking around 10% longer to start up, and it uses more memory."
<<<<

недостатки SERVER VM 10% longer to start up and uses more memory.


также автор предлагает поменять настройки в конфиг файлах чтобы by default все программы запускались под SERVER VM.


>>>Modify the jvm.cfg

-client KNOWN
-server KNOWN

>>>You should change them to:

-server KNOWN
-client KNOWN

>>>This change will cause the server VM to be run for all applications, unless they are run with the -client argument.

> ...orld.class занимает 427 байт! =)

господа, надо разобраться что такое байткод!

ИМХО, берём срц, убираем: пробелы, табы..., кое-что оптимизируем /циклы, пути/, ставим I у интегеров, F у флоатов,..., загоняем в класс-файл - ВМ разберёца.

...поэтому и маленький, что полутекстовой файл

IMHO, IMHO, IMHO... :)

Оба скрина - убогие (из прошлого века видимо), ибо кружок без АА.

> HelloWorld.class занимает 427 байт! =)

И к нему мегов эдак 30 всякого дерьма и хрен он с тобой поздоровается на 8 метрах озу ... Embedded technology ? Нах!

> ИМХО, берём срц, убираем: пробелы, табы...

Все не так просто. К счастью ;) А вообще - шагом марш на сайт сантехников, там лежит спецификация на VM...

> И к нему мегов эдак 30 всякого дерьма

Кстати, на SuSE Linux, ява ставится по дефолту. В дженте - ставится при emerge system, если в явном виде не сказать USE="-java". В маказ 0 идет предустановленная. На винде нет, это да... ПОКА нет. Но нынче сан с майкрософтом дружат, и уже что-то там проскакивало насчет включения JRE в стандартную поставку виндов. Так что мы еще посмотрим =)

В вашем телефоне (сотовом), если он конечно есть, тоже есть java (если телефон не очень давнего производства), но боюсь он обладает значительно более скромными параметрами, нежели заявленные вами.

> Читать про smartptr?

Читайте :)

So today's Standard C++ has exactly one smart pointer: auto_ptr. That's it. So it must be all you need, right? Not a bit of it. There's more to this story.

http://www.cuj.com/documents/s=7980/cujcexp2008sutter/

Ну и, вообще говоря, для того, чтоб воспользоваться прелестями smart pointer'а надо ЯВНО его создать. Натурально, в коде написать: хочу смарт поинтер. Если забудешь, то никто тебе не поможет, кроме аудитов кода. Легче, конечно, чем с delete, но все же...

> Гм... а ты ядро + glibc (ну или msvcrt.dll) посчитал?
А JRE без них уже работает? ;-))))

>Если кто не понял - по приведенной мной ссылке тот скрин что наверху
>(нормальный) - это Swing! А нижний, убогий - SWT.
Ога не понял....

>А вообще с доведением до ума Windows look'n'feel в 1.4.x, под винду
>Swing сейчас очень даже нативно смотрится.
Хм... то что оно выглядит нативно нафиг не надо. Надо чтобы оно работало нативно :-). Есть биндинги для QT/GTK но это ж... :-)))...

ИМХО недостатки в этом случае не в языке, а просто в отсуствии библиотек классов. Если сравнивать критическое кодирование на С++ с Java-кодированием, то ты действительно прав. Но этот недостаток устраним если писать нормально. Таким образом этот тест и показывает, что основная причина тормознутости на С++ - кривость рук. Однако на С++ можно можно оптимизировать код по самые уши. В С++ от кодирования высокого уровня можно свободно переключиться в коде на низкоуровневое. ИМХО яву с С++ вообще сравнивать все равно что лопату и бейсбольную биту. Битой копать неудобно, а лопатой в бейсбол играть.

> Хм... то что оно выглядит нативно нафиг не надо. Надо чтобы оно работало нативно :-).

А зачем? Я когда-то тоже этим страдал, потом понял что совершенно не важно, что там под капотом, главное чтоб смотрелось так же =)

Кстати, Qt под винду ведь тоже виджеты сам рисует. Да что там, майкрософтовский WinForms и тот надписи и кнопки сам отрисовывает (хотя можно включить и нативную отрисовку - но явно, в коде) - ибо функциональность нативных контролов в Win32 на редкость убога.

А про линух - тут отдельный разговор... есть конечно GtkStyle, но он сыроват, да и далеко не все проги позволяют его включать - я час провозился с IDEA - так и не смог =(

Впрочем, под линухом ява тормозит так, что тут уже не до мелочей типа нативного look'n'feel. Почитайте вот:

http://forums.gentoo.org/viewtopic.php?t=38138&postdays=0&postorder=a...

Ява на линухе в БОЛЕЕ ЧЕВ ДВА РАЗА медленней, чем под Win2K, причем последняя крутится в vmware под тем же линухом! Каково, а?

Остается только надеяться, что в 1.5 все будет лучше. Но у меня сейчас в дженте стоит последняя бета 1.5, на пробу, и серьезных улучшений не заметно =(

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

О! Расскажите нам про возможности явы на телефонах!

>Ява на линухе в БОЛЕЕ ЧЕВ ДВА РАЗА медленней, чем под Win2K, причем
>последняя крутится в vmware под тем же линухом! Каково, а?
??????????????????????????????? В данный момент у меня в трее свернут Together... вот уж что-что, а он под линухом на той же самой машине работает заметно шустрее. Похоже что-то где-то у кого-то из нас настроено не так...

> потом понял что совершенно не важно, что там под капотом, главное
> чтоб смотрелось так же =)
Важно... Ибо нативный виджет будет работать заведомо быстрее :-\...

auto_ptr это гм... мягко говоря не то что нужно :-). Годится только чтобы указатель вернуть юзерскому приложению из своей библиотеки.

>и вообще int должен быть 4 байта и никак иначе..- остальное от дукавого

существует такое правило: sizeof(short int)=2, sizeof(long int)=4, sizeof(int) платформозависимое. может быть как 2 так и 4 байта

> auto_ptr это гм... мягко говоря не то что нужно :-).

Ну вот я и предложил товарищу почитать :)

> может быть как 2 так и 4 байта
может быть и 8, как было написано в документашке, что была приведена ниже. :-).

>Вы, господа, не в куриваете что с 1.2 появился JIT, а в 1.4 уже нет classic и потому проспали что в java байткод уже давно не интерпретируеться, а компилируеться в натив Just In Time компилером. И если бы не многие грабли в спеке VM пирожки бы пеклись еще быстрее... Но по спеке не положено. И еще перед тем как приводить результаты надо кое что прочитать про JITы. Насколько я вижу шансов им не дали. Вот если бы для server jit код испольнился хотя бы 8000раз до замера пирожки выпеклись бы еще быстрее. А с тригонометрией да - в Sun 1.4 там какое-то прогонялово

а время на компиляцию будем добавлять к времени работы приложения или как? на таких вот синтетических тестах в итоге получится ой как все плохо

> а время на компиляцию будем добавлять к времени работы приложения или как?

А вы попробуйте это время как-нибудь выкинуть :)

> Похоже что-то где-то у кого-то из нас настроено не так...

А вы тесты погоняйте...

У меня и Eclipse, и IDEA под виндой работают заметно шустрее. Линух - джента на ядре 2.6.5, glibc собран с NPTL.

> Важно... Ибо нативный виджет будет работать заведомо быстрее :-\...

Во-первых, совсем не обязательно. Вы ведь не думаете, что нативные виджеты на платформе - какие-то особенные? Они так же отрисовываются из графических примитивов каким-то кодом. И нет совершенно никаких оснований полагать, что этот код в системных библиотеках будет быстрей, чем в qt-mt.dll. Про "нативность" гуя под линухе я вообще молчу - это анекдот в одно предложение. Вы же не скажете, что Qt "нативней" Gtk?

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

> существует такое правило: sizeof(short int)=2, sizeof(long int)=4, sizeof(int)

Такого правила не существует. Существует только одно правило:

sizeof(long long int) >= sizeof(long int) >= sizeof(int) >= sizeof(short int) >= sizeof(char)

Кто не в курсе - long long int это стандартный тип в C99.

Предлагаю всем умникам, который кричат, что приплюснутый си - рулез, а джава - сакс, сесть и переписать примеры на си-пи-пи так, что бы они показывали лучший результат, и выложить это дело народу.
Вот тогда и померяем, чья пиписька длиннее ;-)

>>выигрывает по скорости у C++
Какая удивительнейшая хрень !

>>>выигрывает по скорости у C++ >Какая удивительнейшая хрень !

Смотрите телепередачу "Удивительное -- рядом!" :)