Техническая статья Sun «Делаем Java быстрее чем С, используя LRWP»

> Формально подходя, такое может быть. А фактически? Это представьте, мы создали класс Фигура с виртуальным методом "вращать". А приложение взяло, и изготовило фигуру только одного типа -- квадрат? Такое в жизни бывает?

Эх, "молодо-зелено" :) (это не оскорбление - скорее зависть) - именно это и заявляют санки и именно это и показал тот тестик на который я уже несколько раз ссылался. Т.е. ВМ в процессе работы определила, что других фигур кроме квадрата в данной задаче нет и заинлайнила (вернее - сделала всё статичным, а что сочла нужным - заинлайнила) в памяти все методы фигур и квадратов, а потом ежё и компильнула всё это в натив.

>Либо тянуть за собой все/большинство "хвостов", а многие из них могут быть сами по себе большими ограничениями...

Это исскусство. И хвост тянуть, и новое ввести, и чтобы все это стройно было (понятно, что чуток хвостов и обрезать придется)

всё, сорри, было приятно поболтать, но пора спать

возможно завтра продолжим ;)

(можно не отвечать ибо ответа ждать не буду :)

>> Формально подходя, такое может быть. А фактически? Это представьте, мы создали класс Фигура с виртуальным методом "вращать". А приложение взяло, и изготовило фигуру только одного типа -- квадрат? Такое в жизни бывает?

>именно это и заявляют санки

Так все-таки! Где вы видели такой код в реальной жизни? Виртуальные методы делаются только для того, чтобы наобъявлять кучу наследников. А санки сделали такую оптимизацию для того, чтоб успешно решить проблему, которой в С++ вообще нет.

>Предположение: возможно имелись в виду [в том числе и] "лэйаут-менеджеры" - "диспетчеры компоновки", коих [до определённого момента] не хватало в прочих тулкитах после tcl/tk.

Не только. Настоящий MVC (первый после смоллтолка), очнь грамно спроектировано - рендереры, модели, возможность вкладывать все что угодно во все што угодно комбинируя компоненты и т.д.

>Но где те решения, которые есть в свинге, и нет в КуТе?

Qt сейчас приближается к свингу по удобству. Но аргумент высказывался как возражение на аргумент что "не имеет столько поклонников, чтобы допилить его хотя бы до уровня GTK+/GNOME и QT/KDE ". Его не надо допиливать - это Qt и GTK ростет до уровня свинга.

>Будем считать?

Ты прочитал то что я написал относително гномоводов и кдефилов? Давай посчитаем сколько в дистрибутиве виндовса програм на куте и гтк и сделаем далекоидущие выводы отноительно этих тулкитов.

>Вся эта ява -- это С++ вместе compaсting gc, дополненный ограничением: нельзя брать адрес, можно только shared_ptr и weak_ptr.

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

>>Но где те решения, которые есть в свинге, и нет в КуТе?

>Qt сейчас приближается к свингу по удобству.

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

>Но аргумент высказывался как возражение на аргумент что "не имеет столько поклонников, чтобы допилить его хотя бы до уровня GTK+/GNOME и QT/KDE ". Его не надо допиливать - это Qt и GTK ростет до уровня свинга.

Qt customers include Adobe®, Google™, Skype™, Lucasfilm®, NASA, Walt Disney® Feature Animation, Siemens, Mathematica and thousands more. А Нокия купила их целиком за $153 000 000.

Все они могли бесплатно юзать свинг в закрытых аппликухах (LGPL). Ну что -- в этих компаниях дураки сидят, или есть какие-то свои преимущества в КуТи, за которые Нокиа выложила нехилую сумму?

Кстати, дизайн в свинге может быть и не плохой, у санок есть академический такой уклон в сторону грамотного дизайна. Я думаю единственное преимущество Кутей -- то что все не хотят жирной и тормозной Явы™. Если вы несогласны, объясните, за что Нокия выложила $153 000 000.

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

