> А например удобнее JDBC, как _унифицированного_ интерфейса доступа к БД, пока ничего нет....

Эй, студентик, DBI видел?

DBI, конечно, хорош... Но это Перл, следовательно, наследует все его недостатки. JDBC в этом плане более красиво сделан. Но исключительно по причине достоинств типизированного языка и наличия нормального механизма исключений. Кстати, питоновское двигло для баз данных хорошо. :)

Я не понимаю, чем кому-то может мешать наличие типизации. Мне кажется, что строгая типизация позволяет вынести отладку части ошибок из runtime во время компиляции. А вот отсутствие типизации ведет зачастую к труднообнаруживаемым ошибкам. ИМХО.

Я не понимаю, неужели до сих пор встречаются люди, которые считают, что Java - самый тормозной язык? :) Если да, то какие тесты это подтверждают? Только, пожалуйста, не демонстрируйте тормозящие апплетики, написанные неизвестными студентами. :)

Прикинь, да...... А можно аргументировать, чем он удобнее..... Пардон, вашего социального статуса не знаю.

begin

dbh = DBI.connect("dbi:ODBC:PostgreSQL30")

rescue DBI::DatabaseError => e

puts "An error occurred"

puts "Error code: #{e.err}"

puts "Error message: #{e.errstr}"

ensure

dbh.disconnect if dbh

DBI - это не только перл.

Это тоже DBI, ruby под виндовс.

>Я не понимаю, чем кому-то может мешать наличие типизации.

var1=(sometype)var2;

>Мне кажется, что строгая типизация позволяет вынести отладку части ошибок из runtime во время компиляции

см. ocaml.

>Я не понимаю, неужели до сих пор встречаются люди, которые считают, что Java - самый тормозной язык? :) Если да, то какие тесты это подтверждают?

tomcat на Pentium'е.

>>Я не понимаю, чем кому-то может мешать наличие типизации. > var1=(sometype)var2;

И? Чем плохо? В случае отсутствия типизации я могу случайно в коде сделать ошибку и приравнять переменной, которая должна содержать один тип, другой тип. В данной конструкции это случайно уже не сделать. :)

>>Я не понимаю, неужели до сих пор встречаются люди, которые считают, что Java - самый тормозной язык? :) Если да, то какие тесты это подтверждают? >tomcat на Pentium'е.

То есть, найдя тормозящую программу, делаем вывод, что сам язык тормозной? :D Можно тогда привестьи пример "нетормозного" языка? Я уверен, что смогу найти программу, которая написана на нем, и будет тормозить. :)

>Я не понимаю, неужели до сих пор встречаются люди, которые считают, что Java - самый тормозной язык? :) Если да, то какие тесты это подтверждают?

более того IntelliJ IDEA вроде правильно написал.

не все так просто
иногда кажется что у ++ "более сильная" типизация
приблизительно такая конструкция
Int x;
UhhTiType y;
Object z;
z = x;
y = (UhhTiType)z;

ошибка только во время исполнения
и вообще, если бы в ++ какая бы организация
угрохала такое же количество средств на создание
приличной нестандартной библиотеки, применимость java
была бы под вопросом, просто - полуинтерпретируемый ОО язык
со связыванием во время компиляции и с общим предком

>Я не понимаю, неужели до сих пор встречаются люди, которые считают, что Java - самый тормозной язык? :) Если да, то какие тесты это подтверждают?

более того IntelliJ IDEA вроде правильно написал.

>>>Я не понимаю, чем кому-то может мешать наличие типизации. >>var1=(sometype)var2; >И? Чем плохо?

Тем, что это уродство _необходимо_. См. Enumeration.nextElement().

>>>Я не понимаю, неужели до сих пор встречаются люди, которые считают, что Java - самый тормозной язык? :) Если да, то какие тесты это подтверждают? >>tomcat на Pentium'е. >То есть, найдя тормозящую программу,

просто взяв первую прешедшую мне на ум _реальную_ программу. А вообще примеров могу накидать массу. И ни одного (из реальной жизни) обратного.

> делаем вывод, что сам язык тормозной? Тормозная в данном случае строго говоря испольнительная система, а не язык. И она _обязан_ быть тормозным в силу предъявляемых к ней требований (про JIT Трындеть не надо - он тут не причём).

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

>>>Я не понимаю, чем кому-то может мешать наличие типизации.

>>var1=(sometype)var2; >И? Чем плохо?

>Тем, что это уродство _необходимо_. См. Enumeration.nextElement().

Это "уродство" улучшает читабельность кода и избавляет от возможности неправильных присваиваний. Enumeration, Iterator и Vector - это уродства, которые надо было хоронить с самого начала, так как они являются одними из сильных источников run-time ошибок, которые бы при наличии проверки на тип отлавливались бы еще во время компиляции.

>>>Я не понимаю, неужели до сих пор встречаются люди, которые считают, что Java - самый тормозной язык? :) Если да, то какие тесты это подтверждают?

>>tomcat на Pentium'е. >То есть, найдя тормозящую программу,

>просто взяв первую прешедшую мне на ум _реальную_ программу. А вообще примеров могу накидать массу. И ни одного (из реальной жизни) обратного.

Пожалуйста, хотя бы десяток :)

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

>> делаем вывод, что сам язык тормозной?

> Тормозная в данном случае строго говоря испольнительная система, а не язык. И она _обязан_ быть тормозным в силу предъявляемых к ней требований (про JIT Трындеть не надо - он тут не причём).

Я так понимаю, вообще голое теоретизирование. Java томозная, потому что _обязана_ быть тормозной. Железный аргумент, даже как-то оспорить сложно.

И как это JIT тут не при чем?

> Отсда одна из _главных_ претензий к жабе - он пытается усидеть на двух стульях - быть эффективной и на стадии разработки и на стадии выполнения. Что взаимно противоречит друг другу.

Почему это? Опять теория? Можно аргументацию, почему?

Ява действительно на многих (не на всех) задачах проигрывает по производительности таким языкам, как С, С++. Но из личного опыта могу сказать, что при достижении программой определенного уровня сложности, С и (в меньшей степени)С++ начинают отставать от явы, потому что становится все сложнее и сложнее писать правильный код и грамотно стыковать куски друг с другом (т.е. возникают сложности с разработкой архитектуры системы). К тому же резко увеличивается сложность поддержки системы (в смысле удаления багов и доработки).

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

С этим трудно не согласиться. Но мне приходилось долгое время работать с IBM DB2. В поставку DB2 входит "Центр управления" и "Командный центр". Раньше, когда была версия 5.2 эти программы были написаны на Си(возможно C++). Тормозов не было даже на 2-х пнях с 64 метрами мозгов. Клиенты работали под NT 4.0. Далее с появлением DB2 7.0 в IBM ,с целью обеспечения кроссплатформенности, переписали все на Java. Пользоваться этим стало возможно только на машинах с 256М памяти. Загрузка "Центра управления" занимала секунд 10-15. Памяти выжиралось до 96М-128М. Написано все с использованием SWING-а. Закрытие программы занимает иногда до 20 сек. Меня в работе это сильно раздражало. С появлением версии DB2 v 8 вообще пришлось отказаться от графических приблуд и перейти на использование командной строки. Даже на последних пнях тормоза и расход памяти возросли просто до неприличия. Конечно можно предположить, что в IBM просто не умеют писать на Java. Но IBM сама активно продвигала Java и в это трудно поверить. Что касается количества зависаний и "глюков" - при использовании Java их стало больше, а последствия их вообще не предсказуемы.

P.S. Окончательный вывод делать не буду. Мои слова только стимул к размышлению

>> DBI, конечно, хорош... Но это Перл, следовательно, наследует все его недостатки.

ну блин ваще... какие у перла могут быть недостатки?!! одни сплошные достоинства! :))

> ну блин ваще... какие у перла могут быть недостатки?!! одни сплошные достоинства! :))

Причем торчащие из самых неожиданных мест. :D

"Но это Перл, следовательно, наследует все его недостатки"

Сам ты с недостатками, перл форева!!!

p.s. привет всем из солнечного Крыма, город Феодосия, вода в море +25

> P.S. Окончательный вывод делать не буду. Мои слова только стимул к размышлению

Сделай, плиз, один вывод - лишние 256 метров памяти стоят меньше чем 100 баксов, т.е. примерно один день работы нормального программиста. если ты используешь систему за $10k поставь себе что-нибудь поприличнее целки 300-мегагерцовой с четвертухой памяти.

Могу сказать следующее - не то чтобы быстро, но на моём ноуте (Pentium-M 1.6, 1G памяти) не замечал особых тормозов ни в тугезере, ни в эклипсе, ни в идее, томкат с jbossом и postgresом живут постоянно. При этом загрузка процессора редко когда больше 3-х секунд держится на 100% при полном тротлинге проца.

И кстати, ещё в 95-ом году, когда я увидел первую жабу, чел, который её показывал сказал - проц тебе мощный не особо нужен. Но памятю запасись. Уже восем лет прошло, а память всё дешевеет и дешевеет, и обратной тенденции не вижу (+- $10 - не в счёт). И если вдруг обнаружится, что ноут начал тормозить - поменяю две планки по 512 на две по 1024, и тормоза уйдут, уверен. Просто не надо смотреть на софт, написанный студентами в качестве курсовых, а надо смотреть на профессиональную работу, например:

Валентин Кипятков - IntelliJ Idea - не тормозит

Эрих Гамма - Eclipse - не тормозит

Про остальных разработчиков сказать по именам не могу, но тем не менее мало что ХОРОШО написанное на любом языке программирования тормозит так, что за 100-200 баксов нельзя от тормозов избавиться.

Спасибо за внимание, да, кстати, за вынимание тоже спасибо.

>И если вдруг обнаружится, что ноут начал тормозить - поменяю две планки >по 512 на две по 1024, и тормоза уйдут

ИМХО

Это не спортивно, какой же ты после этого хакир?

2daebear * (*) (25.08.2004 17:21:15)

>Спасибо за внимание, да, кстати, за вынимание тоже спасибо.

Золотые слова. А че хацкеры на бысике не пишут? Че им жаба то не угодила? Их че кто-то принуждает? Как в анекдоте: ... знаешь как нас пиздят!

