C vs. JVM's benchmark

> О небыдло набежало. Ты хоть опыт работы в индустрии имеешь? Что-нибудь делал в индустрии сложнее 3к строк написанных более чем 3 людьми?

http://valentina-db.com

а сам то ты что написал?

DemoStrings.java:

public class DemoStrings {
    public static void main(String[] args) {
		String a ="a" + args[0];
		String b = "b" + args[1];
		String c = a + b;
		System.out.print("c=" + c);
		
	}
}

DemoStrings.class: размер 910 байт

Декомпилировал, посмотрел.
Какого, спрашивается, рена среда положила туда:
//Method java/lang/StringBuilder.append
???
Я вроде не заказывал...

>>a + b - сложение строк на жава.

>Весьма неэффективное, надо сказать.

javac это меняет на new StringBuffer().append(a).append(b).toString(). Оптимизация по ручной замене стрингов на СтрингБуффера устарела 2 my mind.

Для -target 1.2, 1.3, 1.4
используется подмена конкатенации строк (операции "+") на:
//Method java/lang/StringBuffer.append

Удивительно!

JET упал при компиляции на ~90% :(

>Для -target 1.2, 1.3, 1.4 используется подмена конкатенации строк (операции "+") на: //Method java/lang/StringBuffer.append

>Удивительно!

Алгоритмически сложного в такой замене ничего нет.

> У меня консоль юникодная - передача аргумента русскими буквами говорит что strlen одного символа - 2 - пересматриваем алгоритм и функции - переходим на следующий этап:))

А не желаете пересмотреть решения/алгоритмы Java когда в условии задачи известно, что текст на входе в однобайтовой кодировке, но его очень много?

>> char *message = malloc(strlen(text_1)+strlen(text_2)); strcpy(message, text_1); strcpy((message+strlen(text_1)), text_2);

>ололо, добровольное анальное рабство снова в моде.

>а вот код на С++ string s = s1 + " " + s2 + "...." + ...;

Сходи в Development, объясни Die Hard'у почему у него при использовании STL вся память "размалывается в труху" из-за фрагментации при использовании STL и почему она перестала "размалываться в труху" когда STL заманили на нормальный человеческий Си-лайк мемори мэнеджмент.

PS: Мне реально брезгливо читать твои желчные психопатические комментарии. Залогинься, я тебя заигнорю - составишь компанию iRunix & haywire.

> используется подмена конкатенации строк (операции "+") на: //Method java/lang/StringBuffer.append

> Удивительно!

В С++ такие вещи делаются на expression templates для любых типов.

>Ну это я ещё как-то могу понять. Но как они умудрились сделать так, что программа работает в 5-й и не работает в 6-й??

Да запросто, добавились новые методы, конструкторы и т.д. и т.п. Такие вещи кругом и повсюду. Надо как бы понимать, что кроссплатформенность != обратная совместимость релизов. Как вариант использую 5-е либы и будет счастье.

>Java никогда не догонит и тем более, никогда не перегонит, по скорости, потреблению памяти, простоте и изяществу грамотно написанный код на С

Си никогда не догонит и тем более, никогда не перегонит, по скорости, потреблению памяти, простоте и изяществу грамотно написанный код на ассемблере.

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

Машинные коды универсальных процессоров никогда не догонят и тем более, никогда не перегонят, по скорости, потреблению памяти, простоте и изяществу грамотно разработанную аналоговую схему.

Вот только "грамотно написанный код на C" пишется очень долго. :(

Вот только "грамотно написанный код на C" пишется очень долго... неграмотными iZEN'ами-макофилами:)

Это понятно. Но почему про это не говорят явно, а везде говорят (Джоэл Спольски, например) о ручной оптимизации конкатенации строк, в частности для Java с применением StringBuffer|StringBuilder:
http://russian.joelonsoftware.com/Articles/BacktoBasics.html
"Ладно. Жизнь в стране байтов становится всё сложнее. Правда, хорошо, что вам не надо больше ничего писать на C? В нашем распоряжении есть такие великолепные языки, как Perl, Java, VB и XSLT, которые не заставляют думать ни о чём таком низком, они сами со всем как-то справляются. Вот только иногда трубы вылезают в середине гостиной, и нам приходится думать о том, какой класс использовать -- String или StringBuilder, потому что компилятор всё ещё недостаточно умён, чтобы понять, чего же мы собственно хотим достичь, и помочь нам избежать попадания на алгоритм маляра Шлемиэля."

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

4.2

могу не читая не по ссылкам не комментов сказать что там ява жжетЪ

вот щас запощу и почитаю

даже самому интересно

стало

>sizeof(char) == 1

Быдло-x86-кодер детектед.

>на С реализовано намного больше функционала чем на жабе.

Более того - на C реализована сама "жаба":)

>А char это не символ, это байт :)

char - это не байт. Посмотри для расширения кругозора на PDP.

>4.2

Ассемблер - это не только tasm или masm.

ппц. суперпрофи не различает strlen() и sizeof()

>Ну давайте уже финальный вариант, господа сишники, в нормальном оформлении.

http://www.megabytov.net/linfoline/API/glib/glib-Strings.html

одного достаточно

>>на С реализовано намного больше функционала чем на жабе.

>Более того - на C реализована сама "жаба":)

Где ты такую нашёл? У меня только на C++.

>Ну давайте уже финальный вариант, господа сишники, в нормальном оформлении.

Если кому-то поупражняться интересно - вот вызов есть: http://balancer.ru/tech/forum/2008/02/t60021--CHto,gospoda-surovye-S-plus-plu...