Поточнее пожалуста, а то в конечном итоге все аппликухи на всех языках пишут в какие-то адреса памяти. Как этот класс называется (сам гляну на его документацию) ?

В вики на ООо написано, что яву в нем можно отключить вообще. Надо попробовать и посмотреть, будет ли он так же тормозить. (http://marketing.openoffice.org/2.0/featureguide.html)

>Ну %#дь, а напряжение в сети ты тоже на язык проверяешь? НЕ НАДО ТЕСТИРОВАТЬ - надо почитать из первоисточника для чего ОО использует java. А твои догадки... Ладно, короче - ты неправ.

Почитал первоисточники... http://en.wikipedia.org/wiki/OpenOffice.org -- не только я считаю его тормозом за счет явы.

OpenOffice.org has been criticized for slow start times and extensive CPU and RAM usage in comparison to other competitive software such as Microsoft Office. In comparison, tests between OpenOffice.org 2.2 and Microsoft Office 2007 have found that OpenOffice.org takes approximately 2 times the processing time and memory to load itself along with a blank file; and took approximately 4.7 times the processing time and 3.9 times the memory to open an extremely large spreadsheet file.[72] Critics have pointed to excessive code bloat and OpenOffice.org's loading of the Java Runtime Environment as possible reasons for the slow speeds and excessive memory usage.

>Ну что -- в этих компаниях дураки сидят, или есть какие-то свои преимущества в КуТи, за которые Нокиа выложила нехилую сумму?

Вы что думаете потребителей свинга меньше?!

>Если вы несогласны, объясните, за что Нокия выложила $153 000 000.

За мобильную платформу Qtopia под собственный контроль. К стати сразу после этого она купила симбиан.

В разработку Eclipse IBM вгрохал $40 000 000 только в первый год. То есть весь тролтех стоил может быть как один эклипс - хорошо если.

>Как этот класс называется (сам гляну на его документацию) ?

Unsafe конечноже:)))

Критикс тоже не в теме.

>Critics have pointed to excessive code bloat and OpenOffice.org's loading of the Java Runtime Environment as possible reasons for the slow speeds and excessive memory usage.

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

>В вики на ООо написано, что яву в нем можно отключить вообще.

кто её вообще включал то при сборке? сборка OO с java - опциональная.

К стати редхат за галимый (ну в смысле не пуп земли) j2ee сервер отвалил 360M$ что в 2 раза больше трольтеха. Вот странно да - голимая тормозючая жаба ему понадобилась (icedtea тоже их проект) а трольтеха они не купили. Некритично для бизнеса? :)

ну какие деньги можно сделать на qt? да и зачем он им - трольтех. GTK+ вполне годится для разработки GUI программ их корпоративных продуктов. а на десктопы простых пользователей они не суются. а к тому времени как могут решиться - GTK+ и Gnome допилят до нормального уровня. да и минус у qt существенный - его ОО сущность.

Прочитал.
Мы говорим о моём высказывании о том, что "у Java всё плохо на десктопе".

QT, GTK впесте держат 90% -95% Линукс десктопа. И?
Существуют свзни этих обоих тулкитов с Java, но тем не менее люди предпочитают приложения на "медленном" python/perl/tcl но не на "быстрой" Java.

В дистрибутивы Линукса вчлючено в разы(по моим предположениям) больше приложений на mono, которое буквально несколько лет назад достигло стабильности, чем на Java у которй 15 лет за плечами.

Вывод напрашивается сам собой. Во всяком случае у меня. "у Java всё плохо на десктопе".

ps.
Не спится?

>Существуют свзни этих обоих тулкитов с Java, но тем не менее люди предпочитают приложения на "медленном" python/perl/tcl но не на "быстрой" Java.