Ето точно ;)

Настоящие хакиры покупают пару видюшек с тяпистами метрами памяти на борту и делают вот так вот http://kerneltrap.org/node/view/143 ;)))

> Using Video RAM as System RAM

а потом в этой памяти заводят своп

> Сделай, плиз, один вывод - лишние 256 метров памяти стоят меньше чем > 100 баксов, т.е. примерно один день работы нормального программиста. > если ты используешь систему за $10k поставь себе что-нибудь > поприличнее целки 300-мегагерцовой с четвертухой памяти.

Возможно. Понятно, что тормоза с добавлением памяти могут и пройти. И на глаз их видно не будет. Но, машин может быть много, а не только один ноут. И потом, нагрузка бывает разной и количество программ использующих жабу может быть не 10, а 100. По любому лучше выбрать программу работающую быстро на любом железе, чем ту которой требуется для работы ~ 1 Гиг. Далее, устройства бывают разные. Есть, например наладонники с 64М, - это максимум. И задачи бывают критичные ко времени. Ведь проблемы жабы не кончаются тормозами. Есть еще непредсказуемость. Никогда не знаешь, например, когда JVM запустит сбор мусора. Надо выполнить критичную ко времени операцию, а фиг там выполнение программы приостановлено. То есть применение жабы ограничено и нет у нее объективных преимуществ. А повсеместное использование жабы - следствие агрессивной рекламы.

>>>var1=(sometype)var2; >И? Чем плохо?

>>Тем, что это уродство _необходимо_. См. Enumeration.nextElement().

>Это "уродство" улучшает читабельность кода

ха-ха-ха!

>и избавляет от возможности неправильных присваиваний.

Как это? Оно наоборот позволяет. Что угодно присвоить чему угодно.До самого ран-тайма. Ещё раз отсылаю к окамлу, который умеет без всякого гемороя вычислять типы во время компиляции и generic'и во всяких лиспах, которые умеют и в ран-тайме находить правильные решения.

>Enumeration, Iterator и Vector - это уродства, которые надо было хоронить с самого начала, так как они являются одними из сильных источников run-time ошибок

Я не вижу как, оставаясь в рамках синтаксиса Java'ы (до 1.5) можно от них избавится. Это следствия изначальной непродуманности языка.Что особенно обидно из-за того, что на момент её создания, альтернативы уже существовали лет десять.Более того-насколько я плохо информирован один из идеологов Java'ы - пришёл в Sun из Symbolics'а.

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

А и не надо спорить. Надо думать.Вначале. Жабная программа (в откомпилированном виде - поэтому JIT уже не играет никакой роли) тащит кучу накладных расходов - RTTI, косвенные вызовы, boxed типы, ексепшены,сборка мусора (и вызванный ей своп)... короче если когда нибудь пробывал писать на С в "ОО-стиле" /точнее сказать в страуструповой интерпретации ОО-стиля/ все эти грабли очевидны. Строго говоря, отвратительно написанная С++ программа страдает этими же проблемами, но там даже полный чайник(как раз потому, что чайник) не сможет _всю_ программу завернуть в такую кучу мусора.

>> Отсда одна из _главных_ претензий к жабе - он пытается усидеть на двух стульях - быть эффективной и на стадии разработки и на стадии выполнения. Что взаимно противоречит друг другу.

>Почему это? Опять теория? Можно аргументацию, почему?

Примерно потому же. Все перечисленные выше накладные расходы облегчают программирование но ложатся тяжёлым грузом на выполнение.Простой и эффектный выход предлагали поочередно Остерхут (автор tcl), Столлман и Билл Гейтс - использование двух языков на разных уровнях. Java и C++ - языки ублюдки, пытающиеся угодить всем. Как и все ублюдки (дворняжки) они унаследовали все худшие черты от обоих предков (с несколько натянутой, но точной аналогией, это Fortran и Lisp) и не приобрели лучших. Ни тот ни другой не получили мощности Lisp'а ни эффективности процедурных языков, ни идеологической стройности Smalltalk'а.

К чести Sun'а надо признать, что они не афиширут, но судя по тенденции (J2EE) вполне это всё это осознают... И мне нравится то куда они двигаются.Но не нравится,что медленно :)

>Быстрота работы Java, как и любого другого языка в первую очередь зависит от рук программиста

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

>Пожалуйста, хотя бы десяток :)

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

Более того... Когда я вижу Java Application Server, NetBean и Eclipse в вариантах отдельно для виндовза и для (о ужас!) разных юниксов, у меня рождаются весьма несмутные сомнения в том, что даже Sun/IBM так уж уверены в эффективности соих рантаймов.

>Сделай, плиз, один вывод - лишние 256 метров памяти стоят меньше чем 100 баксов

А теперь умножь на тыщу рабочих мест.

To All :

И еще, все обсуждаемые жаба-программы фактически не занимаются серьезной обработкой данных, такой как компиляция или сортирока(поиск) больших объемов данных. А вот, что бы произошло, если бы скажем gcc или движок Oracle переписали на жабе, трудно даже и представить. Я думаю, что 100 баксами на 256М памяти здесь не обойтись. Вам еще здорово повезло, что не все программы на жабе написаны.

> Это не спортивно, какой же ты после этого хакир?

Точно, это как допинг в спорте.

Чего зря говорить? Вы ведь не знаете сколько(точную цифру) такая разработка будет стоить если делать не на java (с сохранением портабельности). Может цена разработки на каком-нить C++ будет на $200 больше. Тогда эту сумму надо будет умножить на кол-во рабочих мест. Сдается мне, что половина писунов тут вообще не в курсе бюджетов подобных проектов. Надо не один фактор учитывать, а много. Подготовка персонала тоже денег стоит. Чтобы кто-то oCaml выучил тоже бабки нужны. Не менять же разработчиков под каждый проект? Это дороже выйдет.

Балаболы

переливать с пустого в порожнее тоже не круто.

предисловие. Бородатый анек.

Шерлок и Ватсон бродят по набережной Темзы.
В. Шерлок, а как вы думаете, тут есть раки ?
Ш. Ватсон, RACи водятся там, где есть бабки.


J2EE промышленый стандарт. Еще какие то коментариии нужны?.

Господину размышляюшему насчет 1000 рабочих мест.
И какое это имеет значение для сервера?? или ваша организация настолько крута, чтоб использовать ресурсы клиентских писюков в распределенных вычислениях ?


P.S. Желаюшим плыть против течения и мимо денег - удачного плаванья.

>Вам еще здорово повезло, что не все программы на жабе написаны.

Чудак человек! У жабы своя ниша, где ей особой конкуренции в данный момен нет. Вот .NET потихоньку начинает вылезать, но поезд уже ушел. Догнать нереально. И дело не в агрессивной рекламе, а в возможности РЕАЛЬНО за РЕАЛЬНОЕ время создать довольно сложную КИС. И что характерно, то то что один раз сделано, работает почти на любой платформе без каких-либо изменений. Я свою КИС разверну хоть на линуксе, хоть на виндах, хоть на маке минут за 30 с нуля. И даже тестировть не подумаю.

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

ГУИ это тож не очень ниша жабы. Просто гуи можно сделать, ели надо. И грамотно написанные гуи вовсе не тормозят.

А если сравнить числодробилки, то жаба приплюснутым проиграет не более 3 процентов. А может и выиграет. Зависит от множества факторов.

Кстати, компилятор на жабе напсать, да как два байта переслать. Работа со строками там довольно шустрая. А вот надо GCC на жабу переперать? Зачем? Для компиляторов С есть.

И такие монстры IT бизнеса как IBM, Oracle не от нехер делать развивают JAVA технологии. Видимо чтот то есть, что от тебя ускользнуло.

Может ты просто чего-то не понимаешь? Или тебе просто не нравится и все, и слушать ни чего не хочешь. Мне вот тоже перл не нравится. Но у него есть своя ниша, и в нее влезть с жабой, например, очень непросто.

2ifconfig

>P.S. Желаюшим плыть против течения и мимо денег - удачного плаванья.

Респект!

>А если сравнить числодробилки, то жаба приплюснутым проиграет не более 3 процентов. А может и выиграет. Зависит от множества факторов.

Пару нулей забыл ;)

PS: Помнится на http://www.cfd-online.com один перец тоже выступал на эту тему. (про Java в CFD)

Его корифеи мягко (все ж там не LOR ;)) на место поставили ;)

>>Сделай, плиз, один вывод - лишние 256 метров памяти стоят меньше чем 100 баксов

> А теперь умножь на тыщу рабочих мест.

Запросто. Только ты сравни с ценой одного Oracle Enterprise

> но на моём ноуте (Pentium-M 1.6, 1G памяти) не замечал особых тормозов

На твоём не самом слабом ноуте, который ничем более не занят, на одной
копии программы... Это что показатель? Смешно читать такое.

> При этом загрузка процессора редко когда больше 3-х секунд держится на 100%

Ух, как здорово. А если добавить второго клиента? А третьего? Как? больше не тянет? ;) Ф т о п к у!

Не собираюсь спорить, что у жабы своей ниши нет. Очевидно - есть и немалая. Да вот только язык программирования и технология Java на мой взгляд разные понятия. К одной и той же технологии можно разные языки программирования прикрутить. Вот представь к примеру, что вместо Java твой любимый перл используется ( с кроссплатформенностью у него тоже не так уж плохо ). Правда, злая шутка получилась ? :)) Что касается моих предыдущих постов, то говорил я только о текущей реализации JVM и о жабе как о универсальном! языке программирования.

P.S. Не выношу, когда жабу с Си сравнивают и другими языками, которые к жабе никаким боком не относятся. Считаю, что не уместно это.

> Желаюшим плыть против течения и мимо денег - удачного плаванья.

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

Это у Java нормальный механизм исключений?!? Очень интересно. Нормальный механизм исключений - в Objective Caml. Быстрый и сейфный. А у Жабы исключения годятся только для исключительных ситуаций, пардон за бурый кал...

Да, кстати, сам по себе JDBC дюже неудобно юзать. Но его можно очень красиво завернуть в *ПРАВИЛЬНЫЙ* язык: см. http://brl.sourceforge.net/

s/tomcat/resin/g - и вся тормознутость пропадает, а Java остаётся. Гы...

