C vs. JVM's benchmark

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

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

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

причем с использованием expression templates (доступных например в STLPort) память будет выделена только один раз и никакие временные строки создаватся не будут.

PS. С++ FTW

>Не думал что когда-нить наступит время, когда алгоритм, выполняющийся через всякие прослойки-надстройки будет работать с такой же скоростью, будучи запущенный непосредственно на железе. Но сан сделал фантастику реальностью. Сану респект.

Скорее позор горе программистам:) Больше на истину похоже.

Строки вроде православно хранить в wchar_t. И длину вроде, обычно выражают в виде int-ового поля, а не \0, который часто "лёгким движением руки" превращает алгоритм из O(N) в O(N^2).

Кстати malloc возвращающий 0 тоже не обработан.

>А ну сложи 2 стринга переданных в качестве параметров:)?

А теперь ты "сложи" два стринга в Яве без перевыделения памяти. :))

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

сначала читать Джоэля, а потом думать про то что есть с++, где можно писать либо простой код, либо более эфективный

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

Лучше так: { char* message; int len1 = strlen(text_1), len2 = strlen(text_2); message = malloc((len1 + len2 + 1) * sizeof(char)); if(message) { memcpy(message, text_1, len1 * sizeof(char)); memcpy(message + len1, text_2, len2 * sizeof(char)); } return message; }

>Кстати malloc возвращающий 0 тоже не обработан.

:)))

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

>почему это работает?

можешь там написать string[100] = 0; тожде будет работать даже если память не выделена столько. Только херово работает.

елки забыл сделать + 1 во втором memcpy

> malloc((len1 + len2 + 1) * sizeof(char))

sizeof(char) == 1. Нафиг это писать?

> сначала читать Джоэля, а потом думать про то что есть с++, где можно писать либо простой код, либо более эфективный

Та да. Но мы ж не про великую уникальную задачу сложения стрингов говорим правда? Это просто показательный пример. C++ этиз проблем решает только библиотеками которые в себя запрятали этот рак - но если надо будет релизовывать что-то ще - вперед и с песней по всем граблям. Вот тут клиент спросил почему у него запись за пределы выделенной памяти работает. Вот объясни ему - язык такой.

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

>И С создавался для своей ниши и везде и всюду не использовался.

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

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

> Человек который на С будет писать например вебприложение - не просто быдлокодер а быдлокодер шизонутый на всю голову.

тоньше надо ( с )

>елки забыл сделать + 1 во втором memcpy

Давайте давайте - яуже вижу как этот топик целиком переходит на баш.орг - "так они и писали сложение 2х строк неделю" :)

>Кстати ява имеет бинарную совместимость на любых платформах искаропки.

Вон у нас в одной локалке одного сибирского города написали "кроссплатформенную" программку на жабе. Умудрились сделать это так, что под Linux (в большинстве дистров) она работает только на сановской жабе, причём 5-й версии. На 6-й уже не работает. На другой жабе тоже не работает. Но на каком-то из дистров она всё-таки заводилась и на 6-й сановской, и даже на сторонней жаба-машине.

А ты мне тут сказки рассказываешь про кроссплатформенность и совместимость....

>sizeof(char) == 1. Нафиг это писать?

Я не уверен на счет всех платформ, хотя на вменяемых это так, компилятор должен выкинуть это умножение, если оно не нужно.

Ну так то - профессионалы. Небось sun.* использовали во весь рост.

Компилятор то выкинет, а мусора для глаза прибавляет. Или вы для компилятора пишете а не для человека?

А насчёт платформ не совсем понял, sizeof(char) == 1 по стандарту.

>Та да. Но мы ж не про великую уникальную задачу сложения стрингов говорим правда?

Так приведите, пожалуйста, эффективную реализацию конкатенации строк на Java.

Разве StringBuffer, StringBuilder не КОСТЫЛИ?

String f(String a, String b) { return a + b; }

> Разве StringBuffer, StringBuilder не КОСТЫЛИ?

Нет.

ну это какбы не интересно, что толку си с явой сравнивать, ясно кто быстрее. вот жаву с .нет сравнили бы, это да..

.NET на линуксе не работает => оффтопик.

Неправославно, если a и b имеют размер, превышающий несколько миллионов символов.

>Я не уверен на счет всех платформ, хотя на вменяемых это так

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

