LINUX.ORG.RU

Гослинг доволен производительностью Java

 , ,


0

1

Согласно последним замерам в некоторых тестах (например расчет сглаженных сплайнов), Java-вариант обходит FORTRAN-вариант на ~10%. Таким образом, учитывая надежность кластерных решений на JVM, платформа Java уже вполне пригодна для High Performance Computing.

>>> Подробности

anonymous

Проверено: Shaman007 ()
Ответ на: комментарий от anonymous

> Почему ОС? ОС чтоли заставляет компилятор не инлайнить только нужную процедуру?

Естественно. Библиотеки - вообще не компиляторова ума дело, с этим к линкеру. В современных ОС линкеры - часть ОС.

> Самый деревянный пример. Есть у тебя процедура, в начале push все используемые регистры, в конце pop все испольуземые регистры. Когда кодишь на асме, можешь выкинуть push/pop на те регистры, которые не важны для остального кода.

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

anonymous
()
Ответ на: комментарий от Absurd

>Можно избыточный перформанс современных машин жавой утилизировать =)

Вот только, давайте откровенно - у многих ли из тут присутствующих на компах лежат демки, написанные в последние... Ну, хотя бы 5 лет? :)

У меня - пара штук максимум.

У знакомых - ни одной.

А вот 15 лет назад у меня была коллекция во многие десятки образцов (и это во времена отсутствия не только Интернет, но даже FIDO и BBS). И хотя бы несколько демок было практически у каждого знакомого.

Много ли было в то время пользователей, у которых не было бы хотя бы mars.exe? :)

Вот такой уровень - это жизнь. А то, что сейчас - призрачное существование :)

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

> Вот только, давайте откровенно - у многих ли из тут присутствующих на компах лежат демки, написанные в последние... Ну, хотя бы 5 лет? :)

У меня таких два десятка как минимум, коллекционирую всё, что с процедурной генерацией связанно.

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

>Самый деревянный пример. Есть у тебя процедура, в начале push все используемые регистры, в конце pop все испольуземые регистры. Когда кодишь на асме, можешь выкинуть push/pop на те регистры, которые не важны для остального кода.

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

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

>У меня таких два десятка как минимум

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

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

> Именно современных?

Да, с тусовок 2003, 2005 и 2006 года. Ну и парочка совсем свежих, от авторов, которые ещё не демонстрировались публике.

> Ну, тогда ты неимоверно крут :)

У меня просто друзья демосценщики

> Но, увы, сегодня большинство пользователей даже не слышало про демосцену.

А она, при этом, таки существует. Вот ведь парадокс.

anonymous
()
Ответ на: комментарий от Macil

>Обогнать ассемблер это однозначно мощно. Нобелевскую премию авторам.
Программу написанную вручную на RISC асемблере обгонит не только Java.
Компиляторы уже давно сравнимы по скорости с асемблерами а Java имеет ещё и то преимушество что при исполнении может оптимизировать под конкретную среду исполнения.

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

>>Когда кодишь на асме, можешь выкинуть push/pop на те регистры

>Современные компиляторы

Да какие «современные»... Уже к середине 1995-го _все_ популярные компиляторы так делали. Вообще, примитивная оптимизация enter-leave - это ещё что-то к уровню Borland 3.1 восходит, а уже к Watcom 10 жонглирование регистрами шло во весь рост. Я иногда при программировании на ассемблере тупо перенимал некоторые любопытные приёмы у этого компилятора :)

KRoN73 ★★★★★
()
Ответ на: комментарий от botrops-schlegelii

>а что для 32-x bit`ой версии этого asm`мового чуда требовалось 32MiB RAM для уверенной работы - это как ?

Ну там гуй и все дела

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

>А она, при этом, таки существует. Вот ведь парадокс.

А я и не говорил, что она не существует :) Я говорил, что такое существование сложно назвать жизнью. В сравнении с былым величием :)

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