Ембедаббельные RDBMS-движки на Жабке есть. Довольно таки шустрые (понятно, что с sqlite не сравнить - но всё же)...

> см. ocaml.

Строгая типизация и неявная типизация - это несколько перпендикулярные вещи.

>Чего зря говорить? Вы ведь не знаете сколько(точную цифру) такая разработка будет стоить если делать не на java (с сохранением портабельности). Может цена разработки на каком-нить C++ будет на $200 больше.

Не будет. Java не имеет перед С++ никаких преимуществ в плане писания кода. Наоборот - там даже темплейтов и тех нет.

>Сдается мне, что половина писунов тут вообще не в курсе бюджетов подобных проектов

HP OpenView ServiceDesk. Причём на жабе написана не только клиент (за котрый всех его программистов надо вывести в чисто поле и тут же растрелять. В назидание потомкам), но и сервер. Который умудряется при нескольких клиентах ставить раком нехилый такой PA-RISC'овый сервер.

Что самое забавное - никакой портабельности при этом все равно не наблюдается.

>J2EE промышленый стандарт. Еще какие то коментариии нужны?.

И много там в J2EE собственно Java'ы? Может быть господин рассуждающий о "промышленных стандартах" (которые меняются быстрее, чем успеваешь прочитать очередной превью этого "стандарта") взумает уверждать, что JSP,JAXP и прочие XML-RPC имеют какое отношение к Java? А как быть со "промышленным стандартом Enterprise JavaBean" если хочется его подёршать из, например, Excel'я?

>Господину размышляюшему насчет 1000 рабочих мест.И какое это имеет значение для сервера??

А с каих это пор примение Java'ы стало ограничиваться исключетельно серверами? А разве для серверов уже стало не важным обслуживать несколько приложений? И им уже безраздично, что какой-то жалкий фронт-енд к ораклиной базе запросто сжирает гиг-другой памяти?

>Чудак человек! У жабы своя ниша, где ей особой конкуренции в данный момен нет. Вот .NET потихоньку начинает вылезать, но поезд уже ушел. Догнать нереально.

А чего нереального-то? J2EE вот только-только вылезла из пелёнок голых никем по настоящему не реализованных стандартов. .Net сразу появился как готовый к использованию продукт.

>И такие монстры IT бизнеса как IBM, Oracle не от нехер делать развивают JAVA технологии. Видимо чтот то есть, что от тебя ускользнуло.

Как показывает практика не только в СССР реки назад поворачивали и БАМ'ы строили. У буржуев идиотов тоже хвататет. Равно, как и "примкнувших к ним"(с)

>>>Сделай, плиз, один вывод - лишние 256 метров памяти стоят меньше чем 100 баксов >> А теперь умножь на тыщу рабочих мест. >Запросто. Только ты сравни с ценой одного Oracle Enterprise

Сравнил. И что?

>s/tomcat/resin/g - и вся тормознутость пропадает, а Java остаётся. Гы...

URL скажи.

>Да вот только язык программирования и технология Java на мой взгляд разные понятия.

Язык проектировался под технологию.

>К одной и той же технологии можно разные языки программирования прикрутить.

Дану! Правда! А чего не прикручивают? Где виртуальная машина Perl, C, C++, Ada, Lisp, Fortran,... ?

>Вот представь к примеру, что вместо Java твой любимый перл используется ( с кроссплатформенностью у него тоже не так уж плохо ). Правда, злая шутка получилась ? :))

Нисколько. Есть такая система для ленивых админов webmin прозывается. Полностью написана на перле + javascript + applets. Классная штука. Я ей пользуюсь, и прусь от нее. Тоже самое легко сделать на java только зачем, если уже есть на перле?

>Что касается моих предыдущих постов, то говорил я только о текущей реализации JVM и о жабе как о универсальном! языке программирования.

Что касается твоих предыдущик постов, я уже неоднократно предлагал "пузами меряться". Давайте напишем какую-либо числодробилку. Ну хоть обращение матрицы, каждый на своем любимом языке программирования. Со своей любимой оптимизацией. И сравним, что и где быстрее. Вот только все только покричать, а реально что-то сделать, ни укого желания нет.
Делов то на сто строк кода.

>А чего нереального-то? J2EE вот только-только вылезла из пелёнок голых никем по настоящему не реализованных стандартов. .Net сразу появился как готовый к использованию продукт.

Гыгыгыгыгыгыгыгыгыгыгыгыгыгыгыгыгыгыгыгыгыгыгыгыыггы
:))))))))))))))))))))))

Ну повеселил!!!! Давно так не смеялся! Даж слезы потекли! Ты прям новый анекдот придумал! Гыгыгыгыгыгыгыгыгыгы

Ох! Не могу больше! Гыгыгыгыгыгы :))))))))) Щеки заболели.... :)))


>У буржуев идиотов тоже хвататет. Равно, как и "примкнувших к ним"(с)

Аргумент сильный. Возразить не чего. Молчу...

Ой! Гыгыгыгыгыгыгыгы

>Где виртуальная машина Perl, C, C++, Ada, Lisp, Fortran,... ?

Хм. Ты сам то понял, что за чушь сказал?

Ну давай.

Есть положительно определенная симметричная ленточная матрица, заданная

в компактной форме.

Напиши на яве программу для ее обращения.

Гы Гы

На чё будем спорить?

> Что касается твоих предыдущик постов, я уже неоднократно предлагал > "пузами меряться". Давайте напишем какую-либо числодробилку. Ну хоть > обращение матрицы, каждый на своем любимом языке программирования. > Со своей любимой оптимизацией. И сравним, что и где быстрее. Вот > только все только покричать, а реально что-то сделать, ни укого > желания нет. > Делов то на сто строк кода.

Давай, я не против. Только точно сформулируй задачу и попробуем.

Вот мое предложение. Создать массив целых чисел(или с плавающей точкой (double) на выбор), скажем (1000000 элементов). Заполнить его псевдослучайными числами. Создать новый отсортированный массив. Последовательно применить двоичный поиск к каждому элементу массива. Можно использовать стандартные библиотечные функции. Если время выполнения будет небольшим, можно выполнить алгоритм в цикле N раз. Это не числодробилка, но тоже показательная задача.

> Дану! Правда! А чего не прикручивают? Где виртуальная машина Perl, > C, C++, Ada, Lisp, Fortran,... ?

Позволю себе не согласиться. Есть несколько разработок которые используют байт-код, исполняющийся в рамках JVM. В частности, NetProlog : http://netprolog.pdc.dk/ Сам язык PROLOG - логический и к Java отношения никакого не имеет.

Ну децкая задача совсем. Фортран порвет всех на ней.

Школьники на информатике такие решают, двайте лутше про ленточные

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

>>И много там в J2EE собственно Java'ы?

Скажем так, немало :)

>>которые меняются быстрее, чем успеваешь прочитать очередной превью этого "стандарта"

кажеться, вы слишком медленно читаете.

# April 1997, EJB specification announced
# December 1998, Java 2, SDK 1.2 released
# June 1999, J2EE announced & RI shipped
# September 1999, J2EE Beta released
# December 1999, J2EE platform released
# April 2000, J2EE licensed to ATG, BEA, et al
# May 2000, JDK 1.3 released
# May 2000, J2EE 1.2.1 released
# September 2001, J2EE 1.3 released

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

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

P.S. я не против любых матриц, хоть разреженных, если ты профинансируешь разработку.

>> Дану! Правда! А чего не прикручивают? Где виртуальная машина Perl, > C, C++, Ada, Lisp, Fortran,... ?

>Позволю себе не согласиться. Есть несколько разработок которые используют байт-код, исполняющийся в рамках JVM. В частности, NetProlog : http://netprolog.pdc.dk/ Сам язык PROLOG - логический и к Java отношения никакого не имеет.

Это не просимая "виртуальная машина". Она как раз остаётся неизменной и называется JVM. А что именно хотел товарищ, так и осталось непонятным.

>>И много там в J2EE собственно Java'ы? >Скажем так, немало :)

А ничего если я эти Jxxx библиотеки из kawa'ы буду дёргать? Это уже не будет J2EE?

# April 1997, EJB specification announced # December 1998, Java 2, SDK 1.2 released # June 1999, J2EE announced & RI shipped # September 1999, J2EE Beta released # December 1999, J2EE platform released # April 2000, J2EE licensed to ATG, BEA, et al # May 2000, JDK 1.3 released # May 2000, J2EE 1.2.1 released # September 2001, J2EE 1.3 released

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

>мы скорость выполнения программ на разных языках написанных собрались >мерить.

А чё ее мерить?

Или ты сомневашься, что реализация обращение матрицы методом Гаусса, на

фортране будет быстрее чем на яве?

Другое дело использовать алгоритм выгодно использующий сильные стороны

языка.

На простых задачах агритны тоже простые и похожие.

> Или ты сомневашься, что реализация обращение матрицы методом Гаусса, > на фортране будет быстрее чем на яве?

не сомневаюсь.

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

Ну и хде их найти у явы на числодробилках ? Хотя бы примерно, где искать.

А думаю, что существует некоторая критическая точка, когда сложность

реализации алгоритма на фортране превысит скромные умственные

способности афтора. Тогда придется прибегнуть к лиспу, с++ или яве.


Хотя с другой стороны при правильном проектировании этого можно

избежать.

Ведь написали же OS/360 на ассемблере.

Саныч! Ты погоди! Не лезь!

Мы собираемся мерить ИМЕННО выполняемый код на принципиально одинаковых алгоритмах.

Особености языковых фич это немного другое. Можно написать решение системы линейных уравнений из двух уравнений так, что решаться год будет. Это нахрен не нужно.

Зачем нам заморачиваться с разреженными диоагональными матрицами? Там методов всяких просто пруд пруди. Зачем сложные алгоритмы? Говорят байт код медленный. Ну так давайте посмотрим насколько медленный.

Фортран, бесспорно, порвет всех как тузи тряпку. Но сравнить, насколько будет быстрее? Неужели неинтересно?


2Водкин

Сортирвку как делать будем? Слианием, пузырьками, или еще как?

Я предполагал методом Хоара(быстрая сортировка), можно сделать как предложишь.

