LINUX.ORG.RU

Это не новость, господа!

birdie ★★★★★
()

Если удаётся добиться ТАКИХ приростов производительности, то говорит это об одном: продукт изначально был реализован (а как бы и не спроектирован) х.рово. И не факт, что он не перестал быть таковым. Это действительно повод. Усомниться в целесообразности его использования. :)

yozhhh ★★★
()

Еще на 58% или это старая новость?

eXOR ★★★★★
()

Посмотрев на прирост производительности ServerVM не вижу никаких 58%. А вижу несколько процентов.

А что, кто-то еще пускает свои приблуды не с -server?

Mossy
()
Ответ на: комментарий от pitekantrop

>В большинстве десктоп-приложений приятнее работать с -client.

А в JRE, которая у клиентов нет ServerVM

forgiven
()

не верю

Pi ★★★★★
()
Ответ на: комментарий от yozhhh

Откуда такие делеко идущие выводы?! Вроде бы давно было известно, что во многих случаях клиентская VM вела себя хуже серверной. Теперь это не так.

Кстати, по ссылке написано, что ускорение может быть связано с тем, как x86-процессоры (P-IV) оптимизируют выполнение кода на уровне чипа. Оказалось, что новое распределение регистров уж очень способствует процессору в такой оптимизации. А ты тут начал...

D
()

> Sun улучшила производительность HotSpot на 58%. Это повод господа )

Типа молодцы - глядишь, Azureus да Eclipse побыстрее работать начнут =)

int19h ★★★★
()
Ответ на: комментарий от int19h

>> Sun улучшила производительность HotSpot на 58%. Это повод господа )

>Типа молодцы - глядишь, Azureus да Eclipse побыстрее работать начнут

Cкачай Eclipse 3.1 (3.1.1) он стал очень резвый. IMHO мало IDE могут похвастатья такой скоростью при работе с большими проектами.

Azureus и так шустрый.

Yilativs ★★★★
()
Ответ на: комментарий от Yilativs

> Cкачай Eclipse 3.1 (3.1.1) он стал очень резвый.

Оно и стоит - недавно наконец-то в Debian unstable появилось.

> Azureus и так шустрый.

Кому как. С Eclipse аналогично. Т.е. все неплохо, но хочется большего.
SharpMusic вот не тормозит... ;)

int19h ★★★★
()

Смотрится странно, цифры из Client JSE 6.0 build 59
точно такие как в Server J2SE 5.0 Update 5 ....
А вообще если float производительность исправили, то молодцы, раньше был полным отстоем

gopakita
()
Ответ на: комментарий от Nuke

> Это не так. Даже всякие там простенькие freemind быстрее летают с -server.

Не знаю, как ведет себя freemind, не использовал никогда. Но на глаз заметно, как IDEA втыкает с -server.

В двух словах отличие -server от -client в том, что, во-первых, используются более агрессивные оптимизации (отсюда вытекает, что время самой оптимизации возрастает), а, во-вторых, код должен выполнится болшее число раз, чтобы его признали hotspot'ом.

К тому же Class data sharing в 5.0 поддерживается только -client VM.

Если бы с -server было бы так все замечательно, в Sun с -client бы не парились.

У меня даже на полностью 64-битной системе (AMD64) специально стоит еще и 32-битная JVM. В 64-битной JVM -client не поддерживается, а тормоза -server для GUI терпеть желания нет.

pitekantrop ★★★
()

скорость света превышена? а я думал, это невозможно...

--седайко стюмчик

sedajko_stjumchik
()
Ответ на: комментарий от pitekantrop

pitekantrop дело говорит. сервер почти всегда был фуфлом... в мустанге понавтыкали кучу пробов в код, чтобы серверный hotsopot чему-то учился

--седайко стюмчик

sedajko_stjumchik
()
Ответ на: комментарий от yozhhh

>Если удаётся добиться ТАКИХ приростов производительности, то говорит это об одном: продукт изначально был реализован (а как бы и не спроектирован) х.рово. И не факт, что он не перестал быть таковым. Это действительно повод. Усомниться в целесообразности его использования. :)

Не обязательно. Может JVM теперь в 10 раз больше памяти потребляет на всякие хитрые кэши? :)

WFrag ★★★★
()
Ответ на: комментарий от WFrag

>Может JVM теперь в 10 раз больше памяти потребляет на всякие хитрые кэши?

да не... они более эффективно используют регистры + escape анализ

--седайко стюмчик

sedajko_stjumchik
()
Ответ на: комментарий от D

>The improvement in the sub-tests Sparse matmult (2,9X faster) and LU factorization (2,8X faster) are even more noticeable; these two tests are heavy in array manipulation. I'm not sure why arrays improve so much, but my bet is that the better register allocation, causing fewer reloads of array and index variables, plays well with CPU optimizations like data prefetching and instruction-level parallelism.

Почти в 3 раза скорость увеличилась при работе с arrays. Интересно. Кстати, судя по таблице на сайте, то скорость этих операций в 431 и 432 упала по сравнению с 410 (используя -server).

McGray ★★
()
Ответ на: комментарий от McGray

Интересно то, как может быть устроена эта "CPU optimization", и что нужно программистрам, чтобы она заработала в их программах. Из того блога можно предположить, что Mustang стал быстрее на x86, причем на вполне определенном типе процессоров. Любопытно, как поведут себя на тех же тестах более "производительные" атлоны?

D
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.