C vs. JVM's benchmark

Памяти при 16 кушает около 800 MB.

>Ты не избавился от привычки "С++-подобный синтаксис".

Мсье телепат? :D

Или, скажем, Форт считается за "С++-подобный синтаксис"? ;)

...

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

Ха!

Яву таки порвали ! :)

> Яву таки порвали ! :)

Нифига! Они теперь критические участки под JNI заделают.

>>Ты не избавился от привычки "С++-подобный синтаксис".

>Мсье телепат? :D

>Или, скажем, Форт считается за "С++-подобный синтаксис"? ;)

Упс! При чём тут Forth? Ты же сам говорил, что C++-подобный синтаксис для тебя "привычнее":) Забыл?

> Интересно. Новый флейм на тему "Java быстрее машинного кода". Что, кругом одни индусы, что-ли?

> Чем определяется скорость программы? Во-первых, алгоритмом, во-вторых, деталями реализации. Если используется один и тот же алгоритм на Java и C, и Java быстрее - вывод только один: реализацию делал идиот. При всех достоинствах Java, С всегда быстрее на одинаковых алгоритмах, если использовать особенности C. Автор теста, скорее всего, постарался сделать код на C максимально повторяющим код на Java. Ну, не индус ли, несмотря на фамилию?

> Кстати, господам, воспевающим легкость Java для неквалифицированной рабочей силы. Вы что, правда считаете, что 20 идиотов с Java напишут код быстрее и лучше, чем 5-6 приличных сишников? Флаг вам в руки. Паровоз навстречу уже выехал.

флейм на тему "Машкод через JIT быстрее машкода через обычный компилятор" :)))

Один и тот же алгоритм можено реализовать по разному. И нужно быть идиотом чтобы этого не понимать.

Понятие лучше требует раскрытия. Для многих компаний лучше означает быстрее налабать и продать, а не красивый код и оптимальный алгоритм. По этой характеристике "лучше" и дешевле 20 кодеров, чем 5-6 приличных сишников. Да сейчас прилисного сишника хрен найдешь, а Java кодера можно сделать хоть из С-кодера, хоть из Delphi-кодера. И работает что самое интересное ;)

>>ХЗ. работаю в проектах под западных заказчиков. У них только Линукс на серваках (RedHat). Все проекты что участвовал - запуск под Линукс, некоторые штатный запуск ТОЛЬКО ПОД ЛИН.

>Вроде как речь шла о десктопном софте. Что жава отличная вещь для серверных приложения(помимо убогого языка) я уже кажется признал давно и неоднократно.

Ок, принято. Тогда для полноты картины открою страшную тайну :)))

Графическая система базовой Java всем хороша - на ней можно ваять практически все, сами компоненты можно переделывать и переопределять и т.п. Есть только одно НО эти мега возможность ОБЯЗАТЕЛЬНО использовать для рисования GUI на Java. потому сложность Java-GUI намного выше чем остальных подсистем и порог вхождения заметно выше чем у других. Потому как линуксоиды ждут очередного виндокапца, Java-GUI-dev's эдут очередных улучшений от Sun'a.

>> Примерчик можно?

> mv /usr/bin/javac /usr/bin/javac.orig ln -s /usr/bin/gcj /usr/bin/javac

> Компилим какое-нибудь динамичное приложение с генерацией изображений и наслаждаемся мегатормозами.

<troll-off>GCJ, при всем моем уважении к GNU, не является Java(tm) компилятором, потому сравнение не корректно. Можно испохабить gcc, затем им же (переглюченным) пытаться собирать приложение и кричать, что gcc говно т.к. даже код скомпилировать не может. Стыдливо умалчивая, что пользуешься кривостью.</troll-off>

>Графическая система базовой Java всем хороша - на ней можно ваять практически все, сами компоненты можно переделывать и переопределять и т.п. Есть только одно НО эти мега возможность ОБЯЗАТЕЛЬНО использовать для рисования GUI на Java. потому сложность Java-GUI намного выше чем остальных подсистем и порог вхождения заметно выше чем у других. Потому как линуксоиды ждут очередного виндокапца, Java-GUI-dev's эдут очередных улучшений от Sun'a.

