C vs. JVM's benchmark

btw, "обернуть матрицу размером 10^6 x 10^6 " -
отличный тест для сравнения производительности языков.
Хотя, подозреваю, что победит fortran :) :(

>Хотя вот стоит задачка - обернуть матрицу размером 10^6 x 10^6 на 8и-корном проце (еще лучше на GPUах). Где Ваши erlangи и Java?

По задаче инструмент. Эрланг не для числодробления придуман, и честно говоря не думаю что хорошо справится там, где уже есть готовые lapackи. Язык этот был придуман в недрах Эриксона для массового паралеллизма софта телефонных станций. Очень хорошо с этий задачей справился. Первая станция с ним была супрнадежна и простой был АФАИК уровня нескольких секунд в год. Поддерживает создание удаленных процессов которые суть функции, горячую замену кода, стоимость создания процесса сравнима со стоимостью вызова функции.

>незачот! во-первых - это apache модуль, написанный на C НезачОт тебе. Иди кури доки.

> Различия фундаментальные. Начиная от ключевых слов,

Тоже мне, "фундаментальные"

> заканчивая объектной моделью

И что там "фундаментального"? Так, мелочи.

> и исполнением в виртуальной машине.

Есть минимум одна реализация в виде генератора "родного" кода.

>незачот! во-первых - это apache модуль, написанный на C

НезачОт тебе. Иди кури доки.
Tomcat изначально создавался как standalone, только потом стали его пихать в Apache или JBoss.

> незачот! во-первых - это apache модуль, написанный на C

OMG! А мужики-то не знают...

> Тут уже не помочь! man 3 strcat.

The strings may not overlap, and the dest string must have enough space for the result.

>Теперь на java пишут в основном из-за _реализованных_ под неё механизмов сборки мусора и работы с сетевым протоколом.

Честно говоря с сетью и в сях проблем нет, как и с многопоточностью, а вот сборщик мусора ИМХО не нужен и я бы сказал - даже вреден. Программист перестает понимать жизненный цикл объекта, это приводит к совершению концептуальных ошибок в проектировании. Конечно gc все вовремя подчистит и ошибки проектирования будут приводить не к зависаниям, сегфолтам и утечкам памяти а лишь к тормозам при работе и повышенным системным требованиям. Что на это скажет менеджер проекта многие и сами уже знают - главное оно работает, на улучшения времени нет. Такой подход позволяет нанимать дешевую, мало квалифицированную рабочую силу и получать работающий результат. Наверное поэтому по тестам жава не тормозит, но результаты в виде реальных проектов это утверждение постоянно опровергают.

Вы ошиьаетесь Tomcat, написан на java и без нее не запускается, и отлично кстати работает без web сервера apache. Большинство проектов apache написаны на java, а не на С. Зайдите на их сайт и убедитесь

>Тоже мне, "фундаментальные"

Согласен - это мелочи.

>И что там "фундаментального"? Так, мелочи.

Одинарное наследование. Офигеть мелочь-то какая. Ну давай перепиши проект c С++ в котором есть лес классов на Java.

>Есть минимум одна реализация в виде генератора "родного" кода.

Это ты про поделие GCJ, которое даже 1.4-то целиком не поддерживает? Айс!

> Иди кури доки.
курить доки - это для лохов. настоящие пацаны должны курить сорцы :)
когда-нибудь изучал сорцы Tomcata? я - да (так же как сорцы zend/php),
правда достаточно давно ~2002 года

> стоимость создания процесса сравнима со стоимостью вызова функции.

А может наоборот - стоимость вызова функции сравнима со стоимостью создания процесса? :P

> достаточно давно ~2002 года

мда, старею. tomcat - это "оказывается" не модуль, а сервлет (!)
что суть дела не меняет - висит-то он на апаче, который написан на C

>tomcat - это "оказывается" не модуль, а сервлет (!) что суть дела не меняет - висит-то он на апаче, который написан на C

Вообще-то Томкат-это автономное приложение на Жаве. Есть еще Jetty.

> Одинарное наследование. Офигеть мелочь-то какая.

Ага.

> Ну давай перепиши проект c С++ в котором есть лес классов на Java.

Думаю, "лес классов" (имелась в виду сеть классов, да?) - это наименьшая проблема :D И почему именно Си++ -> Java, а не наоборот?

>> Есть минимум одна реализация в виде генератора "родного" кода.

> Это ты про поделие GCJ, которое даже 1.4-то целиком не поддерживает? Айс!

Какая ерунда - не поддерживает 1.4. Ява была Явой и в версии 1.0, было бы что-то "фундаментально отличное" - не было бы GCJ вообще. А так - просто денег не вложили, поэтому нет 1.4.

>незачот! во-первых - это apache модуль, написанный на C

Ты идиот. Не можешь даже в Гугл набрать "Apache Tomcat", чтобы обнаружить, что ты не прав.

PS: в Apache есть модуль для _подключения_ Tomcat'а.

