C vs. JVM's benchmark

> Тем не менее мы пишем именно на этом С.

Язык не имеет отношения к определению "байта". Не было бы Си. байт всё равно был бы. Кроме того, машины с побитовой адресацией ставят крест на используемом Си определении.

>Язык не имеет отношения к определению "байта". Не было бы Си. байт всё равно был бы. Кроме того, машины с побитовой адресацией ставят крест на используемом Си определении.

Из современных машин назови, в МПС я знаю есть области с побитовой адресацией.

> Eclipse Foundation объявили доступность комплекта этого года по имени Europa, включающего 17 млн строк кода при участии более 310 разработчиков из 19 стран.

За сколько строк кода считают один ява-бин с пятью полями и десятью геттерами и сеттерами?

Ну так что имеет отношение то? Мне самому интересно. Если есть источник, индекс доверия к которому будет больше чем у википедии (и цитирумых ею источников), и который скажет, что байт это 8 битов и ни битом больше, я поверю.

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

Достаточно сложная для C. Тем более это компилится часа два на AthlonXP 2500+, наверное?
Eclipse содержит 17 миллионов строк кода и компилится javac пятнадцать минут на том же процессоре.

Все так же задумайтесь о масштабах:
Сколько человек пишут ядро Linux?
Сколько человек пишут среду Eclipse?

50 как минимум. В С будет меньше? По-моему больше.

> Сколько человек пишут ядро Linux?
> Сколько человек пишут среду Eclipse?

Сколько?

>> Язык не имеет отношения к определению "байта". Не было бы Си. байт всё равно был бы. Кроме того, машины с побитовой адресацией ставят крест на используемом Си определении.

> Из современных машин назови

Из современных? Не могу. Да и зачем? Ты вроде не споришь с тем, что они есть.

Если что, у Эльбрус-2 была побитовая адресация :)

Правильно, программа должна быстро компилироваться, а как быстро она работает - это уже программиста не касается.

Прикольно ты сравнил, но раз уж сравнил, то ответь: что работает быстрее - Linux или Eclipse?

>Как и ожидалось, жаба показала себя унылее некуда...

??? Java показала себя примерно на уровне С/С++. Да, в некоторых случаях она от него отстаёт. Но не смертельно.

При этом, Java по факту имеет гарантированую безопасность при работе с массивами, сборщик мусора и встроеную в язык многопоточность. Если учесть всё это - то результат вполне приличный.

> Достаточно сложная для C. Тем более это компилится часа два на AthlonXP 2500+, наверное? > Eclipse содержит 17 миллионов строк кода и компилится javac пятнадцать минут на том же процессоре.

Вообще некорректное сравнение. gcc оптимизирующий компилятор, javac практически никаких сложных оптимизаций не делает. Там основная магия в JIT-е.

>Правильно, программа должна быстро компилироваться, а как быстро она работает - это уже программиста не касается.

Да тут же сравнение:
GCC написан на C/С++ компилирует программу на C/С++ в десятки раз дольше, чем JavaC, написанный на Java, компилирует программу на Java. Ржунимагу.

Ты бы ещё сравнил размеры бинарников компилятяторов, тоже очень "полезное" сравнение.

> Ну так что имеет отношение то?

Общепринятое определение (та же статья, ссылку на которую ты давал: "eight bits by far the most common size for a byte"). Ну и вот: http://en.wikipedia.org/wiki/Units_of_information. А то, что ты приводил - это историческая перспектива, а не сегодняшний смысл.

Ну пусть будет так.

>Из современных? Не могу. Да и зачем? Ты вроде не споришь с тем, что они есть.

Вот в современных уже это редкость, в древних архитектурах присутствует.

>javac практически никаких сложных оптимизаций не делает.

ну да, только вместо "string1 + string2" в откомпилированном .class-файле мы видим: "new StringBuilder(string1).append(string2).toString();"

Вообще все это хрень, вот сравнить C с Common Lisp :-D В CL ведь можно функции и прочее в виде ассемблерного кода на лету смотреть, а по скорости тоже очень все хорошо.

Это не оптимизация. + это синтаксический сахар, означающий именно эту конструкцию, AFAIR это даже в стандарте прописано.

>Ты бы ещё сравнил размеры бинарников компилятяторов, тоже очень "полезное" сравнение.