Странно, что Вы не среагировали на "убогий язык". Жаверы обычно пытаются защищать этот ужас :)

> Странно, что Вы не среагировали на "убогий язык". Жаверы обычно пытаются защищать этот ужас :)

Это не ужас, это тоска %)

ээ.. ждут? JavaFX/Groovy - не вариант?

>> Яву таки порвали ! :)
>>Нифига! Они теперь критические участки под JNI заделают.
>>eugine_kosenko

Дык JNI обычно и означает - C/C++ .... Эх а я только вчера девчонкам рассказал что Ява быстрее процессора, теперь вестимо не дадут :(

Но а если серьёзно - всякие унылые бизнес-аутомаэйшн-системы писать - Ява самое оно! На плюсах там неоправданно много секса. Правильно тэйлганнер сказал - "Это не ужас - это тоска :)"

Ну и уж совсем напоследок - теоретически реализация на схеме должна всех зарулить по памяти/строкам кода (из за знаметиной хвостовой :), по скорости впрочем не уверен - кто нибудь делал?

>Ну и уж совсем напоследок - теоретически реализация на схеме должна всех зарулить по памяти/строкам кода (из за знаметиной хвостовой :), по скорости впрочем не уверен - кто нибудь делал?

Ааа. Так вот оно что. У вас схема быстрее компьютера, C, C++, JNI, паскаля, Asm-а и OpenGL вместе взятых. ФетишЪ хвостовой рекурсии. Схема головного мозга, СГМ, ну да, знакомый диагноз.

>Ааа. Так вот оно что. У вас схема быстрее компьютера

Русский выучи чурко :)
Я сказал зарулит по объёму схаванной памяти и строкам кода в исходнике.
По скорости - сказал совсем не уверен ...

>Упс! При чём тут Forth? Ты же сам говорил, что C++-подобный синтаксис для тебя "привычнее":) Забыл?

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

вопщем проверил я на работе наконец сво реализацию ... на Core 2 Duo 2,6 4 гигабайт памяти ...

total solutions 1846955 in 110 seconds.

чуть побольше чем у анонимуса с 97 секундами, но все равно неплохой результат ... также 900 мегабайт памяти жрет ... чуток подоптимизированный вариант http://slil.ru/25962907 выложите наконец на balancer.ru ну не хочу я там регистрироваться ...

многопоточную реализацию мне уже лень делать ... итак однопоточная быстрей многопоточной реализации на яве в 4 раза, а если ещё второе (третье, четвертое) ядро загрузить то ваще ... правда у автора решения на яве чуток послабже компьютер ...

чорт, невнимательно глядел ... на c2d 2,6 ггц на яве 129 сек :( ... совсем небольшой разрыв ... блин, таки сделать чтоли многопоточную реализацию ...

> http://pastebin.com/m3a69f8a6

хотел позапускать, но че-то не компилится у меня на винде :( грит queens.cpp(6) : fatal error C1083: Cannot open include file: 'tr1/cstdint': No such file or directory похоже там какие-то gcc-шный h-ники использвоались ...

>>Графическая система базовой Java всем хороша - на ней можно ваять практически все, сами компоненты можно переделывать и переопределять и т.п. Есть только одно НО эти мега возможность ОБЯЗАТЕЛЬНО использовать для рисования GUI на Java. потому сложность Java-GUI намного выше чем остальных подсистем и порог вхождения заметно выше чем у других. Потому как линуксоиды ждут очередного виндокапца, Java-GUI-dev's эдут очередных улучшений от Sun'a.

>Странно, что Вы не среагировали на "убогий язык". Жаверы обычно пытаются защищать этот ужас :)

Буду добивать тебя дальше )))) А я согласен, что Java имеет более убогие возможности для программирования, чем С. ;) только в больших приложениях это ПЛЮС ))) у нас к примеру 8 команд по 5-8 человек программистов + манагеры, админы и т.п - получаем примерно 60-80 девоФ. Понятно, что при таком количестве народу уровень у всех очень разный, и Чем меньше возможностей у дева написать мутную хрень тем лучше.

