Вот по поводу Tools`овин информация:

Не считая одной малости: по словам ведущего системного инженера BEA Systems (Мачей Грушка), JRockit стоит использовать только при наличии глубоких знаний о её внутреннем устройстве и способах её настройки. Я могу прокомментировать: эта jmv может на совершенно ровном месте упасть не пискнув или намертво зависнуть, причём частота таких падений/зависаний удручает.

Короче, господа, есть только одна jvm и делают её в sun ;)

Это сообщение отредактировал(а) w1nd - 22.4.2007, 21:24

В следующий раз, когда он приедет в Москву, я его расспрошу об этом по-подробней.



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

А ты уверен, что Sun`овская не упадёт, активно работая в режиме 24/7 через 2-3 месяца без перерыва?


IBM`овская есть ещё, к примеру...

На моей памяти не падала.


Не поминай всуе, а то ышшо явится  Её ещё толком не юзал, но приконнектиться к ней из sun'овской по корбе... это такая гимнастика для всех частей тела, что я молчу  

Возвращаясь к бенчмаркам. Сегодня тестируется следующий код:



Результаты забегов:


Исходники + бинарники:
http://www.mycoolfotos.com/lzma/repeat_goto.zip (371 KB)

Не понял, к чему это? то должны показать эти результаты?
То, что мобильный проц медленнее? И так понятно. То, что одноядерный АМД 2ГГц медленне двуядерного интела 3ГГц?

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

А что вообще за алгоритм, то? И почему такая странная инициализация массива?

Источником этих тестов служит обсуждение на sql.ru.

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

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

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

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

Полагаю, что в конечном счете код, сгенерированный JIT-компилятором будет более быстрым, чем код сгенерированный классическим компилятором. В классике код генерируется один раз и, соответственно, остается постоянным.
JIT-компилятор же может в зависимости от внешних условий генерировать "изменяемый" код, а значит теоретически и более быстрый. 
Думаю особенно заметно это может быть в приложениях, которые должны работать в режиме 24X7 с надежностью не менее 99,99%
(не более нескольких часов в год простоя).
Там будет возможность собрать статистику вызовов и т.д., чтобы сгенерировать более оптимальный код для часто вызываемых функций, заменить их на inline, параметры не через стек, а в регистах , перегенерить так, чтобы часто отрабатываемый код целиком помещался во внутренний кеш конкретного проца, корректировать механизм выделения памяти и т.д. 

Аналогию можно провести с хранимыми процедурами. Работают быстро, потому что хранимка вроде как "скомпилирована". По большому счету это значит, что уже построен и сохранен план запроса. Соответственно выбраны индексы и т.д. Но это не всегда здорово, т.к. например на момент создания хранимки таблица A, участвующая в запросе содержала всего 15 записей, и план запроса оптимизатором строился исходя из этого. После месяца работы таблицу A раздуло и все, сохраненный план может быть уже далеко не оптимален.

Я это к тому, чтобы не удивлялись поклонники Delphi, а потом и С++ " как это интерпретируемый Java обогнал по скорости компилируемый
Delphi/C++/...".  Это вполне возможно для некоторых классов задач.

В теории это звучит заманчиво, но реализуют ли сейчас интерпретаторы такую функциональность?

Подолью огонька в диалог.
Стоит ли использовать технологию, которую потом приходится обвешивать всяческого рода native библиотеками (мягко намекая на GUI Swing и SWT), тогда уж действительно слогон "compile once - run everywhere" становится не актуальным, более того начинает проигрывать девизу "write once - compile everywhere", хотя справедливости ради замечу, что в 1.5 версии отрисовка GUI становится сносной, а в 1.6 даже шустрой.

Честно говоря, не осилил. Что вы хотели сказать?

Platon, не надо нас переманивать с Java на другие платформы. 
GUI даже на 1.4 можно было нарисовать так, чтобы он особенно не тормозил. Просто, большинство программистов знало, как что-то реализовать в принципе, но не знало, как именно это лучше сделать, чтобы не добавлять лишних тормозов.

w1nd, другими словами хочу сказать, что проще программировать на C++ с помощью Qt, иметь абсолютно родное приложение, при этом написать код один раз и скомпилировать его посредством разных компиляторов.


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

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

ЗЫ: Используя метод от противного. Если принять за истину, что GUI-приложения на Java работают быстро, то нет необходимости в разработке родных GUI-библиотек, что противоречит действительности. => GUI-приложения медленные. ЧТД

А ты в курсе, сколько стоит Qt?   


Малость абстрактно и притянуто за уши, но я скорее согласен, чем нет.