кто эти люди? видимо те, кто освоил только скриптовые языки. программы на java стабильны. поделия на питоне и perl часто безобразно глючат. медленное, неэффективное приложения можно написат и на асме (тут кажется были примеры. или не тут но в одной из тем где вы разговаривали про java недавно)

>QT, GTK впесте держат 90% -95% Линукс десктопа. И?

есть удачные программы на GTK+ (ну сделаем вид что есть), на QT, на Java. зачем использовать поделку если ест ькачественные программы на другом тулките/платформе. может появятся нужные мне программы и на моно. пока не вижу таких.

> кто эти люди? видимо те, кто освоил только скриптовые языки. программы на java стабильны. поделия на питоне и perl часто безобразно глючат.

Врать не хорошо.

Deluge (Python) - одни из лучших клиентов по мнению пользователей, по крайней в среде Linux.

zim (Perl) - для меня просто не заменимая вещь. Не видел не единого глюка, работает как часы.

OrnamentBook (Python) - моя любимая читалка.

Anki (Python) - мой личный мозговой тренер.

Но вот на днях поставил все таки Azureus. Во-первых, вы тут уверяли ой какая она стабильная. Но пользователи на torrents.ru совсем другого мнения - проклинают эту лягушку написанную на жабе как только могут. Вплоть до того, что с ней вообще работать нельзя, падает на ровном месте. Но я все таки ей стал пользоваться. А знаете почему? Из жалости к жабе. Я подумал, пусть будет хоть какая нибудь програмулечка на десткопе, памяти все равно два гига. Впечатления двоякие. Вроде бы не уступает KTorrent (да, у меня Gnome и я не гнушаюсь qt/kde). Но что ж такой интерфейс кошенный-перкошенный? Все съезжает! Половина полей вечна перекрыто! Тьфу.

И jEdit не замена vim. Жалкая поделка, даже самому автору стало стыдно, и он от нее отвернулся. Но, справедливости ради, Столлман тоже отвернулся от Emacs. Туда этой поделке на недоязыкчке гиков и дорога вместе с жабой. VIM жив, VIM будет жить!

И хватит меня обвинять в троллинге.

> Где вы видели такой код в реальной жизни? Виртуальные методы делаются только для того, чтобы наобъявлять кучу наследников.

В конкретном небольшом приложении может быть объявлен только один наследник для некоторого библиотечного класса. "застатичить" код и после оптимизации "занаитить" - не заманчиво ли? :)

> А санки сделали такую оптимизацию для того, чтоб успешно решить проблему, которой в С++ вообще нет.

Нет пока в языке нет множественной диспетчеризации и MOP-а (я знаю что этого и в java нет, я о тех случаях, когда обычный вызов через VMT не пойдёт). Если вы это добавите - подобные проблемы встанут и перед вами "в полный рост". И при _некоторых_ условиях вы начнёте проигрывать по скорости.

> В конкретном небольшом приложении может быть объявлен только один наследник для некоторого библиотечного класса. "застатичить" код и после оптимизации "занаитить" - не заманчиво ли? :)

Типично явовское рассуждение (там любят перед любым классом втыкать интерфейс, хотя это может и полезно, но не по теме). Но я в ТРЕТИЙ РАЗ ставлю вопрос: а нафиг делать с++-метод виртуальным, если будет только один наследник? Мой пример про классы Фигура и Квадрат был именно на эту тему. Если метод "повернуть" у фигуры сделан виртуальным, то вероятность иметь в наследниках один Квадрат близка к нулю. Скорее всего сам автор Фигуры уже понапишет наследников, а прогер, юзающий либку с Фигурой, добавит еще. Так что тут Сан успешно решает проблемы, которых в С++ вообще нет.

>Нет пока в языке нет множественной диспетчеризации и MOP-а (я знаю что этого и в java нет, я о тех случаях, когда обычный вызов через VMT не пойдёт). Если вы это добавите - подобные проблемы встанут и перед вами "в полный рост". И при _некоторых_ условиях вы начнёте проигрывать по скорости.