Саныч, фортран (FORTRAN IV) для разработки просто БЯДА!

А чужой код читать! Маааама!

Эти вычисляемые goto х.з.куда просто песня.

А всякие там комон блоки, просто чума какя-то.

Как вспомню... Брррр.. Мурашки по коже.

:)

Хаора, Хаора,... Не помню. Это что-то с рекурсией. Делим пополам, и сортируем половинки, а потом сливаем? Напомни, или мне к Кнуту обратиться лучше?

Короче, сегодня в конце дня или на крайняк завтра утром, вышлю программу. На фортране писать не буду, будет чистый Ц, безо всяких плюсов. Использовать буду в варианте :

1. qsort и bsearch из stdlib 2. Сам напишу замену этих библиотечных функций.

Компяляторов у меня на работе 3 шт. : GCC, Intel, Watcom, Borland. Фортраном не располагаю. Исходники будут в этом же топике.

Хорошо, используй жабский sort. Как он там чего делает - Х.З. Так тебе и быстрее и проще будет.

Вадик, я за тебя болею.

Поставил $100 протиф $30.

Давай уже не подведи меня.

Обленитесь!

http://shootout.alioth.debian.org/

Зайдите и посмотрите на результат.

>1. qsort и bsearch из stdlib 2. Сам напишу замену этих библиотечных функций.

Ну и отлично. А я на JAVA твою прогу перепру. Могу еще на паскаль. FreePascal есть. Потом обсудим, и погоняем.

ЗЫ. Фортран 77 есть в GCC. Только я на нем писать не буду. Стремно.

Саныч! Тебе только глумится. :)

Давай на фортране ваяй! Или на 1С.

Помню, ты крутейший алгоритм на 1С реализовал. Про улитку. :)

/* Это вариант N 1. Есть оверхед на вызове Cmp */

#include <stdio.h>
#include <stdlib.h>

int SZ;

int Cmp(const void *p1, const void *p2)
{
  register int i1 = *(int *)p1, i2 = *(int *)p2;

  if(i1 > i2)
    return 1;

  if(i1 < i2)
    return -1;

  return 0;
}

int main(int argc, char *argv[])
{
  int  i;
  int *a, *rc;

  if(argc < 2)
  {
    printf("Usage : tst <array_sz>\n");
    return 1;
  }

  SZ = atoi(argv[1]);
  if(SZ < 0 || SZ > 100000000)
  {
    printf("BAD SIZE!\n");
    return 1;
  }

/*  printf("SIZE = %d\n", SZ); */

  if((a = malloc(sizeof(int) * SZ)) == NULL)
  {
    printf("Out mem!\n");
    return 1;
  }

  for(i = 0; i < SZ; i++)
  {
    a[i] = rand();
/*    printf("%d\n", a[i]); */
  }

  qsort(a, SZ, sizeof(int), Cmp);
/*
  printf("-----------------\n");

  for(i = 0; i < SZ; i++) printf("%d\n", a[i]);
  printf("-----------------\n");
*/
  for(i = 0; i < SZ; i++)
  {
/*    printf("%d\n", a[i]); */
    rc = bsearch(a + i, a, SZ, sizeof(int), Cmp);

    if(rc == NULL)
    {
      printf("Elem %d not found\n", a[i]);
      break;
    }
  }

  return 0;
}

да, забыл написать, параметр в командной строке должен быть. Он является размерностью массива.

Да я сам за него болею :) Но со ставками ты погорячился вроде.

Вадик ты чё то тормозишь?

А еще говорят что ява это язык это для рапид апликейшн девелопмент :(

>Вадик ты чё то тормозишь?

>А еще говорят что ява это язык это для рапид апликейшн девелопмент :(

Да, блин, генеральный притащился. Напружинил. Типа, таботаю я... :((

>Вот мое предложение. Создать массив целых чисел(или с плавающей точкой (double) на выбор), скажем (1000000 элементов). Заполнить его псевдослучайными числами. Создать новый отсортированный массив. Последовательно применить двоичный поиск к каждому элементу массива. Можно использовать стандартные библиотечные функции. Если время выполнения будет небольшим, можно выполнить алгоритм в цикле N раз. Это не числодробилка, но тоже показательная задача

Не смеши мои тапочки этой "числодробилкой" ;) 

Показываю что такое "числодробилка"

 16:11:31  up 24 days,  1:01,  2 users,  load average: 2,33, 2,68, 2,76
50 processes: 47 sleeping, 3 running, 0 zombie, 0 stopped
CPU0 states: 100,0% user   0,1% system    0,0% nice   0,0% iowait   0,0% idle
CPU1 states:  99,1% user   0,4% system    0,0% nice   0,0% iowait   0,0% idle
Mem:  2063048k av, 1785084k used,  277964k free,       0k shrd,   39780k buff
         5380k active,            1629032k inactive
Swap:       0k av,       0k used,       0k free                 1313224k cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
32250 ss        14   0 1078M 1,1G  903M R    66,6 53,5  1048m   1 OpenCFD-0.1

так вот расчетная область это 640 000 узлов - каждый описывается структурой
из _примерно_ 150 штук long double  и 2-мя десятками int-ов

Я чегой-то не уверен что джава просто в состоянии инициализировать такой объем данных а уж про "числодробление" наверное лучьше не вспоминать ;))) 

Жаба в чём то красива (вероятно концепция ОО), но её беда в том что это проприетарный язык одной кампании. К тому же ничего более менее серъёзного на ней не напишешь - посему как всегда C++.

Может Вы не знаете, но физики показали что запасов энергии в нашей

вселенной хватит только на ~ 10^128 элементарных лог. операций

Тут люди на деньги спорят, а Вы тратите наши такты на всякую херню.

> Я чегой-то не уверен что джава просто в состоянии инициализировать > такой объем данных а уж про "числодробление"

Матов не хватает. Яву делали _не_ для числодробления. Это все равно, что сравнивать опен-офис с матлабом. Понятно, что в ОО не расчитаешь мат. модель какого-нибудь однополосного детектора, зато в матлабе не сделаешь (за реальное время) расчет бухгалтерского баланса с выкладками.

> К тому же ничего более менее серъёзного на ней не напишешь - > посему как всегда C++.

Вовсе не по этому. А потому, что ты даже на C++ ничего серьёзного не писал.

>Может Вы не знаете, но физики показали что запасов энергии в нашей >вселенной хватит только на ~ 10^128 элементарных лог. операций

Это все зависит от модели вселенной ;)

>Тут люди на деньги спорят, а Вы тратите наши такты на всякую херню.

Нечто ты думаешь что эта фуйня там вертится забесплатно ? ;)

Бух. баланс считают в 1С? Это похоже на бейсик.

Непонятно зачем нужна ява?

>Матов не хватает. Яву делали _не_ для числодробления.

А я чего пытаюсь объяснить "специалистам" которые ситают что джава отстает от сей "по скорости числодробления на 3%" ? ;)

Во. Пинайте.

import java.util.Arrays;
import java.util.ArrayList;
import java.util.Random;
import java.util.Date;

public class Tst
{
    private static final int maxSize = 1000000;

    public static void main (String argv [])
    {
		int sz;

        if (argv.length < 1) {
            System.err.println ("Usage : tst <array_sz>");
            System.exit (1);
        }
				
		try {
            // Get array size
			sz = Integer.valueOf(argv[0]).intValue();

            // Test array size
            if (sz <= 0 || sz > maxSize) {
                System.out.println("BAD SIZE!");
	            System.exit (1);
            }

            // Initial randomize
            Random r = new Random(maxSize);

            // Fill array
            int[] a = new int[sz];
            System.out.println("1. Fill array size of "+sz);
            System.out.println("    start : "+new Date().getTime());
            try {
	            for (int i=0; i<sz-1; i++) {
       				a[i] = r.nextInt();
        	    }
            }
            catch (Exception e) {
                throw new Exception("Fill array error at i="+i+"\n"+e.getMessage());
            }
            System.out.println("    stop  : "+new Date().getTime());

            // Sort array
            System.out.println("2. Sort array");
            System.out.println("    start : "+new Date().getTime());
            Arrays.sort(a);
            System.out.println("    stop  : "+new Date().getTime());

            // Binary search elements
            System.out.println("3. Binary search");
            System.out.println("    start : "+new Date().getTime());
            for (int i=0; i<sz-1; i++) {
                if (Arrays.binarySearch(a, a[i]) != i) System.out.println("Element "+a[i]+" i= "+i+" not found!");
            }
            System.out.println("    stop  : "+new Date().getTime());
		}
		catch (Exception e) {
           throw new NumberFormatException("Integer param ["+argv[0]+"] error\n" + e.getMessage());
		}
	}

}
a

Саныч, будешь смеяться, но те-же самые ученые доказали, что во вселенной реальный физический смысл имеют числа не более 10^40, а число 10^100 (помоему гугол) ваапче больше бесконечности :)

Я же написал, что не считаю эту задачу числодробилкой. А вообще то и ею можно загрузить систему по полной. Запусти несколько копий и увеличь размер массива до максимума. И будет тебе счастье. Я согласен, что задача эта детская, но показательная.

Ну я проверять не буду. Если все работает, - верю на слово. Ты время работы своей программы приведи на числах 10000,100000,1000000 и 10000000. И сравним чья быстрей. А вообще, длинная у тебя программа, я думал на Си больше писать придется. Вопрос : какой конфигурации у тебя комп ? Может мою прогу заодно запустишь ? Она без проблем GCC компилится.

Звиняйте, лажанулся. В буфере обмена какая-то старая лажа оказалась.



import java.util.Arrays;
import java.util.Random;
import java.util.Date;

public class Tst
{
    private static final int maxSize = 1000000;