Не знаю, как суммировать размеры разбросанных тут и там ошмётков GCC, но tools.jar из JavaSE 6u10 JDK с javac внутри занимает 11,9 МБ. В предыдущих версиях JDK было около 6 МБ.

>Это не оптимизация. + это синтаксический сахар, означающий именно эту конструкцию, AFAIR это даже в стандарте прописано.

Лучше бы оно ушло и сделали бы "православно" то что в класс кладется.

Не пропарсил :)

>Вообще некорректное сравнение. gcc оптимизирующий компилятор, javac практически никаких сложных оптимизаций не делает. Там основная магия в JIT-е.

Другими словами байткод без JIT'а на Java-процессоре (фактически нэйтив!) будет выполняться довольно тормозно?
Странно, а почему же OperaMini на мобильных девайсах с ARM-процессором и блоком picoJava2 не тормозит?

>Лучше бы оно ушло и сделали бы "православно" то что в класс кладется.

Полностью согласен!
Это надо было делать на уровне класса String, а не придумывать сначала один костыль StringBuffer, а потом второй похожий костыль StringBuilder.

> Другими словами байткод без JIT'а на Java-процессоре (фактически нэйтив!) будет выполняться довольно тормозно?

Если его просто интерпретировать, да. Довольно или нет, не знаю, не измерял.

> Странно, а почему же OperaMini на мобильных девайсах с ARM-процессором и блоком picoJava2 не тормозит?

JavaME это не совсем стандартная Java и я не берусь что-либо утверждать про неё.

>Другими словами байткод без JIT'а на Java-процессоре (фактически нэйтив!) будет выполняться довольно тормозно?

>Странно, а почему же OperaMini на мобильных девайсах с ARM-процессором и блоком picoJava2 не тормозит?

Наверное потому что там J2Me, который заточен для мобилок с ARM ;-)

>>Странно, а почему же OperaMini на мобильных девайсах с ARM-процессором и блоком picoJava2 не тормозит?

>Наверное потому что там J2Me, который заточен для мобилок с ARM ;-)

Интересно, как этот код J2ME "заточен" для мобилок с ARM, если преверифицированные .class-файлы так же работают в приложении J2SE?

AOT-компиляция что ли?

> Другими словами байткод без JIT'а на Java-процессоре (фактически нэйтив!) будет выполняться довольно тормозно?

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

>Странно, а почему же OperaMini на мобильных девайсах с ARM-процессором и блоком picoJava2 не тормозит?

Там другой вопрос - JIT слишком дорог для мобильных устройств. Вот и обходятся java-процессором.

>> Другими словами байткод без JIT'а на Java-процессоре (фактически нэйтив!) будет выполняться довольно тормозно?
>Именно. Поэтому от Java-процессоров и отказываются. Например, Azul Systems использует в своих мега-компьютерах обычный HotSpot, но с аппаратной поддержкой ускорения GC.

"Лучше жечь электричество и греть воздух", чтобы не тормозило.


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

"Лучше не жечь электричество и не греть воздух", чтобы не тормозило.

Так почему же до сих пор используют x86 и недоязык C/C++? Риторический вопрос.

>Не знаю, как суммировать размеры разбросанных тут и там ошмётков
>GCC, но tools.jar из JavaSE 6u10 JDK с javac внутри занимает
>11,9 МБ. В предыдущих версиях JDK было около 6 МБ.

# COUNT=0 ; equery files gcc | while read i ; do if ! [[ -d $i ]] ; then let COUNT+=$(stat $i -c '%s'); fi ; done ; python -c "print \"%f MiB\" % ( $COUNT./1024**2 )"                                                                                           
64.353711 MiB

+100

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

> Весьма изящно, да. :)

там вроде сегфолт будет, места для 0x00 в результирующей строке не предусмотрели, ну и лучше сделать мемсет или использовать calloc, вместо strcpy два strcat:

char *message = calloc(1, strlen(text_1)+strlen(text_2) + 1); strcat(message, text_1); strcat(message, text_2);