Вам же по русски говорят, что не написан он на С. Апач ему нафиг не нужен, хотя можно сконфигурировать их в связку, тогда апач будет статику выдавать.

>когда-нибудь изучал сорцы Tomcata? я - да (так же как сорцы zend/php),

Я контрибьютор в Tomcat'е. А вот ты его даже в руках не держал.

> Вообще-то Томкат-это автономное приложение на Жаве. Есть еще Jetty.
http://svn.apache.org/repos/asf/tomcat/connectors/trunk/jk/native/apache-2.0/...
"Apache 2 plugin for Tomcat" - что есть aka apache-module
вся основная нагрузке лежит здесь.
Остальные java-довески - это "performance non-critical" функциональные части. Курите сорцы!

tomcat - это сервлет контейнер.

Не путайте слово Apache - и httpd Apache server

На С для tomcata таки есть The Apache Tomcat Native library

>мда, старею. tomcat - это "оказывается" не модуль, а сервлет (!)

Точно. Уже в маразм впал.

"Сервлет" - это (грубо говоря) приложение выполняющееся _В_ tomcat'е. Сам Tomcat - это _контейнер_ сервлетов.

Ещё раз для маразматиков: Tomcat - это контейнер, который занимается запуском сервлетов. Примерно как Apache является контейнером для CGI.

>что суть дела не меняет - висит-то он на апаче, который написан на C

Ещё раз для маразматиков: Tomcat _ПРЕКРАСНО_ работает автономно без всякого Apache. Скачай и запусти, чтобы убедиться. Какие проблемы-то?

Например, у меня работает ферма Tomcat'ов с nginx'ом перед ними для load ballancing'а.

Жесть. Вам сколько говорят, а все за свое.

> Я контрибьютор в Tomcat'е
я понимаю, что поправить какой-нибудь java-klass на Tomcatе -
это не означает поправить его apache-moduleную часть,
о существовании которой Вы, похоже даже не подозревали.

>"Apache 2 plugin for Tomcat" - что есть aka apache-module

Ещё раз медленно для тупых. mod_jk - это просто способ ПОДКЛЮЧЕНИЯ к Apache. Посмотри сам в исходник. Причём это далеко не единственный коннектор - по твоей же ссылке смотри в http://svn.apache.org/repos/asf/tomcat/connectors/trunk/

Коннекторы нужны, чтобы подключить приложение к уже существующему серверу. Например, чтобы поддерево /myapp перенаправлялось Tomcat'у, а всё остальное отдавалось CMSкой на PHP.

Один из самых распространенных багов в 6 жабе на который наткнулись как только она вышла:

http://bugs.sun.com/bugdatabase/view_bug.do;?bug_id=6434149

Возможно из-за него не получилось запустить вашу программку.

Пол страницы ему уже твердим, пусть считает как захочет.

> Tomcat _ПРЕКРАСНО_ работает автономно без всякого Apache

все все прекрасно понимают - Ваше высказывание аналогично тому,что
PHP "_ПРЕКРАСНО_ работает автономно без всякого Apache", ну и что?

Мы, изначально говорили о производительности C vs Java и в какой-то момент
прозвучало утверждение, что "Tomcat - что эо вебсервер написанный
на Java"

>я понимаю, что поправить какой-нибудь java-klass на Tomcatе -

А как насчёт "добавить систему кластерной репликации сессий"?

>это не означает поправить его apache-moduleную часть, >о существовании которой Вы, похоже даже не подозревали.

Я прекрасно знаю про коннекторы. Я так же прекрасно знаю про внутренности Apache - я когда-то немного участвовал в разработке SVN (когда оно ещё было версии 0.24, ахх...) и долго мучался с mod_svn.

У меня и по сей день используется пропатченный для LDAP-авторизации mod_authz_svn.

А как ты думаешь, зачем в юниксе придумали IPC? А веб-морду написать на перле или ruby, используя готовый фреймфорк - дело на полдня.

закругляемся господа, караул устал ... пора и по-работать :)

>Поучительный пример из жизни говорящий о (не)умении выбирать инструменты. На работе есть тупой старый сишник. Он даже С++ не собирается смотреть, ибо не Ъ. Ведь Ъ - это любимый "быстрый" С. Так вот этот чудак на букву М написал сервер кеширования геолокаций в любимом суперязыке - С. Долго писал, упорно. И в итоге сделал все "как надо" - никаких левых библиотек, все на указателях. В итоге это жрало память аки пылесос и медленно работало. Пришел вчерашний студент, переписал все с использованием хештаблиц. Теперь сервант держит нагрузку в 10 раз большую с меньшим временем отклика.

Тоесть Вы туверждаете, что на Ц без применения сторонних библиотек невозможно реализовать хэш-таблицу? Или иначе к чему эта история о чуваке которые не шарил в алгоритмах и структурах данных? Как это вообще с Ц связано?

>все все прекрасно понимают - Ваше высказывание аналогично тому,что >PHP "_ПРЕКРАСНО_ работает автономно без всякого Apache", ну и что?