Следующий пример: if(func1() && func2()) - будет ли вызвана func2()? всегда ли? и можно ли гарантировать это поведение (любое однозначное поведение)?

попробовал у себя же на машине Java реализацию, вот что получилось

E:aqueens_java>java -Xmx1500m com.ssv.test.samples.queens.EightQueens 16
16 queens.
Started at:Mon Jul 07 12:59:18 YEKST 2008
Finished at:Mon Jul 07 13:03:33 YEKST 2008, after 255308 ms.
1846955 solutions found.

E:aqueens_java>java -Xmx1500m com.ssv.test.samples.queens.EightQueens 16 thread
ed
16 queens.
Started at:Mon Jul 07 13:03:48 YEKST 2008
Finished at:Mon Jul 07 13:06:11 YEKST 2008, after 142841 ms.
1846955 solutions found.

напомню, c2d 2,6 Ггц 4 ГБайт памяти ... 
таки да, многопоточная реализация работает заметно быстрей, за счет использования второго ядра ... 

>Следующий пример: if(func1() && func2()) - будет ли вызвана func2()? всегда ли?

Как раз в этом случае func2() будет вызвана всегда и только тогда, когда func1() вернёт не-ноль.

"Иногда лучше жевать", чем с такими "знаниями C" лезть с заявлениями.

Там использовались стандартные заголовочные файлы из нового стандарта :) Конкретно этот можешь заменить на #include <stdint.h>

> func2() будет вызвана всегда и только тогда, когда func1() вернёт не-ноль.

М-да... над этой фразой нужно как следует помедитировать.

>> func2() будет вызвана всегда и только тогда, когда func1() вернёт не-ноль.

>М-да... над этой фразой нужно как следует помедитировать.

Согласен, неудачная формулировка:)

Перефразирую:

func2() будет вызвана всегда в случае, если func1() вернёт не-ноль.

Я даже больше скажу, в Java поведение идентично, и что хотел сказать исходный товарищ этим заявлением, я не понял. Может быть он спутал C с паскалем, где это настраивалось опцией компилятора?

Зато в Java определён результат (x++ + x++) :)

Да он в любом языке определён, на код-ревью будет написан комментарий // TODO: Clean it

>Буду добивать тебя дальше )))) А я согласен, что Java имеет более убогие возможности для программирования, чем С. ;) только в больших приложениях это ПЛЮС ))) у нас к примеру 8 команд по 5-8 человек программистов + манагеры, админы и т.п - получаем примерно 60-80 девоФ. Понятно, что при таком количестве народу уровень у всех очень разный, и Чем меньше возможностей у дева написать мутную хрень тем лучше.

Ну вот мы снова пришли к согласию. Жава хороший язык для чувака с плеткой, который погоняет стадо индусов.

>Да он в любом языке определён

В Си/Си++ НЕ определён :)

>Зато в Java определён результат (x++ + x++) :)

А еще Гослинг следит за жабакодерами и не позволяет им защемить дверью хер.

> А еще Г-нг следит за жабакодерами и не позволяет им защемить дверью хер.

Не упоминай имя Г-нга всуе!

>Следующий пример: if(func1() && func2()) - будет ли вызвана func2()? всегда ли? и можно ли гарантировать это поведение (любое однозначное поведение)?

На Си определено и этим пользуются - if (p && strlen(p) > 0) {...}. Если p == null, то значение логического выражения сразу принимается за false и strlen под null (c неопределенным поведением в этом случае) вызван не будет.

На плюсах можно перегрузить operator&& и в этом случае поведение будет другим - оно вычислит оба операнда.

> На плюсах можно перегрузить operator&& и в этом случае поведение будет другим - оно вычислит оба операнда.

Птааг^W Гослинг оберегает тебя.

>А нафига -mfpmath=387, когда есть -mfpmath=sse, который теоретически быстрее?

а это чтобы помедленнее было у меня spectralnorm.cpp c

1: -mfpmath=387 - 843.75

2: -mfpmath=sse - 703.125

gcc-4.3.0 mingw, core2 1.8

>> На плюсах можно перегрузить operator&& и в этом случае поведение будет другим - оно вычислит оба операнда.