Что сделали санки я понял. А вот почему множественная диспетчеризация потребует "застачитить" функцию -- не доходит пока что.

> Но я в ТРЕТИЙ РАЗ ставлю вопрос: а нафиг делать с++-метод виртуальным, если будет только один наследник? Мой пример про классы Фигура и Квадрат был именно на эту тему. Если метод "повернуть" у фигуры сделан виртуальным, то вероятность иметь в наследниках один Квадрат близка к нулю.

Я думал что я объяснил... Фигура - в библиотеке в надежде что фигур будет много. Квадрат - в приложении, но он один там такой - приложение _квадратное_, и другого не надо. JVM оптимизирует (в памяти) не только _приложение_, но и код _библиотеки_ - на последнем я и пытаюсь заострить ваше внимание. Без ВМ получить такое практически нереально.

Да, пример выглядит слишком синтетическим. Но с учётом что в программах/библиотеках для JVM классов "до чёртиков", вероятность возникновения и оптимизации подобных случаев ненулевая "однозначно"

> Так что тут Сан успешно решает проблемы, которых в С++ вообще нет.

на сколько "тормознее" вызов метода через VMT? Я просто не в курсе.

> А вот почему множественная диспетчеризация потребует "застачитить" функцию -- не доходит пока что.

Это я уже впереди паровоза бегу - множественная диспетчеризация потребует подбора выполняемого метода в рантайме (если не городить n-мерные VMT), а здесь уже знакомые условия: если мы можем определить, что в данном приложении будет работать только один вариант метода, то почему бы... :)

>Но я в ТРЕТИЙ РАЗ ставлю вопрос: а нафиг делать с++-метод виртуальным, если будет только один наследник?

А какой смысл делать невиртуальный метод? В Яве просто - там все методы виртуальные, ненужные виртуальные вызовы заменяются на простые Хот-Спотом. Это многое упрощает.

> QT, GTK впесте держат 90% -95% Линукс десктопа. И?

А виндовс на GDI.dll и что? Никаких ассоциаций? Если вы приехали в германию - очень странно там искать испаноязычных иудивлятся что их там нет. Исторически GTK/Qt это тулкиты операционной системы - и естественно их засилие под эту операционную систему. Это что - не ясно?

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

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

> Вывод напрашивается сам собой.

Да - вы абсолютно не хотите видеть фактов в угоду своим суевериям.

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

вы забыли что пользователи торрентс.ру - в основном пользователи венды. вечно у них всё падает. когда я гонял Azureus на венде - у меня и там не падало.

>Но что ж такой интерфейс кошенный-перкошенный? Все съезжает! Половина полей вечна перекрыто! Тьфу

меняйте шрифт в конфиге GTK+

>И jEdit не замена vim. Жалкая поделка, даже самому автору стало стыдно, и он от нее отвернулся.

кому что удобно. ругать vim не буду. говорят раньше были ещё более ужасные текстовые редакторы популярны

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

/tommy

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

Не уверен.

javax.swing.SwingUtilities.java:

/* Don't make these AppContext accessors public or protected --
* since AppContext is in sun.awt in 1.2, we shouldn't expose it
* even indirectly with a public API.
*/
// REMIND(aim): phase out use of 4 methods below since they
// are just private covers for AWT methods (?)

static Object appContextGet(Object key) {
   return AppContext.getAppContext().get(key);
}

static void appContextPut(Object key, Object value) {
   AppContext.getAppContext().put(key, value);
}

sun.awt.AppContext — проприетарный класс, в исходниках отсутствует.
Так называемая "узелок" для Open Source. :))


В файле javax.swing.UIManager.java на каждом шагу используется строка "javax.swing.plaf.metal.MetalLookAndFeel", хотя как приватная константа, объявленная в начале текста, смотрелась бы куда лучше.
Вообще же, имена классов в тексте методов встречаются на каждом шагу, инкапсуляция не соблюдается. Транжиривание ресурсов в виде содания векторов на любой чих и плюк.