А я щетаю, шо сейчас расцвет демосцены. Ты считаешь в относительной мере - да, мало кто вообще про демосцену слышал. А посмотри на абсолютные величины - сейчас народу гораздо больше, чем 15 лет назад. Просто вообще пользователей больше несоизмеримо, и демосцена незаметна.

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

>А посмотри на абсолютные величины - сейчас народу гораздо больше, чем 15 лет назад.

Это да. Но 15 лет назад достичь популярности и получить массовую оценку было проще. А это - основной стимул демомейкеров :)

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

>Любой, кто игрался с асмом под DOS скажет тебе, что ты не прав.

Деточка, я писал в машкодах еще под К1801.

>Ни один компилятор не выдаст такой компактный бинарник, как ассемблер Сколько там под DOS "привет мир" занимал? 5 байт + размер текста? :)

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

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

>Ну, во многих быдложелезках JVM вполне нативен.

Ну значит он на 100% нативный :)

r ★★★★★
()

> Java-вариант обходит FORTRAN-вариант на ~10%.

Что-то не то с Фортраном - cовсем медленным стал :(

Byron
()
Ответ на: комментарий от anonymous

>я писал в машкодах еще под К1801.

Ну, там машкоды красивые... Халява... А вот что на счёт 1816ВЕ49? :) Вот уж где была система команд, после которой даже 8080 - это рай :D

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

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

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

>Дык кэш-то забивается кодом. А кэш влияет на производительность. Забив его лишним кодом можно затормозить выполнение за счёт большего числа операций с основной память..

Практика показывает, что unrolled loops и inlined functions дают достаточно выигрыша, чтобы с лихвой перекрыть cache misses по загрузке кода после своей работы. Об оптимизации по размеру (точнее отказу от разворота циклов и прочих тяжелых вещах) стоит думать лишь в том случае, если мы в кеше ну _очень_ ограничены - что применимо разве что к обрубкам P4 (селеронам)

anonymous
()
Ответ на: комментарий от rtc

>>Ты не понимаешь. Очень удобно и приятно вести разработку веб-приложения на линуксе, сдать заказчику и не ипать свой мозг ОС на сервере.

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

начни лучше с примеров! что тащит именно приложение, а не JVM?

пока единственное серверное приложение такого рода виденое мной - проприетарнай VoIP сервер (работал только под Win 32bit).

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

>Вот только, давайте откровенно - у многих ли из тут присутствующих на компах лежат демки, написанные в последние... Ну, хотя бы 5 лет? :)

У меня есть, даже разбито по категориям: 128,4k,64k,dosonly,...

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

>dosonly - в последние пять лет? OMG! Вот такого я не видел...

Ну так у тебя же linux - что тут непонятного?

anonymous
()
Ответ на: комментарий от VoDA