    public static void main (String argv [])
    {
		int sz;

        if (argv.length < 1) {
            System.err.println ("Usage : tst <array_sz>");
            System.exit (1);
        }
				
		try {
            // Get array size
			sz = Integer.valueOf(argv[0]).intValue();

            // Test array size
            if (sz <= 0 || sz > maxSize) {
                System.out.println("BAD SIZE!");
	            System.exit (1);
            }

            // Initial randomize
//            Random r = new Random(maxSize);
            Random r = new Random();

            // Fill array
            int[] a = new int[sz];
            System.out.println("1. Fill array size of "+sz);
            System.out.println("    start : "+new Date().getTime());
            int i = 0;
            try {
	            for (i=0; i<sz-1; i++) {
       				a[i] = r.nextInt();
        	    }
            }
            catch (Exception e) {
                throw new Exception("Fill array error at i="+i+"\n"+e.getMessage());
            }
            System.out.println("    stop  : "+new Date().getTime());

            // Sort array
            System.out.println("2. Sort array");
            System.out.println("    start : "+new Date().getTime());
            Arrays.sort(a);
            System.out.println("    stop  : "+new Date().getTime());

            // Binary search elements
            System.out.println("3. Binary search");
            System.out.println("    start : "+new Date().getTime());
            int j;
            for (i=0; i<sz-1; i++) {
                j = Arrays.binarySearch(a, a[i]);
                if (j < 0) System.out.println("Element "+a[i]+" i= "+i+" j= "+j+" not found!");
            }
            System.out.println("    stop  : "+new Date().getTime());
		}
		catch (Exception e) {
           throw new NumberFormatException("Integer param ["+argv[0]+"] error\n" + e.getMessage());
		}
	}

}

Вот получилось такое:

1. Fill array size of 1000
    start : 1093535757460
    stop  : 1093535757462
2. Sort array
    start : 1093535757464
    stop  : 1093535757474
3. Binary search
    start : 1093535757476
    stop  : 1093535757491
=============================
1. Fill array size of 10000
    start : 1093535804440
    stop  : 1093535804447
2. Sort array
    start : 1093535804449
    stop  : 1093535804509
3. Binary search
    start : 1093535804511
    stop  : 1093535804587
============================
1. Fill array size of 100000
    start : 1093535840624
    stop  : 1093535840713
2. Sort array
    start : 1093535840715
    stop  : 1093535840803
3. Binary search
    start : 1093535840805
    stop  : 1093535840873
=============================
1. Fill array size of 1000000
    start : 1093535870980
    stop  : 1093535871252
2. Sort array
    start : 1093535871254
    stop  : 1093535871680
3. Binary search
    start : 1093535871682
    stop  : 1093535871952
=============================
1. Fill array size of 10000000
    start : 1093535896395
    stop  : 1093535898494
2. Sort array
    start : 1093535898496
    stop  : 1093535902901
3. Binary search
    start : 1093535902904
    stop  : 1093535905629
==============================

Время в формате longint впадлу мне было тысячные высчитывать.

ЗЫ. А ни кто и не говорил, что на жабе код короткий. Какраз наоборот.

А компик у меня... ща гляну... Мозгу 512 метров.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 1
model name      : Intel(R) Celeron(R) CPU 1.70GHz
stepping        : 3
cpu MHz         : 1700.048
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 3394.76

Слушай, а тебе, что влом вычитать : stop - start. Что еще и калькулятор под рукой держишь ?

/* Вот вариант с засечкой времени по 3 этапам */

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int SZ;

int Cmp(const void *p1, const void *p2)
{
  register int i1 = *(int *)p1, i2 = *(int *)p2;

  if(i1 > i2)
    return 1;

  if(i1 < i2)
    return -1;

  return 0;
}

int main(int argc, char *argv[])
{
  int     i;
  int    *a, *rc;
  time_t  tmbgn;

  if(argc < 2)
  {
    printf("Usage : tst <array_sz>\n");
    return 1;
  }

  SZ = atoi(argv[1]);
  if(SZ < 0 || SZ > 100000000)
  {
    printf("BAD SIZE!\n");
    return 1;
  }

  tmbgn = time(NULL);

  printf("SIZE = %d\n", SZ);

  if((a = malloc(sizeof(int) * SZ)) == NULL)
  {
    printf("Out mem!\n");
    return 1;
  }

  for(i = 0; i < SZ; i++)
  {
    a[i] = rand();
  }

  printf("fill array : %lu (sec)\n", time(NULL) - tmbgn);

  tmbgn = time(NULL);
  qsort(a, SZ, sizeof(int), Cmp);
  printf("sort time : %lu (sec)\n", time(NULL) - tmbgn);

  tmbgn = time(NULL);

  for(i = 0; i < SZ; i++)
  {
    rc = bsearch(a + i, a, SZ, sizeof(int), Cmp);

    if(rc == NULL)
    {
      printf("Elem %d not found\n", a[i]);
      break;
    }
  }

  printf("search time : %lu (sec)\n", time(NULL) - tmbgn);

  free(a);
  return 0;
}

Ну, что мой вариант сам скомпилишь ??

>Она без проблем GCC компилится.

$ ./tst 1000
$ ./tst 10000
$ ./tst 100000
$ ./tst 1000000
$ ./tst 10000000

А кто время печатать будет? С секундомером сидеть? :)

Давай, приводи в порядок.

Последний листинг возьми, там время есть.

=============================
SIZE = 1000
fill array : 0 (sec)
sort time : 0 (sec)
search time : 0 (sec)
=============================
SIZE = 10000
fill array : 0 (sec)
sort time : 0 (sec)
search time : 0 (sec)
============================
SIZE = 100000
fill array : 0 (sec)
sort time : 0 (sec)
search time : 0 (sec)
============================
SIZE = 1000000
fill array : 0 (sec)
sort time : 1 (sec)
search time : 0 (sec)
============================
SIZE = 10000000
fill array : 1 (sec)
sort time : 10 (sec)
search time : 7 (sec)
============================

У меня

1. Fill array size of 10000000
    start : 1093535896395
    stop  : 1093535898494
    Итого :          2099 мсек (2 сек)
2. Sort array
    start : 1093535898496
    stop  : 1093535902901
    Итого :          4405      (4 сек)
3. Binary search
    start : 1093535902904
    stop  : 1093535905629
    Итого :          2725      (3 сек)


По последниму варианту 10000000 (остальные у тебя нули).

Общее время у тебя 18 сек, у мен 9 сек.

Вобщем, о чем я и говорил.

ЗЫ. Саныч! Ты выиграл! С тебя пиво! :)))

Какой ты шустрый, однако. Я проверю у себя, завтра скажу результат. Но мы договорились 2 варианта проверить. Если все у тебя так быстро, то есть вероятность, что Java при сортировках скомпиленный код зовет. А тогда это не Java уже победила, а в стандартной библиотеке GCC функция сортировки хуже написана.

/* Сортировка - своя, поиск свой. То же, но на жабе плиз. */

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define flip(x, y) tmp = *(x); *(x) = *(y); *(y) = tmp

int SZ;

static void quick_sort(int *base, int num)
{
   register int num_smaller, tmp, *large, *small;

   if ( num < 3 ) 
   {
      if ( num == 2 ) 
      {
	 if ( base[0] > base[1] ) { flip(base, base + 1); }
      }
      return ;
   }

   large =  base + num - 1;
   small =  base + (num >> 1);

   if (*small > *large)
   {
     flip( small, large );
   }

   if(*small > *base)
   {
      flip(small, base);
   }
   else
      if (*base > *large)
      {
	flip( base, large );
      }

   if(num == 3)
   {
      flip(base, small);
      return ;
   }

   small =  base + 1; 

   while (small < large)
   {
      if ( *small < *base )
      {
	 small += 1;
	 continue;
      }

      do
      {
	 if (*base > *large) 
	 {
	    flip( small, large );
	    large -= 1;
	    small += 1;
	    break;
	 }
	 large -= 1;
      } while( small < large );
   }

   if (*small < *base) { flip(small,base); }
   num_smaller = small - base;

   quick_sort( small, num - num_smaller );
   quick_sort( base,        num_smaller );

   return;
}

int * bin_find(int *key, int *base, int nelem)
{
  int  *kmin, *probe;
  int i, j;

  kmin = base;

  while (nelem > 0)
  {
    i = nelem >> 1;
    probe = kmin + i;

    if (*key == *probe)
      return(probe);
    else if (*key < *probe)
      nelem = i;
    else  
    {
      kmin = probe + 1;
      nelem = nelem - i - 1;
    }
  }

  return NULL;
}

int main(int argc, char *argv[])
{
  int     i;
  int    *a, *rc;
  time_t  tmbgn;

  if(argc < 2)
  {
    printf("Usage : tst <array_sz>\n");
    return 1;
  }

  SZ = atoi(argv[1]);
  if(SZ < 0 || SZ > 100000000)
  {
    printf("BAD SIZE!\n");
    return 1;
  }

  tmbgn = time(NULL);

  printf("SIZE = %d\n", SZ);

  if((a = malloc(sizeof(int) * SZ)) == NULL)
  {
    printf("Out mem!\n");
    return 1;
  }

  for(i = 0; i < SZ; i++)
  {
    a[i] = rand();
  }

  printf("fill array : %lu (sec)\n", time(NULL) - tmbgn);

  tmbgn = time(NULL);
  quick_sort(a, SZ);
  printf("sort time : %lu (sec)\n", time(NULL) - tmbgn);

  tmbgn = time(NULL);

  for(i = 0; i < SZ; i++)
  {
    rc = bin_find(a + i, a, SZ);

    if(rc == NULL)
    {
      printf("Elem %d not found\n", a[i]);
      break;
    }
  }

  printf("search time : %lu (sec)\n", time(NULL) - tmbgn);

  free(a);
  return 0;
}

Ха-ха! А на самом деле этот тест в натуре ни о чем не говорит. Совершенно бестолковый, хотя подверждает то, что ява вовсе не всегда медленней C.

P.S. Intel сделал GCC в 2.5 раза на моей тачке (P4 256M.) в первом варианте программы с библиотечными qsort и bsearch.

> for (i=0; i<sz-1; i++) { > a[i] = r.nextInt(); > }

Почему цикл до sz-1 вроде в жабе та же индексация, что и в Си ?

http://www.caucho.com/

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

Я именно об этом все время и говорил. Те, кто, понезнанию, утверждают, что JAVA тормоз, на самом деле, просто не в теме. Нетормознее других.

Данный тест, действительно, мало о чем говорит. Просто в библиотеках JAVA сортировка и поиск лучше реализованы. Хотя, это говорит о многом.

>то есть вероятность, что Java при сортировках скомпиленный код зовет.

Неа. Все в байткоде. Класс Arrays можешь сам в сырцах глянуть.