Я бы не назвал это хорошим дизайном, тем более "академическим уклоном".


>Я думаю единственное преимущество Кутей -- то что все не хотят жирной и тормозной Явы™.

Затрахали уже этот стереотип.

>Я бы не назвал это хорошим дизайном, тем более "академическим уклоном".

Это мелочи - тому классу 100 лет в обед - конкретные реализации внутри JRE может и не блещут но _дизайн_ свинга очень хороший.

>Да - вы абсолютно не хотите видеть фактов в угоду своим суевериям.
Ок. Какой вывод вы сделаете? Что Java десктоп приложений больше, чем на mono? python? tcl? perl?

>Серьезно? Кроме трех указанных + томбой (которые все подчиняются гномологике которую я уже 3 раза упоминал) слабо перечислить?

Так я предлагал пересчитать. Согласны?

>Что Java десктоп приложений больше, чем на mono? python? tcl? perl?

Я привел линк с длинным списоком. Мало?

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

>Так я предлагал пересчитать. Согласны?

Жабских в дистре моноводов (+packman) на первый взгляд: AJClientGUI, BattleDuel, BidNobble, Art of Illusion, aTunes, Breakage, AudioCutter, Azureus, BilderHerunterlader, BJJ, Blue, bolzplatz2006 (футбол мля!), Buddi, Capivara, Cassiopea, CDnavigator, DataCrow, Eisenkraut, Free Colonisation, FreeJ, Frinika, FrostWire, GameExtractor, GFP, GuitarCodex+, GuitarScaleAssistant, GuitarTeX2, HattrickOrganizer, Hibiscus, Herzog3d, HoloRacer, Improvisor, Jajuk, Jampal, Jaolt, Jarnal, Javadict, Javaprefs, JBidWatcher, jBudget, jDiskDigest, jDictionary, jDVDSlideshow, jFreerails(2), jFTP, jGammon, JGnash, jHaushalt, JIBS, JIExplorer, jKiwi, jlGui, jMathLib, jMeld, jMencode, jMovieBase, jMp3Renamer, jmugen, JNyqIDE, jOrgan, jRipper, jRisk, jSampler, jSkat, jSudoku, jSynthLib, jTagger, Jubler, JUICE, Legatus, mareinternum, MarsProject, MediaSniper, MediaSort, MegaAero, MegaMek, MekMaker, MovieManager, MP3Dings, MpegParser, nplayer, Obantoo, orDrumbox, Oropuro, Passenger, PersonalFinanceManager, phex, planetGenesis, Railworld, RSSOWl, sonnheim, Step-by-Step, SweetHome3d, TrackEditor, TuxGuitar, TvBrowser, VdrAssistant, Venice, VideoMaker, Vuze, Yameg.

Девелопмент: Antsnest, Eclipse, jEdit, NetBeans, popeye, Robocode, svnControl.

Твой ход. Считай.

Если уже одного этого списка в сотню програм яста мало как доказательство факта что _пишут_ на жабе десктопные программы.

У меня нет жавофобии, но из этого списка у меня только Eclipse..., стоял... когдато. Я теперь ненужен?

> привел линк с длинным списоком. Мало?
Я думаю если пересчитать программы написанные на .Net+mono получится больше. Я, конечноже, имею в виду десктоп приложения.

>А вывод такой жаба так же готова для десктопа как и моно. Нет никакой разницы.
Ура!!!!!!!!!!!!

Я об этом и говорил. Другими словами и только о Java, но сути это не меняет.

Про готовность моно мне говорить тяжело, так как я не писал гуёвых приложений ни на моно ни на дотнете и не могу сказать насколько это проблематично получить удобное в эксплуатации приложение.
Azereus, Banshee, F-Spot и прочее говорят что это возможно, но почему-то не распространено.