> Неправославно, если a и b имеют размер, превышающий несколько миллионов символов.

И что ты от меня хочешь? Я из астрала должен память для результата взять?

>Ну так то - профессионалы. Небось sun.* использовали во весь рост.

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

Компилю azureus JET-ом =)

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

>Разве StringBuffer, StringBuilder не КОСТЫЛИ

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

Ну санки вряд ли обещали backward-compatible своих внутренностей. JDK вроде не трогали.

> #include <string> ... s3 = s1 + s2;

Какое то неправильное сравнение. К примеру на Си тогда можно написать так :
#include "myfunctions"
char *message = sting_add(text_1+text_2);

По сути сравниваються наличие либов ...

Лучше бы сравнили сложение двух строк без каких либо ( даже встроенных )
либ. И заодно как это будет выглядеть на Java ? ;)

А как не работает? У меня не работало один раз - под IBM JDK, как раз из за sun.чего-то.

>Неправославно, если a и b имеют размер, превышающий несколько миллионов символов.

Какакая разница? Временных строк там не будет. Это компилируется в return new StringBuilder(a).append(b).toString();

Я уже написал, как это выглядит на Java. В ней нет перегрузки операторов, кстати, поэтому это часть языка.

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

Ну - это вообщето артефактный символ оствашийся со времен когда железки говорили только на us_ascii.

Но "меня эти подробноти не интересуют" - мне строки складывать:)

http://linfoline.homedns.org/API/glib/glib-String-Utility-Functions.html#g-st...

gchar *str = g_strconcat( str1, str2, NULL);

>gchar *str = g_strconcat( str1, str2, NULL);

Так держать - уже glib подполз!:)

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

>Человек который на С будет писать например вебприложение - не просто быдлокодер а быдлокодер шизонутый на всю голову.

В некоторых случаях на эту задачу можно посмотреть с другой стороны. Например, есть большая и сложная программа на С, которая, сидя на рабочем сервере считает какой-нибудь физический процесс. Допустим также, что нужно мониторить процесс расчёта и останавливать/корректировать/перезапускать его, находясь дома за обычным ПК. Пишется дополнение к программе, которое, скажем, формирует растровую картинку текущей итерации расчёта и отдаёт её через Апач в интернет плюс HTML форма с элементами контроля. Такую программу можно назвать веб-приложением? В некотором смысле - да.

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

Весьма неэффективное, надо сказать. При этом выделяется кусок памяти размером a.length()+b.length() и производится посимвольное копирование в него последовательно первой и второй строк. После этой операции ссылки на a и b, если они больше нигде не используются, передаются GC для очистки содержимого памяти от a и b.

Память распределяется крайне неэкономно.

>При этом выделяется кусок памяти размером a.length()+b.length() и производится посимвольное копирование в него последовательно первой и второй строк. После этой операции ссылки на a и b, если они больше нигде не используются, передаются GC для очистки содержимого памяти от a и b.

Больше никому об этом не говори. И хоть раз декомпилируй этот код.

Ты может быть будешь удивлён, но в С сложение строк происходит точно так же. За исключением того, что память удаляется руками (при необходимости).

Только тесты чисто счетные в основном.А вот если и считать и с памятью работать, скажем, сжатие или шифрование, etc - Java сильно в попе по производительности.Сливает типично процентов на 40-50 или более порой.Кто не верит - бенчит сам.Примеры бенчей (включая версии на жабе и дотнете) есть скажем на http://www.quicklz.com/

Jet 6:

              Excelsior LLC
          6 Lavrenteva Ave.
 Novosibirsk 630090 Russia
 Phone: +7 (383) 330 55 08
    Fax: +1 (509) 271 52 05
Web: www.excelsior-usa.com


Русские иногда рулят :-)

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

>для всяких быдлокодеров - да

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

А чем это отличается по сути от вышепреведенного кода на C? *lol*

>А как не работает? У меня не работало один раз - под IBM JDK, как раз из за sun.чего-то

Да хрен его знает. С ошибкой вроде какой-то вываливается. Прога консольная.

Мне самому её поюзать не довелось (ТНБ миловал) :)

> Ну скажем так - скорость работы алгоритма, скомпиленного в бинарные коды явамашины (и выполняющегося в явамашине) сравнима со скоростью скомпиленного в C++ кода (и выполнящегося непосредственно самим процом). А в некоторых случаях даже опережает.

man jit