или я забыл уже всё :(

а вообще, в том же glib2 есть функциональность для склеивания нескольких строк:

gchar *message = g_strconcat(text_1, text_2, NULL);

> И, да, это не канает, не unicode-aware.

если использоваться UTF8 то вполне себе работоспособно.

>"Лучше жечь электричество и греть воздух", чтобы не тормозило.

Нет. Это если ты будешь заниматься идиотством с Java-процессором - тогда, действительно, будешь виновен в глобальном потеплении.

ТАК КАК JIT ЭФФЕКТИВНЕЕ!

>"Лучше не жечь электричество и не греть воздух", чтобы не тормозило.

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

Поэтому и используют java-процессоры. Они работают медленнее нормального JITа, но БЫСТРЕЕ простой интерпретации.

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

ну если избегать ВСЕ библиотеки, кроме как стандартную библиотеку С, то да, задача. Я конечно понимаю что str + str, хорошо, но + у меня как бы больше с арифметической операцией ассоциируется, но это уже мои личные интимные проблемы :-D

> гыгы - ну что кто набросает список требований которые нужно учесть для складывания строк на сях? ;)

дабы не ипать моск, use glib2 ;)

> D?:)

+1!

всё хочу засесть за изучение :)

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

тут проблемы нет, char != буква, а выделяется память не для буквы, а для блока, куда что хошь пиши, т.е. буквока у тебя 2 байта занимает, вот под неё два байтика и нужно выделить, другое дело что не логично: strlen, вроде как длинна строки в СИМВОЛАХ, а не в байтах. но для уникода соответственно юзать всякие u_strlen и другие подходящие инструменты, коих написано немало.

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

мой вариант:

cat > string.c << _EOF_
#include <stdio.h>
#include <glib.h>

int main()
{
   gchar *message = g_strconcat("Проверка", ", ", "Проверка!", NULL);
   printf("%s\n", message);
   free(message);
   return 0;
}
_EOF_

gcc -o string `pkg-config --cflags --libs glib-2.0` string.c

ЗЫ терминал у меня UTF8

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

а глиб нету под разные платформы? :) тем паче что glib на си и написан, так что вполне можно позволить скомпилять где угодно где есть си компилер.

А также были с тетрадной адресацией. И полностью безадресные. 1-4 стековые тег-базированные. И причудливые гибриды вышеназванного. CDC и Burroughs в своё время зажигали 8). Кое что юзается и по сей день.

Собственно мне интересно, что запело бы поколение пепси по поводу байта на теговой архитектуре, где размер адресуемого поля колебался от 1 до 64к бит и интерпретировался весьма хитроумными комбинациями флажков? :)

не верю результатам тестов , субъективно c\gtk быстрее того же блокнота написанного на java , причем если смотреть на вещи вроде Eclipse(кстати Netbeans быстрее и меньше рамы ест) и VC , то VC всеравно быстрее.

Кому 4.2 , а это лично мое мнение.

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

Откуда же вы такие берётесь-то? :D Даже в упомянутом tasm'е, например, неужели работа с объектами 1:1 отображается? А во что отображаются макросы? :D

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

В мире что, много проектов, типа ядра? :D Вопрос же о массовости, а не о нишевых решениях.

>Только никто из работающих на них не называет тамошние адресуемые единицы "байтами" - только "словами'.

Если ширину данных можно разбить на целое число байт и к этим байтам можно адресоваться, то традиционно, таки да, зовут эту величину словом.

Но что делать с машинами, где ширина шины данных 9 бит, скажем? Или что делать с самым первым оригинальным определением байта на IBM7030, где оно было равно 6 битам? :D

Вообще, нечастый случай, когда по спорному вопросу в Вики достаточно детально определено: http://ru.wikipedia.org/wiki/Байт

Макросы далеко не обязательный аттрибут ассемблеров. Расширения зачастую бывают самые причудливые. А парадигма 1:1 отображения принципиально верна.

>> Можно пример ситуации, когда байт имеет смысл без адресации?

> Байт состояния аппаратуры.

А читаться он будет через libastral? :) Или, всё же, через адресное пространство памяти или портов?

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

Байт - по своему происхождению и по логике счётная единица и поэтому обязан адресоваться.

>что работает быстрее - Linux или Eclipse?

Что работает быстрее, трактор или тракторист? :D

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

Точно также, как на Си можно писать, использую машкод в виде бинарных данных. Всякая селёдка - рыба, но не каждая рыба - селёдка. На ассемблере можно написать также быстро, как на машкоде, но это не значит, что любая программа на ассемблере будет столь же быстра, как программа на машкоде.

...

Собственно, походу, серьёзно на асссемблере никто из приравнивающих его машкоду не писал :D