Из этого вытекает вывод что "Sun просрала десктоп"(С).

С причинаами этого в моей интерпратации можно соглашаться а можно и нет, так как здесь всё гораздо менее очевидно и более субъективно.

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

Это, кстати, говорит, что оновная битва за Линукс десктоп ещё впреди, что внушает некоторый оптимизм по поводу Java на десктопе.

>У меня нет жавофобии, но из этого списка у меня только Eclipse..., стоял... когдато. Я теперь ненужен?

По поводу 95% я уж говорил. А остальные 5% - это экзотические программы вне зависимости от того на чем они написаны. Потому и не стоят на каждом втором десктопе.

Делать что-то серьёзное лениво, потому простой поисл по зависимостям от моно и от жавы - либы показал совсем незначительное превосходство моно. Я, признаюсь, ожидал большего.
Кстати среди моно и жава программ есть КДЕ программы.

Подводя итоги
1. Жава не гова для десктопа
2. Я ошибся, говоря о значительном превосходстве моно программ на линукс десктопе. Превосходство(количественно) незначительное.

Ждём развитя событий!

> А какой смысл делать невиртуальный метод? В Яве просто - там все методы виртуальные, ненужные виртуальные вызовы заменяются на простые Хот-Спотом. Это многое упрощает.

А как запретить возможность перегрузить метод в яве, ежели они все там виртуальные? Никак? Значит явовое ооп сосёт.

>> А какой смысл делать невиртуальный метод? В Яве просто - там все методы виртуальные, ненужные виртуальные вызовы заменяются на простые Хот-Спотом. Это многое упрощает.

>А как запретить возможность перегрузить метод в яве, ежели они все там виртуальные? Никак? Значит явовое ооп сосёт.

Смешно. А как в С++ запретить потомкам перегружать виртуальный метод? В Жаве можно просто закрыть его (final).

>Делать что-то серьёзное лениво, потому простой поисл по зависимостям от моно и от жавы - либы показал совсем незначительное превосходство моно.

Превосходство св студию. Я перечислил сотню _десктопных_ программ - в ответ одни глые заявыления.

>Кстати среди моно и жава программ есть КДЕ программы.

Еслибы я перечислил все зависимости от жабы - их было бы на порядок больше. Я перечислил _десктопные программы с жабным GUI.

>1. Жава не гова для десктопа

Хоть в лоб хоть полбу - невменяемость полная. Сами придумали критерий 'наличие програм в репе' - получили соютнбю программ - сами не удовлетворились.

>А как запретить возможность перегрузить метод в яве, ежели они все там виртуальные? Никак? Значит явовое ооп сосёт.

объявить final.

> Смешно. А как в С++ запретить потомкам перегружать виртуальный метод? В Жаве можно просто закрыть его (final).

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

Абсурд! У тебя есть ссылка на пример на плюсах, где требуется именно финальный класс?

s/финальный класс/финальный метод/

т.е. вы считеаете, что на Java написано больше десктоп приложений, чем на mono/.net?

BTW, вы хотите список приложений на моно+дотнет? или что?
чам ваш список никем не используемых приложений лучше, чем список из дистрибутива? у тех хоть мэйнтэйнер есть.

не берите это так близко к сердцу. мне кажется Сан нарала заниматься этим вопросом и может буть лет через 5-7 воямятся десктов приложения на Java которыми можно будет пользоваться не только из фанатизма или необходимости, но и потопу, что они удобны.

>> Смешно. А как в С++ запретить потомкам перегружать виртуальный метод? В Жаве можно просто закрыть его (final).

>В плюсах такое не нужно.

Нужно. Пишешь допустим скелетную имплементацию интерфейса, реализовав большую часть виртуальных методов. Обойти скелетную реализацию не даешь, объявив реализованные методы как final. В До-Диез такое тоже сделали (seal по моему)