PHP - это вообще язык. Точно так же и С не может работать web-сервером.

>Мы, изначально говорили о производительности C vs Java и в какой-то момент >прозвучало утверждение, что "Tomcat - что эо вебсервер написанный на Java"

Да. Это абсолютно правильно. Tomcat - это полноценный web-сервер, который может отдавать статический контент.

Ещё раз: скачай Tomcat и запусти его. Пока ты показываешь полное незнание предмета.

>Или запущу самописный GC. И вообще это моё дело.

Не флейма ради: а что этот ГЦ в С-коде должен делать? По идее он должен утилизировать участки памяти на которые больше не указывает ни один поинтер. В С это мемори лик и в правельно написаной программе такого быть не должно вроде как.

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

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

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

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

C в большинстве задач не нужен так как многократно увеличивает стоимость продукта и понижает читаемость кода (см. выше пример со строками на pure C).

что касается Java и прочего - и на Java можно делать отличный софт. важен не язык а откуда руки ростут и что в голове находится. просто быдлокодерам из средней азии C вообще не осилить.

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

Прикольно, у меня eject, который использует glib2, материться на какую-то кривую строку в файле темы:

>eject
/home/sergey/.themes/marble-look/gtk-2.0/gtkrc:49: Clearlooks configuration option "sunkenmenu" is not supported and will be ignored.

>ldd /usr/bin/eject
linux-gate.so.1 => (0xb801e000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00cff000)
libc.so.6 => /lib/libc.so.6 (0x00b13000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00ccb000)
/lib/ld-linux.so.2 (0x00aef000)
libdl.so.2 => /lib/libdl.so.2 (0x00ca9000)

glib?

[onestep@onestep-box ~]$ ldd /usr/bin/eject
linux-vdso.so.1 => (0x00007fff85ffe000)
libc.so.6 => /lib/libc.so.6 (0x00007f987d8f0000)
/lib/ld-linux-x86-64.so.2 (0x00007f987dc43000)

>> Apache Tomcat. Написан на Java. :P

> незачот! во-первых - это apache модуль, написанный на C

Написать глупость, конечно, проще и быстрее, чем сходить на http://tomcat.apache.org или в википедию заглянуть.

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

Вы думаете, что в компиляторе поддержка хеш-таблиц реализована не ручками? :) Ещё раз повторю, в glib есть очень хорошая реализация хеш-таблиц, ручками делать ничего не надо. Surprise?

> Можно и пошариться по инету в поисках сторонних библиотек или кода, кто спорит.

Можно и не шариться, т.к. glib включена в практически любой современный дистрибутив.

>> Apache Tomcat. Написан на Java. :P

> незачот! во-первых - это apache модуль, написанный на C

Нет, это Servlet Container написанный на Java :)

>Не флейма ради: а что этот ГЦ в С-коде должен делать? По идее он должен утилизировать участки памяти на которые больше не указывает ни один поинтер. В С это мемори лик и в правельно написаной программе такого быть не должно вроде как.

В Inkscape в зависимостях я узрел какой-то gc дя Си. Что это за чудо правда я пока не смотрел.

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

Ну так причем здесь Ц, если Вы сами признаете, что проблема кроется в структурах данных?

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

Нигде шариться не нужно:

http://library.gnome.org/devel/glib/stable/glib-Hash-Tables.html

http://www.gnu.org/software/libtool/manual/libc/Hash-Search-Function.html

>В Inkscape в зависимостях я узрел какой-то gc дя Си. Что это за чудо правда я пока не смотрел.

Если ГЦ работает постоянно, то все впринципе нормально. Я не понял смысла "активировать" ГЦ, когда в программе с ручным управлением памятью вдруг закончилось место на хипе.

> Не флейма ради: а что этот ГЦ в С-коде должен делать?

Освобождать неиспользуемую память. Для этого придётся ручками инкрементить-декрементить счётчики и сообщать ему, что по такой ссылке лежить память, в которой по таким то адресам записаны другие указатели. Я такого не видел, но представить могу. Или обычный консервативный GC вроде Boehm GC.

GC тоже берёт память из хипа.

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

Зачем ручками декрементить счетчики и потом "натравливать" на эти куски ГЦ, если можно просто освободить эту память с помощью фри?

>GC тоже берёт память из хипа.

Я где-то утверждал обратное? о_О

Чтобы за жизненным циклом объектов следил не программист а компьютер.

А почему тогда спрашиваешь, зачем запускать GC при нехватке памяти? Памяти не хватает, запустили GC, освободили неиспользуемую память, памяти стало хватать, работаем дальше.

> btw, "обернуть матрицу размером 10^6 x 10^6 " - > отличный тест для сравнения производительности языков. > Хотя, подозреваю, что победит fortran :) :(

при работе с матрицей проще использовать GPU, чем CPU. Производительность будет гораздо выше, т.к. GPU фактически при прорисовке видеокартой слюнявой игрушки обрабатывает матрицы ... Всякие Джавы разве могут работать с GPU ?