aTunes - исплняемый файл mplayer`а.
ps
Ну пусть, что тормоз, и, что к нему JRE нужно - зато кроссплатформенный; ан нет - нужно исполняемые файлы кодеков, под конкретную платформу.

botrops-schlegelii ★★
()
Ответ на: комментарий от anonymous

>> корпоративный рынок(Oracle, IBM, SAP, Red Hat, Sun) = Java.

> Думаешь, сказанул красивые грозные словечки "корпоративный рынок", и все сразу запугались да зауважали? Лучше бы тебе иметь представление о том, что такое интерпрайз изнутри. У жабы там своя конкретная ниша, но никто не скажет, что она рулит везде и во всём. Полно задач, к которым её и близко не подпускают. Особенно их полно в финансовой сфере.

Как раз в финансовой сфере очень много чего на java крутится. И *некоторые* мобильные операторы работают на java (что у них унутря не знаю - у них проходил собеседование, НО штат программистов это дело девелопящих - порядка сотни).

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

Да не, большая часть демок в моей коллекции под винду. Не знаю никого, кто писал бы сейчас демки под дос.

anonymous
()
Ответ на: комментарий от VoDA

> Как раз в финансовой сфере очень много чего на java крутится.

Много, да. А много того, где Жаба противопоказана.

> И *некоторые* мобильные операторы работают на java (что у них унутря не знаю - у них проходил собеседование,

И у них внутрях много чего. Я даже видел железку с аппаратным XSLT у одного очень большого и глобального оператора. Вот чего нигде и никогда не видел - так это тотального перехода на Жабу. Всегда остаются задачи, куда она не лезет совершенно.

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

>Демосценщику нужно признание других демосценщиков

Это сегодня. Когда простые юзеры и не знают про демосцену :) Остаётся довольствоваться признанием своей тусовки...

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

>Вот чего нигде и никогда не видел - так это тотального перехода на Жабу.

А в истории было хоть где-то, хоть одно программное решение с тотальным переходом на него? :)

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

> На машине с процессором x86 1550MHz и оперативкой 768 Mb eclipse , при открытии проекта "hello world", тормозит люто и в конечном итоге выбрасывает сообщение, что недостаточно памяти. Конечно сраный eclipse заведется на 2х ядерном процессоре с двумя гигабайтами оперативы

На машине Cel 1700 с 512Mb оперативки сраный эклипс ганимед при открытии проекта из ~100 классов не тормозит и сообщение не выкидивает что памяти мало. Да и чего бы ему на память жаловаться, если он ~150Mb отгребает, а опера с 30 вкладками ~180Mb.

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

А vuze на днях поставил из-за проблем ktorrent-а с torrents.ru, так со страху сразу закрыл и больше не запускал. Этим ребятам-разработчикам автоуборщик мусора в яве всеравно не поможет.

xintrea
()
Ответ на: комментарий от anonymous

>Да не, большая часть демок в моей коллекции под винду. Не знаю никого, кто писал бы сейчас демки под дос.

А вот демки под линупс никто не пишет. Что говорит о том, что Ъ-программистам он ни йух не сдался.

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

>Кэш процессора.

Страшно подумать сколько должен корячится asm-кодер чтобы хотя бы наполовину заполнить _кодом_ кеш современного процессора _LOL_

Мы уж как нибудь на "переносимом макроассемблере"(С) в случае чего ;)

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

>> Как раз в финансовой сфере очень много чего на java крутится.

> Много, да. А много того, где Жаба противопоказана.

Возможно. Нельзя объять необъятное. В некоторых *редких* случаях частное решение лучше общего. Тогда и используются специализированные языки.

>> И *некоторые* мобильные операторы работают на java (что у них унутря не знаю - у них проходил собеседование,

> И у них внутрях много чего. Я даже видел железку с аппаратным XSLT у одного очень большого и глобального оператора. Вот чего нигде и никогда не видел - так это тотального перехода на Жабу. Всегда остаются задачи, куда она не лезет совершенно.

Конечно, только по мере улучшения ПЛАТФОРМЫ и прикладных библиотек все больше задач можно эффективно решить на java. Особенно уровня enterprise.

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

>и не ява, а джава. к логопеду?

Не ява и не джава. А Жаба. К герпетологу.

anonymous
()
Ответ на: комментарий от KRoN73


> А в истории было хоть где-то, хоть одно программное решение с тотальным переходом на него? :)


все кто писал на борланд с++ 3.1 тотально переходили на борланд с++ 3.5:)

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

> Интересно, куда подевались все те фанатики визжащие про емакс и _правильных адекватных кодеров_.

> Ребята, вы где? Образ _адекватного разработчика_ по прежнему не раскрыт.

возможно, этот образ только у тебя в мозгу. не крикнул бы - никто и не вспомнил.

anonymous
()

Прошу прощения, но кто-нибудь читал ссылку и препринт по ней?

Информация про 10-ти процентное ускорение по сравнению с Фортраном там просто приведена в комментариях одного пользователя на совсем другое сообщение.

Оригинальный пост по ссылке "Подробности" к этому утверждению отношения не имеет, в препринте, опять же, про это ни слова. Так же как и в посте Гослинга. Опять же, в препринте не утверждается какое-либо превосходство Явы над Фортраном. Основное заключение препринта --- это то, что дела в Яве стали гораздо лучше, и отрыв не такой большой, как раньше. Слово "сплайн" в нем каким-то образом не обнаруживается.

Каким боком в виде новости указывается перевод ничем не подтвержденного коммента непонятно какого человека ---- а в виде "Подробностей" дается нечто, не имеющее ничего общего ни с самим этим комментом, ни с текстом новости?

gene
()
Ответ на: комментарий от KRoN73

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

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

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

А если попросил бы, то оказалось, что жабокодеры этот велосипед уже изобрели (AspectJ + JIT).

nosuchuser
()
Ответ на: комментарий от VoDA

> В некоторых *редких* случаях частное решение лучше общего. Тогда и используются специализированные языки.

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

> Конечно, только по мере улучшения ПЛАТФОРМЫ и прикладных библиотек все больше задач можно эффективно решить на java.

Это не так. Платформа не улучшается, более того, у нее и потенциала к улучшению нет, благодаря изначально кривому дизайну.

anonymous
()

Да, кстати, --- никакие замеры дающие эти 10% там не естественно не приведены. Ссылки на них тоже нет.

Для тех, кто, по ссылкам не ходит:

Оригинальный пост Гослинга:

--- Current State of Java for HPC

At the last JavaOne I did a walk-on talk during the AMD keynote where I talked about how incredible HotSpot's performance had become - beating the best C compilers. I ended my talk with a joking comment that "the next target is Fortran". Afterwards, Denis Caromel of Inria came up to me and said "you're already there". He and some colleges had been working on some comparisons between Java and Fortran for HPC. Their final report Current State of Java for HPC has been made available as a Tech Report and makes pretty interesting reading. There are a lot of HPC micro benchmarks in it which look great. Thanks! Permalink Comments [3] ---

Обратим внимание на "_micro_ HPC bemchmarks".

А вот источник якобы новости:

You might be interested in SASA, a project to port the DIERCKX library of Fortran subroutines for calculating smoothing splines - without tuning the Java code, I'm see roughly 10% improvement against the original GCC-compiled fortran.

Roberto

Posted by Roberto Tyley on September 04, 2008 at 08:33 AM PDT

Кто-то там чего то типа увидел...

gene
()
Ответ на: комментарий от r

>все кто писал на борланд с++ 3.1 тотально переходили на борланд с++ 3.5:)

Неправда! Многие переходили на Watcom. А вот с Turbo C на Borland C, действительно, переходили все :-)

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

> А вот демки под линупс никто не пишет.

Пишут, пишут. Только мало. Под линукс появился даже новый жанр демок - 4k source. 3D-демки под линух писать напряжно, поскольку нет DirectX, в котором до фига полезных функций на халяву. Если использовать OpenGL+GLUT и OpenAL или ещё что аналогичное, то много тривиальной функциональности приходится тащить в свой код, от чего размер страдает.

anonymous
()
Ответ на: комментарий от KRoN73

> А в истории было хоть где-то, хоть одно программное решение с тотальным переходом на него? :)

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

anonymous
()
Ответ на: комментарий от r

>все кто писал на борланд с++ 3.1 тотально переходили на борланд с++ 3.5:)

Не все. Я про 3.5 даже не слышал. Я тотально перешёл на Watcom, кажется, 9. Или сразу на 10 уже... Давно было.

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

>А и раньше простые юзеры не могли оценить. Надо ведь понимать, чего стоит засунуть все это в 4к

Понимали. Это было время, когда работа юзера не сводилась к нажатию на ярлык программы. И что такое размер программы и как он соотносится с насыщенностью программы понимали практически все. Юзер тогда был совсем другой :)

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