Groovy в 827 раз медленнее Java

Тоже самое на Monster.com USA. Zope - 17 за 3 месяца(!!!) J2EE - больше 5000!!!

> Кстати, серьезно любопытствую, много ли приложений с Session Beans (версий 2 или 3) написано
Много. Session Bean используются очень часто. Entity Beans гораздо реже. К слову о птичках,JMS и JMX тоже пользуются популярностью.

> ... и что думаешь про эту спецификацию?
Если смотреть на спецификацию относительно даты ее выхода, то она хороша. На момент их выхода (1, 2) просто не было более удобных альтернатив.

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

И не нужно забывать, что J2EE это не только ORM и сессионник.

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

> слову о птичках,JMS и JMX тоже пользуются популярностью.

Именно JMS или Message Beans?

> И не нужно забывать, что J2EE это не только ORM и сессионник.

Я в курсе, 1500-ый пдф читаю уже долго.

> Тоже самое на Monster.com USA.

Я все понял, ни JBoss ни Zope вы сами не видели, можете не продолжать, сказать вам нечего.

> Вот только не понятно, почему большинство математиков пишут программы для расчетов на фортране, и даже не задумываются учить си++ для ускорения программ?

Пользуюсь Фортраном для численных расчетов в течение 30 лет и C для системного программирования с середины 80-х годов.

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

2) Объектный стиль программирования вносит дополнительное накладные расходы в задачи, и так требующие больших ресурсов для выполнения. Численные задачи в 90% случаев носят функциональный зарактер.

3) Современный Фортран - это наполовину Алгол 68, который считается идеальным языком публикации алгоритмов. Численный алгоритм, записанный на Фортране 90, абсолютно ясен и понятен кому угодно при минимальной подготовке. Язык C - по сути дела универсальный ассемблер, и численный алгоритм на C записать в легко читаемом виде бывает чрезвычайно сложно (например, всякая хитрая матфизика).

Являюсь программистом в крупнейшем на юге России медицинском центре. Параметры системы: J2EE, Oracle, клиентские места Java (Swing), 150 рабочих мест. Знаю программистов, которые разрабатывали систему АЦК для казначейств. Региональный сервер J2EE: Oracle, в регионе до 500 удаленных клиентов на Delphi.

> Параметры системы: J2EE, Oracle

Здесь Оракле - это СУБД (или у них есть AS)? А J2EE - совокупность спецификаций от servlets/JSP до Message Beans, в целом ничего не говорящая. А назвать это "параметрами системы" вообще страновато ;)

Да у Oracle чего только нет :) OAS. В данном конкретном случае OC4J, наверно.

У нас порядка 100 Entity beans, данные хранятся на Oracle.

Был у меня еще друг, тоже Zope пытался освоить. Быстро бросил. Перешел на Ява. Быстро нашел работу.

Статья глупая. Возможно её начтоящей целью является реклама маргинального языка Scala. Соотношение 827:1 вовсе не тивично, а может быть и существует для специально подобранного примера. Кроме того, скорость работы одной и той же программы на Groovy существенно зависит от того, является ли она предварительно скомпилированной (тогда быстрее) или загружается из исходного файла и при этом компилируется (тогда медленнее). Кроме того, Groovy вовсе не предназначен для замены Java, это скорее дополнение к Java (добавляет скриптовые возможности). Если же использовать отдельно от Java, то сравнивать не с Java, а с Ruby итп. Ограничиваюсь комментарием к статье. Комментировать глупую дискуссию с бессмысленными нападками на Java и восхвалением Python и подобным было бы слишком утомительно.

http://www.forthgo.com/blog/java-vs-c-vs-c-at-finding-primes/

http://www.ddj.com/java/184401976?pgno=1

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Друк, ты ебанулся головой дюже крепко. Ваша ВизуалСПП может быть процентов на 15-20 быстрее gcc. И если учесть просто охуенную переносимость ВС++ который работает на всех платформах если это х86 и на всех ОС если это винда, то ну его на йух, твой вс++. Интеловский компилер по скорости вс++ не уступает, а работает и под линуксом тоже. Да и 0.2 путнка самая большая разница, а в среднем наверноео и 0.1 нигкого не ипут под линуксом, потому что нисмотря на это, приложения под линуксом один хер быстрее работают, чем под вашим быдлоподелием. Т.е. даже с этим преимуществом в 20%, ваше поделие всё равно умудряетс яработать медленнее и находиться в полной жёпе.

>Ваша ВизуалСПП может быть процентов на 15-20 быстрее gcc

Это вряд ли, если только в винде.

> Возможно её начтоящей целью является реклама маргинального языка Scala.

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

> Был у меня еще друг, тоже Zope пытался освоить. Быстро бросил. Перешел на Ява. Быстро нашел работу.

Если цель заключается в нахождении работы, кто бы спорил? Однако занятно, что это все что могу сказать явисты об Zope.

> Кроме того, скорость работы одной и той же программы на Groovy существенно зависит от того, является ли она предварительно скомпилированной (тогда быстрее) или загружается из исходного файла и при этом компилируется (тогда медленнее).

Для данного примера скорость компиляции составляет десяток секунд от силы. Что касается скорости работы - ну сделайте свои примеры, я поковырялся с сурсами и понял, что для сриптов груви голится, а как язык общего назначения рассматhивать его не прихзодится, и не только из скорости :(

Это к чему?

Первый нах. Второй нах. По всем тестам ВС++ превосходит GCC, а с icc одна проблема - это говно выдает иногда неправильный код. И вообще на фиг мне усрался этот icc. A GCC не кроссплатформенна твою мать. МинГовно это не GCC.

http://www.ddj.com/java/184401976?pgno=10 Мдя, результаты у Mono просто выдающиеся, чего и следовало ожидать. Как впрочем и у его хозяйчика aka прародителя .NET 2.0. Тут http://www.ddj.com/java/184401976?pgno=11 аналогичная картина.

Зато как IBM Java уделала Intelовские компиляторы, любо дорого смотреть :)) Но Sun Java 6.0 уделала бы и ее, вот бы сейчас эти тесты http://www.tommti-systems.com/mainDateien/reviews/languages/bench.zip прогнать

> Кстати, серьезно любопытствую, много ли приложений с Session Beans (версий 2 или 3) написано, и что думаешь про эту спецификацию?

Достаточно серьёзно из j2ee пока знаком лишь с servlets, applets, jdbc. Всё остальное лишь на уровне теории или в виде практических упражнений. Не сказал бы что технология очень мне нравится (имхо сложновато в плане развертывания), но в enterprise-секторе очень и очень важным может оказаться фактор поразительной масштабируемости и гибкости j2ee.

Тем не менее, если есть средства в других средах, которые делают всё то же, и лучше, то почему бы и нет? Биться головой об стену с криками "Долой %ваш_язык%!" я не буду :)

> A GCC не кроссплатформенна твою мать.

Хорошо пошутил :-).

> МинГовно это не GCC.

А CygWin?

Лучше, конечно, отокмпилировать *.groovy в *.class - тогда получиться обычный java-байткод!

> Лучше, конечно, отокмпилировать *.groovy в *.class - тогда получиться обычный java-байткод!

Вряд ли поможет - я думаю там dynamic dispatch поверх жабы реализован.

>PS Нафига на JVM генерить фракталы, мне кто-нибудь объяснит?

Шоб былО!

> динамическая типизация гораздо хуже по производительности

Естественно. Кульхацкеры-"кулибины", изобретатели велосипедов из руды, опять обломались. :))

Статьи по ссылке не читаем? Там как раз это и называется причиной падения скорости на 3 порядка