Да. Я юзал j2sdk1.4.2 от SUN.

>Почему цикл до sz-1 вроде в жабе та же индексация, что и в Си ?

А Х.З. спешил. Поправь.

Последнюю, мою программу запусти, пожалуйста. Она быстрее должна работать. И дело здесь не в Си как таковом, а в погано написанной функции qsort библиотеки glibc. Ее наверно студенты писали недоученные. Даже старый компилятор Watcom по скорости сортировки делает GCC более чем в 2 раза. Я думаю, что моя последняя программа, должна таки сделать жабу раза в 2 хотя бы. Вообще qsort может многократно вызываться некоторыми СУБД, и это будет узким местом в их производительности. Да, не забудь при компиляции врубить оптимизацию.

Ха-ха! Действительно, сортировка написана pure-java, т.е. без вызова нативного кода.

>Я именно об этом все время и говорил. Те, кто, понезнанию, >утверждают, что JAVA тормоз, на самом деле, просто не в теме. >Нетормознее других.

То есть, ты хочешь сказать, что все перечисленные выше программы от IBM, HP работают быстро и память не жрут вовсе ? И не надо для жаба-программ тачку иметь с 1 гигом мозгов ? А я вот думаю, что прсто этот тест не выявил узких мест в реализации JVM.

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

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

>    private static final int maxSize = 1000000;

>            // Test array size
>            if (sz <= 0 || sz > maxSize) {
>                System.out.println("BAD SIZE!");
>            System.exit (1);
>            }

Вот отрывок твоего кода, я плохо знаю яву, могу ошибаться. Вопрос : как при maxSize = 1 млн. ты сортировал массив размером 10 млн. ??

>ЗЫ. Саныч! Ты выиграл! С тебя пиво! :)))

Вадик, а я и не сомневался ниразу.

Я паренькам потом сказал, что у тебя менты знакомые в ОБОПе, дык они

деньги сразу отдали.

Чегой то тормозит твой Вадик. У меня его программа ни хрена вообще не работает. Пришлось кильнуть ее на фиг. А мою последнюю программу он так и не скомпилил и результаты не показал. Так, что еще не ясно, кто выиграл. Вот бы независимого эксперта найти, да где там, все в сговоре , на защуты жабы как один вышли :((

Ладно мне уходить пора. Сегодня командировка у меня. Буду только вечером.

>Вопрос : как при maxSize = 1 млн. ты сортировал массив размером 10 млн. ??

Очень просто. Ты попросил 10 лимонов, я в коде поправил.

Вот твом новые результатаы:
SIZE = 10000000
fill array : 1 (sec)
sort time : 4 (sec)
search time : 4 (sec)

Вот мои результаты (я сортировку не переписывал. лень)
1. Fill array size of 10000000
    start : 1093596619333
    stop  : 1093596621434
    total :          2101
2. Sort array
    start : 1093596621437
    stop  : 1093596625724
    total :          4287
3. Binary search
    start : 1093596625739
    stop  : 1093596628525
    total :          2786

Если сомниваешься, что у меня сортируется, то пжалуста:

1. Fill array size of 100
    start : 1093596887185
    stop  : 1093596887186
    total :          1
2. Sort array
    start : 1093596887189
    stop  : 1093596887192
    total :          3
a[0]=-2111599406
a[1]=-2069543405
a[2]=-2032038148
a[3]=-2031976050
a[4]=-2022986515
a[5]=-2007690959
a[6]=-1945460874
a[7]=-1937900332
a[8]=-1929162988
a[9]=-1866504218
a[10]=-1843837416
a[11]=-1820515551
a[12]=-1820442276
a[13]=-1812038488
a[14]=-1786896641
a[15]=-1779750641
a[16]=-1755335777
a[17]=-1754820398
a[18]=-1739430236
a[19]=-1715306654
a[20]=-1648565432
a[21]=-1629523293
a[22]=-1538196019
a[23]=-1528492485
a[24]=-1527356690
a[25]=-1506256877
a[26]=-1470917501
a[27]=-1468515384
a[28]=-1396733484
a[29]=-1342182883
a[30]=-1238156590
a[31]=-1179950846
a[32]=-1120321371
a[33]=-1101073774
a[34]=-1060389163
a[35]=-1058627450
a[36]=-1052916733
a[37]=-989769244
a[38]=-907573098
a[39]=-890407528
a[40]=-832207321
a[41]=-787175442
a[42]=-748042236
a[43]=-572708201
a[44]=-566204244
a[45]=-536484320
a[46]=-452399322
a[47]=-431718268
a[48]=-404544121
a[49]=-348108885
a[50]=-309701300
a[51]=-220409445
a[52]=-196868093
a[53]=-194012432
a[54]=-137406858
a[55]=-126115113
a[56]=-112576415
a[57]=-95668345
a[58]=-75573937
a[59]=1083895
a[60]=37402774
a[61]=81829755
a[62]=160059553
a[63]=164019117
a[64]=220521548
a[65]=237545053
a[66]=556751899
a[67]=565699794
a[68]=601068540
a[69]=660668956
a[70]=683669536
a[71]=746342829
a[72]=777396456
a[73]=871729834
a[74]=968283502
a[75]=984361632
a[76]=1040159412
a[77]=1107710579
a[78]=1153351491
a[79]=1154968958
a[80]=1158635576
a[81]=1196878357
a[82]=1354244228
a[83]=1384040837
a[84]=1387115327
a[85]=1544213703
a[86]=1574930135
a[87]=1618893473
a[88]=1645240543
a[89]=1707687838
a[90]=1754342706
a[91]=1754954330
a[92]=1773989962
a[93]=1806908838
a[94]=1827886854
a[95]=1844008423
a[96]=1844784250
a[97]=1892381188
a[98]=1926732568
a[99]=1969745353
3. Binary search
    start : 1093596887375
    stop  : 1093596887376
    total :          1

ЗЫ. Не пойму, что у тебя могло так круто зависнуть? :(( У меня все пашет, аж пищит.

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

У меня, типа, других дел хватает. Освободился, сделал. Твою прогу откомпилил. Может что не так сделал? С Си я не спец.

gcc -o tst_s tst_s.c
./tst_s 10000000

bla-bla-bla.


Что ты там такое намутил, что моя зависла???

/usr/java/j2sdk1.4.2/bin/javac Tst.java
/usr/java/j2sdk1.4.2/bin/java Tst 10000000

bla-bla-bla.

Все действительно работает, только что проверил на другой тачке. Предыдущая загружена была сильно и программа в своп уходила, памяти было мало. Ладно, у меня вопросов нет больше. По времени ничья получилась, да и фиг с ним. Единственно, что для меня не ясно, так это то, что на более слабой тачке cel 1.2 моя последняя программа скомпиленная GCC 2.953, показала в результате 7 сек, у тебя на cel 1.7 - 9. Но это уже мелочи. В общем согласен, не проиграла жаба ни капли. Так, что считаю спор закрытым. :)

P.S. Но все же ты несколько себе подыграл. Оптимизацию при компиляции, так и не включил. :))

gcc -O -o tst_s tst_s.c

>Может у тебя ошибка какая-то с циклами ??

Может и ошибка. Вот последний вариант.

===================================

import java.util.Arrays;
import java.util.Random;
import java.util.Date;

public class Tst
{
    private static final int maxSize = 10000000;

    public static void main (String argv [])
    {
		int sz;
    long start;
    long stop;

        if (argv.length < 1) {
            System.err.println ("Usage : tst <array_sz>");
            System.exit (1);
        }
				
		try {
            // Get array size
			sz = Integer.valueOf(argv[0]).intValue();

            // Test array size
            if (sz <= 0 || sz > maxSize) {
                System.out.println("BAD SIZE!");
	            System.exit (1);
            }

            // Initial randomize
            Random r = new Random();

            // Fill array
            int[] a = new int[sz];
            System.out.println("1. Fill array size of "+sz);
						start = new Date().getTime();
            System.out.println("    start : "+start);
            int i = 0;
            try {
	            for (i=0; i<sz; i++) {
       				a[i] = r.nextInt();
        	    }
            }
            catch (Exception e) {
                throw new Exception("Fill array error at i="+i+"\n"+e.getMessage());
            }
						stop = new Date().getTime();
            System.out.println("    stop  : "+stop);
            System.out.println("    total :          "+String.valueOf(stop-start));

            // Sort array
            System.out.println("2. Sort array");
						start = new Date().getTime();
            System.out.println("    start : "+start);
            Arrays.sort(a);
						stop = new Date().getTime();
            System.out.println("    stop  : "+stop);
            System.out.println("    total :          "+String.valueOf(stop-start));
//						for (int k=0; k<sz; k++) {
//							System.out.println("a["+k+"]="+a[k]);
//						}

            // Binary search elements
            System.out.println("3. Binary search");
						start = new Date().getTime();
            System.out.println("    start : "+start);
            int j;
            for (i=0; i<sz; i++) {
                j = Arrays.binarySearch(a, a[i]);
                if (j < 0) System.out.println("Element "+a[i]+" i= "+i+" j= "+j+" not found!");
            }
						stop = new Date().getTime();
            System.out.println("    stop  : "+stop);
            System.out.println("    total :          "+String.valueOf(stop-start));
		}
		catch (Exception e) {
           throw new NumberFormatException(e.getMessage());
		}
	}

}

===========================================================

Наслаждайся.

ЗЫ. Уские места java я знаю. А алгоритм теста ты предложил. :) Такчто звиняйте если что не так.

И еще памяти у тебя кушается аж под 160М. А у меня только ~ 41М

>P.S. Но все же ты несколько себе подыграл. Оптимизацию при компиляции, так и не включил. :))

Это неспециально. Не в курсах я про особености GCC. Дальше
./configure
make
make install
мои познания не идут :)

Таки да. Жаба память любит. :)

Вот, что интересно, свои, на скорую руку написанные функции сортировки и поиска, ускорили выполнение программы ровно в 2 раза. Все же кто пишет эту чертову glibc. Неуже ли нельзя было за такой срок написать нормальные функции сортировки и поиска. Проигрывать другим компилерам в 2 - 2.5 раза просто ПОЗОР !!