4 месяца прошло, желающих решить задачу на Си/Си++ не нашлось. Не смотря на относительно невысокую сложность и опубликованные решения на Java и даже Python :)

>Что-нибудь делал в индустрии сложнее 3к строк написанных более чем 3 людьми?

"сложнее 3к строк", "написанных более чем 3 людьми", да ещё и "в индустриИ" - это и есть быдлокод:)

капча bouring как бы говорит, какой ты унылый и скучный зануда.

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

Конечно, если вам нужно выжать предпоследние 20% по производительности - пишите на C, с вами никто не спорит. Если вам нужен realtime или вы пишете драйвер - пишите на C, ясное дело. Если вы пишете маленькую самостоятельную аппликуху, которая должна быстро запускаться как самостоятельное приложение, то пишите на C.

<flood>

А что до "сложения" двух строк, так вот как раз в си это сделать проще простого:

s = (char*)((int)s1 + (int)s2)

Разве вы имели в виду s1+(int)s2? ;-)

</flood>

>"сложнее 3к строк", "написанных более чем 3 людьми", да ещё и "в индустриИ" - это и есть быдлокод:)

А "небыдлокод" - это менее 1000 строк написанных в одно рыло? :D

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

>>sizeof(char) == 1

>Быдло-x86-кодер детектед.

sizeof(char) по стандарту всегда == 1. Только вот CHAR_BITS может быть например 32.

> В Blu-ray ява не тормозит!

простите, где ?

>> 4.2

> Ассемблер - это не только tasm или masm.

Правда? O_o

Язык ассемблера, по определению, 1:1 отображается в набор инструкций процессора (да, бывают случаи, когда конкретный ассемблер не поддерживает какие-нибудь малоиспользуемые команды).

> Язык ассемблера, по определению, 1:1 отображается в набор инструкций процессора

определение сам придумал?

>> В Blu-ray ява не тормозит!

>простите, где ?

В устройствах для воспроизведения дисков Blu-ray используется Java.

http://en.wikipedia.org/wiki/Blu-ray_Disc
"Java software support

Main article: BD-J

At the 2005 JavaOne trade show, it was announced that Sun Microsystems' Java cross-platform software environment would be included in all Blu-ray Disc players as a mandatory part of the standard. Java is used to implement interactive menus on Blu-ray Discs, as opposed to the method used on DVD video discs, which uses pre-rendered MPEG segments and selectable subtitle pictures, which is considerably more primitive and less seamless. Java creator James Gosling, at the conference, suggested that the inclusion of a Java Virtual Machine as well as network connectivity in some BD devices will allow updates to Blu-ray Discs via the Internet, adding content such as additional subtitle languages and promotional features that are not included on the disc at pressing time. This Java Version is called BD-J and is a subset of the Globally Executable MHP (GEM) standard. GEM is the world-wide version of the Multimedia Home Platform standard."

>Язык ассемблера, по определению, 1:1 отображается в набор инструкций процессора

Некоторые трансляторы даже ассемблерный текст оптимизируют. В частности, TASM оптимизировал длину джампов и коллов, потому как двухпроходным был. Естественно, можно было всегда указывать явно длину комманды перехода, но всё же:)

Кстати, до сих пор не понимаю: почему C называют "переносимым ассемблером"? В этом убожестве даже битность базовых типов не определена, не говоря уже о том, что порядок вычисления выражения даже принудительно указать нельзя :(

> Стэфан Краузе в своём блоге

вообще-то Штефан.

> Java cross-platform software environment would be included in all Blu-ray Disc players

эмм, речь идет о плеерах, а не о самой технологии, Java будет только менюшки рисовать ...

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

>> Java cross-platform software environment would be included in all Blu-ray Disc players

> эмм, речь идет о плеерах, а не о самой технологии, Java будет только менюшки рисовать ...

Потому и не тормозить!!!

> Естественно, можно было всегда указывать явно длину комманды перехода, но всё же:)

Вот именно - можно было. Т.е. при желании, можно было прозрачно писАть машкоды в удобной нотации %) Об этом и речь.

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

И что с ним делать? Он только для убогой x86 код компилит (да даже для AMD специально код замедляет) - дальше можно не смотреть.

>Вот именно - можно было. Т.е. при желании, можно было прозрачно писАть машкоды в удобной нотации %) Об этом и речь.

"При желании" макроопределениями можно было любые инструкции реализовать, даже несуществующие:)

> объясни Die Hard'у почему у него при использовании STL вся память "размалывается в труху"

Чего дураку объяснять. Юзать надо кошерные реализации STL, и юзать с головой. Где того требует задача можно хоть на SSE4 инструкциях писать.

>>Т.е. при желании, можно было прозрачно писАть машкоды в удобной нотации %) Об этом и речь.

>"При желании" макроопределениями можно было любые инструкции реализовать, даже несуществующие:)

Ну полная аналогия с машкодами - там тоже можно любые комбинации байтов вкрячить :D

байт - минимально адресуемая ячейка памяти. сколько там битов - не важно.

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

Вот у меня сейчас собирается ядро. Более чем 4 миллиона строк. Это как по вашему, простая программа? Ну напишите это на яве или на пыхпыхе - я поржу.

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

Тото я смотрю у меня десктоп весь на жабе: Гном, ФФ, Пиджин, Емакс, Трансмишион...

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

Байт - это 8 бит. Сколько байт в минимально адресуемой ячейке - не важно.

> Байт - это 8 бит

С чего это вдруг? Пруфлинк.

>Короче вопросы еще у кого-то остались по поводу применимости языка С?

Может мы с тобой какой-то разный Линукс юзаем? Потому что 90% используемого мной софта написано на Ц/Ц++.