>Птааг^W Гослинг оберегает тебя.

Да, меня от тебя и прочих.

таки заставили меня регистрироваться на balancer.ru ... http://balancer.ru/2008/07/07/post-1588193.html

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

оптимальные алгоритмы и высокое качество кода хороши исключительно для вычислительных задачь.

>По этой характеристике "лучше" и дешевле 20 кодеров, чем 5-6 приличных сишников. Да сейчас прилисного сишника хрен найдешь, а Java кодера можно сделать хоть из С-кодера, хоть из Delphi-кодера. И работает что самое интересное ;)

жаба как язык очень прост и если говорить о кодерах, то выучить кодера жабе очень просто, а вот тому же с++-у на 3 порядка сложнее, да и времени уйдет во столько же раз больше. примерно тоже справедливо и для программистов - у с++ как у значительного более сложного языка есть множество собственных идиом для разработки в дополнении к тому, что есть в жабе и что довольно неприятно - есть куча обязательных идиом, не следуя которым невозможно получить потдерживаемый и работоспособный продукт.

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

Для любых задач. В том числе для проверки правописания :)

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

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

Java совсем не проста. Одно то, что нельзя double check lock реализовать из за её модели памяти до 1.5, чего стоит. Скажем так, у Java есть подмножество, на котором просто писать и которое достаточно мощно для повседневных задач.

> таки заставили меня регистрироваться на balancer.ru ... http://balancer.ru/2008/07/07/post-1588193.html

А если Java-версию Excelsior JET скомпилировать?

http://www.excelsior-usa.com/jetdleval.html

Примерно так:

jc com.ssv.test.samples.queens.EightQueens export JETVMPROP=-Djet.gc.heaplimit=1500M ./com.ssv.test.samples.queens.EightQueens 16 ./com.ssv.test.samples.queens.EightQueens 16 thread

Ну скомпилируй, кто мешает.

Говорила мне бабушка - не игнорируй предпросмотр.

jc com.ssv.test.samples.queens.EightQueens export JETVMPROP=-Djet.gc.heaplimit=1500M ./com.ssv.test.samples.queens.EightQueens 16 ./com.ssv.test.samples.queens.EightQueens 16 thread

> А если Java-версию Excelsior JET скомпилировать?

епта ... 70 мега ... давай попробуй и выложи результат ...

> Ну скомпилируй, кто мешает.

Дык надо же на той же машине запустить, иначе смысла нет.

>Следующий пример: if(func1() && func2()) - будет ли вызвана func2()? всегда ли? и можно ли гарантировать это поведение (любое однозначное поведение)?

поведение этой конструкции ничем не отличается от С/C++. хотите гарантий и предсказуемости - используйте Ada - там при любых обстоятельствах ( за отсутствием возникновения исключения в func1 ) позовутся обе функции. для получения жабского ( как и С/C++-cного поведения ) нужно использовать специяльную кострукцию

'if func1 and func2 then ... end if' -- гарантированно обе функции

'if func1 and then func2 then ... end if' -- func2 не зовется если func1 вернет false

>Java совсем не проста. Одно то, что нельзя double check lock реализовать из за её модели памяти до 1.5, чего стоит.

Терехов великолепно реализовал double checked locking на жабе и эта реализация ( с использованием tls ) великолепно работает и на 1.4

>Скажем так, у Java есть подмножество, на котором просто писать и которое достаточно мощно для повседневных задач.

любой Turing completed language достаточно мощен для повседневных задач, а жаба - очень простой язык.

> Терехов великолепно реализовал double checked locking на жабе

Ссылку можно?

> любой Turing completed language достаточно мощен для повседневных задач

brainfcuk, к Вашему сведению, тоже turing complete.

>> А если Java-версию Excelsior JET скомпилировать? > епта ... 70 мега ... давай попробуй и выложи результат ...

Чуда не произошло, но и разочарования тоже.

Отклонение от HotSpot 6 - единицы процентов, в разные стороны на трёх разных машинах (Celeron, Athlon, Core 2 Duo), только вот на первых двух памяти маловато оказалось для 16x16.