Это действительно смущает. :((( Может патчик им заслсть?

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

> Все же кто пишет эту чертову glibc.

Ульрих её пишет. А ты попргобуй dietlibc от Феликса:
http://www.fefe.de/dietlibc/
Много времени не займёт её установить: make; make install, а дальше
собирай свою программу так: diet gcc <остальные аргументы>
Скорость должна повыситься минимум в 3 раза.

>Я именно об этом все время и говорил. Те, кто, понезнанию, утверждают, что JAVA тормоз, на самом деле, просто не в теме. Нетормознее других.

На самом деле вы сами не понимаете, что меряете. Понятно, что такой код jit-компилируется без труда. Чтобы понять преимущество C++ создайте вектор комплексных чисел, где каждый элемент - это объект типа Complex. Понятно, что все методы в C++ должны быть сделаны встраиваемыми (inline). Или вообще вектор элементов произвольного типа. Вот это и сравнивайте. Если и тут java будет не медленнее - тогда да, я поверю в то, что Java выигрывает здесь у C++

Разве гцц не игнорирует inline?

Насчет gcc не знаю, но он явно не единственный компилятор C++ в мире. Вообще я к тому, что на C++ можно нормально пользоваться инкапсуляцией без ущерба по скорости - грубо говоря, нормально создавать абстрактные типы данных и оперировать ими. У меня (VC++ 6) разница в скорости между Debug (без оптимизации и инлайнов) и Release версиями за счет инкапсуляции и инлайнга может быть до десяти раз.

>P.S. Но все же ты несколько себе подыграл. Оптимизацию при компиляции, так и не включил. :))

>gcc -O -o tst_s tst_s.

SIZE = 10000000
fill array : 1 (sec)
sort time : 3 (sec)
search time : 2 (sec)

Давайте для сравнения такой код на Jave напишите

#include <vector>
#include <time.h>

template<class T> class Complex
{
public:
Complex() {}
Complex(const Complex<T>& Other): Rl(Other.Rl), Im(Other.Im) {}
Complex(const T& rl, const T& im): Rl(rl), Im(im) {}
Complex& operator += (const Complex<T>& Other)
{ Rl += Other.Rl; Im += Other.Im; return *this; }
protected:
T Rl, Im;
};

int main(int argc, char* argv[])
{
time_t t0 = time(&t0);

size_t Count = 10000000, Index;
std::vector< Complex<double> > points;
points.reserve(Count);
for( Index = 0; Index < Count; Index++ )
points.push_back(Complex<double>((double)(Index % 100),
(double)(Index % 1000)));

time_t t1 = time(&t1);
Complex<double> Sum(0.0, 0.0);
for( Index = 0; Index < Count; Index++ )
Sum += points[Index];

time_t t2 = time(&t2);
printf("init: %d, calc: %d\n", t1 - t0, t2 - t1);
return 0;
}

Без отимизации и инлайнинга такой код выполнялся (VC6, PIII/Celeron ~800-1000 512M - не знаю точно) выполнялся 16/4 сек., с оптимизацией и инлайнингом - 2/0 сек. Интересно было бы на Jave посмотреть.

> Без отимизации и инлайнинга такой код выполнялся (VC6, PIII/Celeron
> ~800-1000 512M - не знаю точно) выполнялся 16/4 сек., с  
> оптимизацией и инлайнингом - 2/0 сек. Интересно было бы на Jave посмотреть. 

Ну вобщем понятно что в такой формулировке решение на Java будет проигровать по определению.

Привожу более нейтральный тест:

#include <stddef.h>
#include <sys/time.h> 

#include <vector> 

const int count = 10000000;

class Figure {
public:
	virtual double getArea() = 0;
};

class Rectangle : public Figure {
public:
	Rectangle(double h, double w) : h(h), w(w) {}
	double getArea();

private:
	double h;
	double w;	
};

double Rectangle::getArea() {
	return h * w;
}

class Triangle : public Figure {
public:
	Triangle(double a, double b) : a(a), b(b) {}
	double getArea();

private:
	double a;
	double b;
};

double Triangle::getArea() {
	return 0.5 * a * b;
}

unsigned int milisec(const timeval& x, const timeval& y) {
	return (1000000 * (y.tv_sec - x.tv_sec) + (y.tv_usec - x.tv_usec)) / 1000;
}

int main(int argc, char* argv[]) 
{ 
	timeval t0;
	gettimeofday(&t0, NULL); 
 
	std::vector<Figure *> figures; 
	figures.reserve(count); 
	for(int i = 0; i < count; ++i) {
		figures.push_back(i % 3 == 0 ? (Figure *) new Rectangle(i % 100, i % 99)
			: (Figure *) new Triangle(i % 100, i % 99)); 
	}
 
	timeval t1;
	gettimeofday(&t1, NULL);

	double s = 0.0;
	for (int n = 0; n < 100; ++n) {
		for(int i = 0; i < count; ++i) {
			s += figures[i]->getArea();
		}
	}

	timeval t2;
	gettimeofday(&t2, NULL);
 
	printf("summa: %f\n", s);	
	printf("init: %d, calc: %d\n", milisec(t0, t1), milisec(t1, t2));
 
	return 0; 
}
java:

public class Test {
	private final static int count = 10000000;

	interface Figure {
		double getArea();
	}

	static class Rectangle implements Figure {
		public Rectangle(double h, double w) {
			this.h = h;
			this.w = w;
		}

		public double getArea() {
			return h * w;
		}
	
		private double h;
		private double w;
	}

	static class Triangle implements Figure {
		public Triangle(double a, double b) {
			this.a = a;
			this.b = b;
		}

		public double getArea() {
			return 0.5 * a * b;
		}
	
		private double a;
		private double b;
	}

	public static void main(String[] args) {
		long time0 = System.currentTimeMillis();

		Figure[] figures = new Figure[count];
		for(int i = 0; i < count; ++i) {
			figures[i] = (i % 3 == 0 ? (Figure) new Rectangle(i % 100, i % 99)
				: (Figure) new Triangle(i % 100, i % 99));
		}

		long time1 = System.currentTimeMillis();

		double s = 0.0;
		for (int n = 0; n < 100; ++n) {
			for(int i = 0; i < count; ++i) {
				s += figures[i].getArea();
			}
		}

		long time2 = System.currentTimeMillis();

		System.out.print("summa: ");
		System.out.println(s);

		System.out.print("init: ");		
		System.out.print(time1 - time0);

		System.out.print(", calc: ");		
		System.out.println(time2 - time1);
	}
}

bash-2.05b$ /opt/ibm-jdk-bin-1.4.2/bin/java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia321420-20040626 (JIT enabled: jitc))
bash-2.05b$ gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Configured with: /var/tmp/portage/gcc-3.3.2-r5/work/gcc-3.3.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,f77,objc --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --disable-multilib
Thread model: posix
gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)


bash-2.05b$ /opt/ibm-jdk-bin-1.4.2/bin/java -Xms512m -Xmx512m Test
summa: 1.6087864848E12
init: 828, calc: 18038

bash-2.05b$ g++ -O3 -march=athlon-xp Test.cxx
bash-2.05b$ ./a.out
summa: 1608786484800.000000
init: 1448, calc: 21803

Выводы делайте сами ;-)

2 vilfred:

> привет всем из солнечного Крыма, город Феодосия, вода в море +25

Феодосия ацтой :) Отдыхающие "друг у друга на головах" и ваще толпа и отсутсвие комфорта. В Гаграх круче :)

>Ну вобщем понятно что в такой формулировке решение на Java будет проигровать по определению.
>Привожу более нейтральный тест:

Конечно, если писать на C++ как на Java, то разницы не будет. Мне все-таки кажется, что использовать в расчетных задачах virtual и new - несколько нетипично, а вот инлайнинг и абстрактные типы данных - самое то. В общем Ваш тест вообще ничего не показывает, либо показывает именно то, что Вы бы хотели увидеть :)

> Конечно, если писать на C++ как на Java, то разницы не будет. 

Не согласнен, virtual - это "основной инструмент абстракции" используемый в подавляющем большенстве программ (что на C++, что на Java, что на C#) имеющих хоть какую нибудь архитектурную сложность. Что значит писать на C++ как на Java, в контексте virtual ? Что Вы предлагаете для C++ ? Заменить на switch/case ;-) Думаете производительность и архитектура программы от этого будут лучше ? Иммено по этому я выбрал virtual для теста, так как тест с ним примерно одинаков для c++ и java, а эффективой замены не существует.

> Мне все-таки кажется, что использовать в расчетных задачах virtual и new -
> несколько нетипично, а вот инлайнинг и абстрактные типы данных - самое то. 

Согласен, но расчетные задачи это скорее фортран + intel MKL, чем С++, по известным причинам, а по поводу расчетных задач и java можете посмотреть это:
http://www.vinci.org/rlv/d/javaperf/docs/lewis/javaCbenchmark.html.

> В общем Ваш тест вообще ничего не показывает, либо показывает именно то, что
> Вы бы хотели увидеть :)

Я увидел что других серьезных причин кроме пямяти (через лет пять тоже будет не критично) писать на C/С++ нет. Я не говорю что java лучшая платформа для всего и не призываю писать только на ней, мне просто не нравится предвзятое отношение к ней. Хочу заметить что современная java, это:
	1) Быстрейший allocator и GC (кто там говорил про большие обьемы и базы данных, посмотрите на Cloudscape)
	2) Run-time оптимизация недоступная обычному компилятору (см. тест выше ;-)).
	3) Огромный выбор open-source библиотек и модулей (в С++ тоже не мало (хотя существенно меньше), но автор каждой второй считает что для его проекта нужно реализовать собственную common библиотеку (string, collections, threads, file io), а про exceptions слышал только 1 из 10 (я имею в виду exception safe код)).
	4) Скорость разработки (следствие 3, плюс все однородно: платформа, внешние библиотеки)
	5) Стабильность (утечек памяти нет, все привыкли кидать exception, а не вызывать exit(-1) (конечно это клинический случай, но бывают) ;-))
	6) Безопасность (постоянно не боишся получить переполнение стыка)

Если кто думает что в ближайшем будущем java-у вытестнет dotNET c С#, то это вряд ли, дело не в фичах языка или платформы, а в сообществе  разработчиков которые выберают dotNET, в большенстве я бы не стал ждать от них хороших open-source библиотек (хотя несколько  имеются). Соответственно разработка всего что вылазит за границы стандартной библиотеки заведомо проигрывает java.

Вообще-то разговор шел как раз о расчетах, если Вы помните :)

Понимаете, я не противник явы. Я просто пытаюсь показать ее больное, с моей точки зрения, место, а именно отсутствие средств для создания небольших быстрых классов. Т.е. либо громоздкие наследники Object - "моделирующие предметную область", либо непонятно что. Но ведь в реальных сложных приложениях таких "моделирующих" объектов как правило значительно меньше, чем небольших вспомогательных. В итоге: невозможность создать свою инфраструктуру/архитектуру приложения, если это действительно нужно. В этом же заключается и плюс явы - фиксированная инфраструктура, заточенная под создание бизнес-приложений и, как следствие, большая стандартная библиотека и множество легко-интегрируемых сторонних. А как язык ява - не фонтан imho.
Поэтому же, мне кажется, так мало "коробочных" приложений уровня Photoshop или Office, написанных на яве - там разработчикам и так и так приходится вырабатывать свою инфраструктуру с нуля, а тут ява далеко не помошник.

> bash-2.05b$ /opt/ibm-jdk-bin-1.4.2/bin/java -Xms512m -Xmx512m Test

-Xms512m ? Дык это ж допинг ;) Не по-олимпийски как-то.

$ uname -a
Linux earth 2.6.7 #1 Mon Aug 9 16:17:07 MSD 2004 i686 AMD Athlon(tm) XP 1500+ AuthenticAMD GNU/Linux

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs
Configured with: (...)
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)

$ /opt/ibm-jdk-bin-1.4.2/bin/java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia321420-20040626 (JIT enabled: jitc))

$ ./test_cpp
summa: 1608786484800.000000
init: 997, calc: 34592

$ /opt/ibm-jdk-bin-1.4.2/bin/java -Xmx512m -Xms512m Test
summa: 1.6087864848E12
init: 2725, calc: 71202

Небольшой прикольчик: ;)
$ /opt/ibm-jdk-bin-1.4.2/bin/java -Xmx512m -Xms2m Test
summa: 1.6087864848E12
init: 8536, calc: 70826

Вот такой допинг применен для С++:
size_t memSize = sizeof(Rectangle) * count/3 + sizeof(Triangle) * (count - count / 3);
void* mem = reinterpret_cast<Rectangle *>(operator new(memSize));
Rectangle *rectMem = reinterpret_cast<Rectangle *>(mem);

for (int i = 0; i < count; i+=3) {
figures[i] = new (rectMem++) Rectangle(i % 100, i % 99);
}

Triangle *triMem = reinterpret_cast<Triangle *>(rectMem);
for (int i = 1; i < count; i+=3) {
figures[i] = new (triMem++) Triangle(i % 100, i % 99);
figures[i+1] = new (triMem++) Triangle(i % 100, i % 99);
}


Выводы делайте сами... ;)

-Xms512m -Xmx512m - это нормально, т.к. применимо к любой java программе без ее изменения.

Попробуйте своим способом ускорить OpenOffice ;-), у него как раз тормоза при запуске по этому поводу.

А ваш допиг на C++, изменяет порядок объектов, хотя на результат в данной задаче это не влияет, но это уже попахивает дисквалификацией ;-)

34592 vs 71202
А куда же у нас делся virtual ? Кючики gcc и результат gcc -S слабо привести ?

> А ваш допиг на C++, изменяет порядок объектов, хотя на результат в данной задаче это не влияет, но это уже попахивает дисквалификацией ;-)

Ну... отпарирую так: можно применить более сложную в реализации, не меняющую порядок обьектов оптимизацию, перегрузив операторы new & delete.

> А куда же у нас делся virtual ? Кючики gcc и результат gcc -S слабо привести ?

Ничего больше не менял, чесслово. :) Ключики: -O3 -march=athlon-xp -ffast-math. Коли интересно, g++ -S: http://rafb.net/paste/results/2jZPb044.html. Честно говоря, сам удивлен результатами явы. :\

> Попробуйте своим способом ускорить OpenOffice ;-), у него как раз тормоза при запуске по этому поводу.

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

> отпарирую так: можно применить более сложную в реализации, не меняющую порядок обьектов оптимизацию, перегрузив операторы new & delete.

А что будет если потребуется удалить 90% обьектов, в произвольном порядке ?

Конечно, перегрузив операторы new & delete, можно реализовать специальный алгоритм allocator-а на этот случай, но не стоит забывать что процессор может быть и не один, и если вы хотите конкурировать с jvm allocator одним глобальным mutex вы не отделаетесь, а условие задачи (требования заказчика в реальной жизни) в процессе раелизации этого всего может и изменится.

Будем изобритать велосипед или признаем что для реальных задач jvm allocator эффективнее ?

Да не забудьте о времени на тестирование и отладку, даже ваш не очень сложный допинг не лишен ошибок:
const int count = 10000000;
int a = count / 3;
for (int i = 0; i < count; i+=3) {
a--;
printf("%d\n", a); /* ;-) */
> Ничего больше не менял, чесслово. :)
.L149:
.L137:
.L142:
leal 0(,%ebx,4), %edi
addl -40(%ebp), %edi
movl (%edi), %edx
movl (%edx), %ecx
movl %edx, (%esp)
call *(%ecx) # virtual call
faddl -104(%ebp)
incl %ebx
cmpl $9999999, %ebx
fstpl -104(%ebp)
jle .L149
Верю ;-)
bash-2.05b$ g++ a.s
bash-2.05b$ ./a.out
summa: 1600535735700.000000
init: 393, calc: 19978
bash-2.05b$ /opt/ibm-jdk-bin-1.4.2/bin/java -Xmx512m -Xms512m Test
summa: 1.6087864848E12
init: 798, calc: 17973
Но мой jdk все равно быстре ...
> Честно говоря, сам удивлен результатами явы. :\
Я скорее удивлен скоростью работы именно вашего jdk, обьясняю почему:
у вас
> $ uname -a
> Linux earth 2.6.7 #1 Mon Aug 9 16:17:07 MSD 2004 i686 AMD Athlon(tm) XP
> 1500+ AuthenticAMD GNU/Linux
у меня
bash-2.05b$ uname -a
Linux meteor 2.6.7-gentoo-r6 #11 Wed Aug 4 20:53:28 VLAST 2004 i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
в 32 разрядном режиме

отношение результатов C++ теста: 35589 / 20371 = 1.74704 (вполне правдоподобно)
отношение результатов Java теста: 73927 / 18771 = 3.93836 (AMD нужно было назвать мой процессор Athlon64 6000+ ???)

А может я эти цифры придумал ? Поищите в google другие benchmark-и почему то их результаты схожи с моими, а такой провал в скорости jdk похоже только у вас :?

Возможно у вас патч на ядре, для софтварной защиты от переполнения стека, который тормозит jdk.

> Вообще хотелось показать, что сравнивать яву и C++ на синтетических тестах довольно сложно, нужно учитывать массу факторов. Это если действительно сравнивать, а не миссионерством заниматься.

Я не говорил что претендую на многофакторное сравнение. В этом тесте специально сделал упор на то что используется в С++ и Java программах примерно одинаково (как показывает практика, в C++ очень редко применяют механизмы используемые в вашем допинге, т.к. они серьезно затрудняют разработку) и в большом колличестве.

Если бы я хотел сделать синтетических тест в котором Java порвала бы C++, я бы активно использовал garbage collector. Но на C++ тоже легко можно порвать Java, например масивом классов как было предложено выше.

Исходя из этого в реальных бизнес проектах (хотя бывают исключения) Java будет быстре как по скорости работы, так и по скорости разработки, я уже не говорю про отладку ;-)

>> отпарирую так: можно применить более сложную в реализации, не меняющую порядок обьектов оптимизацию, перегрузив операторы new & delete.
>А что будет если потребуется удалить 90% обьектов, в произвольном порядке ?
Ну будет список из count*0.9 указателей на память, которую можно занять.

> Конечно, перегрузив операторы new & delete, можно реализовать специальный алгоритм allocator-а на этот случай, но не стоит забывать что процессор может быть и не один, и если вы хотите конкурировать с jvm allocator одним глобальным mutex вы не отделаетесь, а условие задачи (требования заказчика в реальной жизни) в процессе раелизации этого всего может и изменится.

А вообще... ни на одном другом языке нельзя написать аллокатор, похожий на аллокатор jvm? :\ Чем же ограничены C++ программисты?

> Да не забудьте о времени на тестирование и отладку, даже ваш не очень сложный допинг не лишен ошибок: ...
Забавно, да... но это не относится к тому, кто быстрее. Как раз с тем, что на java быстрее и дешевле разрабатывать программки, никто не спорит.

> Возможно у вас патч на ядре, для софтварной защиты от переполнения стека, который тормозит jdk.

Никаких патчей, vanilla kernel. Единственное - glibc поддерживает nptl.

> А может я эти цифры придумал ? Поищите в google другие benchmark-и почему то их результаты схожи с моими, а такой провал в скорости jdk похоже только у вас :?

Попросил проверить приятеля... получилось примерно то же самое.
Цифры я не придумывал, может быть кто-нибудь еще их подтвердит?

> Ну будет список из count*0.9 указателей на память, которую можно занять.

Занять ее к сожелению можно будет далеко не всем и не стандартным способом.

> А вообще... ни на одном другом языке нельзя написать аллокатор, похожий на аллокатор jvm? :\ Чем же ограничены C++ программисты?

Тем что у них нет C++ VM ;-) т.е. аллокатор не может знать и использовать runtime информацию, а так же прозрачно "двигать" объекты в памяти.

Вообще, в теории, VM доступно на порядок больше оптимизаций чем обычному компилятору. Хотя jvm относительно не давно стала конкурировать с C/C++, у нее еше большой потенциал для развития.

> Попросил проверить приятеля... получилось примерно то же самое. Цифры я не придумывал, может быть кто-нибудь еще их подтвердит?

Может дело в памяти ? У меня 1 гиг, расход памяти 512 + jvm, может стоит уменьшить count и -Xm...