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

>>Давай все-таки объективно. Как ты за 2 строчки напишешь сортировку списка? (мой подход требует 2 строк)

> Яже Вас не заставляю и ничего не доказываю. Нравится - юзайте. Предложить то в замен для десктопа что-то адекватное сложно...

Вот напишешь ты свою СТЛ, прямо таки идеальную. И придет к тебе кто-то, и скажет, что подогнать твою СТЛ под его задачу с помощью написания 2 строчек -- это непосильная задача, его это не устраивает, и поэтому твою СТЛ надо выбросить, и написать новую. И куда ты его пошлешь?

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

У СТЛ есть проблемы, но не такие.

>Ну а потом еще 2 строчки - именованую функцию место лямбды для какого нибудь форич, а потом еще...

1. Мешать все в одну кучу не надо.

2. Вместо лямбды именованная функция может и не прокатить. Тебе придется создавать целый именованный класс!!!

>Тогда их надо на моно перетягивать, все ж легче чем на яву.

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

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

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

ДАже по другому - в первую очередь должна быть технология МS, во вторую подерживаться ву студии все. Если есть говно в студии и хороший аналог без студии 95% предпочтет сидеть на студийном говне. Если есть технология от MS и лучний аналог не от MS - большинство дотнетеров будеть сидеть на технолоии от МС.

> Дело не в этом, а в том что первичен DE а потом уже гуй. QT или GTK никому точно так же был бы не нужен если бы не было DE.

Ы? А про гуевую библиотеку с целью не подмазается под ДЕ, а с целью переносимости ты ничего не слышал? Опера на КуТи идет под виндой, а КуТи десктопа под виндой все еще нет?

> Гуй по нутрям на яве покруче и qt и gtk вместе взятых.

Ссылку можно?

>Ы? А про гуевую библиотеку с целью не подмазается под ДЕ, а с целью переносимости ты ничего не слышал?

Я смотрю все гномовские и KDE шные приложения очень легко и на ура переносятся под венду да? Легко и просто да?

Переносимость либы не является определяющим фактором. И Qt и GTK переносимы - однако большинство фанатов гнома и кде лучше удавиться чем поставит переносимую прогу не на их тулките. Это подвтерждает так же факт что под оффтопик все эти нативные программы пишутся на непмереносимых лоибах при полном присутствии на рынке переносимых.

>Ссылку можно?

На что? Qt во всю несется копируя решения свинга которым уже 10 лет в обед.

> Ну, слишком мало ограничений не получится

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

> для "полноценного" метапрограммирования придётся манипулировать AST-ом

да

> а это только в лиспе выглядит изящно.

нет

> Для сравнения можно глянуть на макры Nemerle - смысл тот-же, но выглядит...

у возможно не получилось

> Так что "высокий порог вхождения" сам по себе уже ограничение.

кхм... вот я против высокого порога

> И, по-моему, любые запреты лучше налагать "административно" (пусть имея для контроля некоторые технические средства) нежели зашивать ограничения физически.

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

>> Гуй по нутрям на яве покруче и qt и gtk вместе взятых.

> Ссылку можно?

Предположение: возможно имелись в виду [в том числе и] "лэйаут-менеджеры" - "диспетчеры компоновки", коих [до определённого момента] не хватало в прочих тулкитах после tcl/tk. В свинге с этим получше. Кто просветит на счёт qt и gtk? (сразу предупрежу - сорри, прямо сейчас маны читать не пойду :)

>Вот напишешь ты свою СТЛ, прямо таки идеальную. И придет к тебе кто-то, и скажет, что подогнать твою СТЛ под его задачу с помощью написания 2 строчек -- это непосильная задача, его это не устраивает, и поэтому твою СТЛ надо выбросить, и написать новую. И куда ты его пошлешь?

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

>Ссылку можно?

>> На что?

На статью, где на примерах программирования с обоими либам подтверждаются твои слова.

>Qt во всю несется копируя решения свинга которым уже 10 лет в обед.

Допустим даже что ты прав. Но где те решения, которые есть в свинге, и нет в КуТе?

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

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

> Я просто высказал, что в С++ мне не нравится неединообразная работа с последовательностями

я объяснил почему так

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

Ты мои ответы читаешь? Я же сказал, НАДО и что это еще в 1990-х можно было сделать.

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

А ты вот как раз самоустраняешься от полезной работы по просвещению меня о моем "фетише" :-)

Ну тогда, если ты знаток лиспа, подумай о том, как реализовать МОП на С++ так, чтобы в случае "статичных" (с точки зрения МОП) классов результат получался по скорости, не отстающий от текущего С++.

Тоже не флейма ради.

>Есть тут люди, имеющие противоположную мне точку зрения на яву, я с ними продолжу общаться.

и не дуйся ты так. соврал - всё равно придется, рано или поздно, это признать. ну в следующий раз так не делай просто.

>> И, по-моему, любые запреты лучше налагать "административно" (пусть имея для контроля некоторые технические средства) нежели зашивать ограничения физически.

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

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

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

Ну я таки имел в виду "порог вхождения" :)

>> а это только в лиспе выглядит изящно.

> нет

Хм, ну и как вы себе это представляете с учётом типизации, свободных/несвободных контекстов, гигиены/отсутствия оной и прочего? Учтите, надо не просто "подставлять имена / куски кода" - надо иметь возможность анализировать/разбирать на куски/склеивать AST, желательно так-же легко, как лисп манипулирует списками :)

>> Для сравнения можно глянуть на макры Nemerle - смысл тот-же, но выглядит...

> у возможно не получилось

Вот именно, что у них _получилось_. И если даже несколько упростить представление AST-а - проще работать с ним не станет. И это при том, что макросистема Немерле таки обладает рядом ограничений...

>> Так что "высокий порог вхождения" сам по себе уже ограничение.

> кхм... вот я против высокого порога

В случае метапрограммирования "низким" его никак не сделать (если только это не "макры" си-препроцессора). Полноценная "метасистема" позволяет "вмешиваться" в процесс компиляции на всех уровнях - одним знанием "как написать макрос" здесь не обойтись.

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

На уровне коллективов/проектов/любых структурных форм - элементарно. А одиночки "решают" всё меньше и меньше.

Принят кем? Массой кодеров? Сразу "забыть": Немерле "слил" C# при практически идентичном синтаксисе и несравнимых возможностях. А жабку переплюнуть практически нереально. Так что вы сначала определитесь с "целевой аудиторией".

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

>Ну тогда, если ты знаток лиспа, подумай о том, как реализовать МОП на С++ так, чтобы в случае "статичных" (с точки зрения МОП) классов результат получался по скорости, не отстающий от текущего С++.

Понятия не имею :)

Отвечу не по порядку:

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

1. Вон у явы столько ограничений -- вообще шаблоны появились года 3 назад, и нечего -- ели, и похваливали (а до того коллекции у безопасной явы были нетипизированные).

2. Прямо позарез нужна не контекстно свободная грамматика? У нее ведь и скорость разбора то существенно поменьше... так что ограничения будут, никуда не деться.

3. Да, вот академически настроенные люди любят что без ограниченй

4. Ограничения я думаю берутся из максимизации отношения Возможности/Затраты

> Ну тогда, если ты знаток лиспа, подумай о том, как реализовать МОП на С++ так, чтобы в случае "статичных" (с точки зрения МОП) классов результат получался по скорости, не отстающий от текущего С++.

Я не он, но (ИМХО) реализовать МОП а-ля в CLOS-е без переноса выбора вызываемого метода в рантайм невозможно. Следовательно - и оптимизация этого дела - тоже в рантайме. А здесь уже рукой подать до управляемого кода и ВМ. (Что частично и подтвердила новостная пенисомерка с джавой - JVM умеет кое-что делать в этом направлении)

> Отвечу не по порядку:

Лучше бы по порядку - "Для кого язык?" :)

>>> а это только в лиспе выглядит изящно. >> нет

> Хм, ну и как вы себе это представляете с учётом типизации, свободных/несвободных контекстов, гигиены/отсутствия оной и прочего? Учтите, надо не просто "подставлять имена / куски кода" - надо иметь возможность анализировать/разбирать на куски/склеивать AST, желательно так-же легко, как лисп манипулирует списками :)

1. Если есть АСТ, то лисп не нужен, и даже вреден, так как синтаксис там ужасный.

2. Типизация -- как в шаблонах.

3. Контексты -- да.

4. Насчет гигиены: в плюсах другая модель связывания чем в лиспе, возможно гигиена и не нужна.

> И это при том, что макросистема Немерле таки обладает рядом ограничений...

Каких?

> Полноценная "метасистема" позволяет "вмешиваться" в процесс компиляции на всех уровнях - одним знанием "как написать макрос" здесь не обойтись.

Я предпочитаю другую модель, слегка утрируюя: "для изготовления макроса назовите его и включите/выключите следующие чекбоксы"

>На уровне коллективов/проектов/любых структурных форм - элементарно.

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

>1. Если есть АСТ, то лисп не нужен, и даже вреден, так как синтаксис там ужасный.

Вот только не начинайте :)

> Лучше бы по порядку - "Для кого язык?" :)

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

>Я не он, но (ИМХО) реализовать МОП а-ля в CLOS-е без переноса выбора вызываемого метода в рантайм невозможно.

Да.

>Следовательно - и оптимизация этого дела - тоже в рантайме.

Нет.

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

> А здесь уже рукой подать до управляемого кода и ВМ.

Нет (только для оптимизаций а-ля llvm)

>Признай - ты их не искал и не смотрел. На смотри http://forums.java.net/jive/forum.jspa?forumID=91
А я про это открыто говорил, что не искал. Мне интересно было, что из десктоп приложений используют читатели ЛОРа.
Перечислять существующи программы, интересная затея, но бессмыссленная, если ими никто не пользуется.

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

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

> 4. Насчет гигиены: в плюсах другая модель связывания чем в лиспе, возможно гигиена и не нужна.

Это довольно _большое_ ограничение - не пользоваться "локальным окружением" места применения макроса.

И вы так и не сказали - как манипулировать AST-ом? Как простыми структурами/объектами? Так даже Немерле будет на порядок удобнее.

> > И это при том, что макросистема Немерле таки обладает рядом ограничений...

> Каких?

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

> Я предпочитаю другую модель, слегка утрируюя: "для изготовления макроса назовите его и включите/выключите следующие чекбоксы"

Меня одолевают смутные сомнения... Вы на лиспе писали? Вот к лисповым макрам добавить типизацию - будет прототип желаемого...

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

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

>>1. Если есть АСТ, то лисп не нужен, и даже вреден, так как синтаксис там ужасный.

>Вот только не начинайте :)

Уточню: консистентность синтаксиса лиспа это плюс, но беднота -- это огромный минус.

Такой синтаксис есть плюс, когда все прогеры меняют структуру программы... но щас все пишут аппликухи, и всем достаточно таких eval, apply и lambda, которым не надо знать структуру исходника. Достаточно адреса функции и изредка стэкового фрейма.

>Меня одолевают смутные сомнения... Вы на лиспе писали?

Я не писал на лиспе. Я его только изучал.

>Вот к лисповым макрам добавить типизацию - будет прототип желаемого...

Верю. Только надо добавить. И еще сделать, чтобы С++ проги с ним дружили (компились в быстрый код, как обычно)

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

> согласен. но для того чтобы что-то ограничивать надо сначала иметь _что_ ограничивать :)

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

> >Следовательно - и оптимизация этого дела - тоже в рантайме.

> Нет.

> Представь С++ прогу записанную с помощью МОП. Очевидно, что этот МОП код может быть оптимизован на этапе компиляции, если дополнительно известны, что эти классы "моп-статичны".

Может быть оптимизирован только _ваш_ МОП-код, но ни как не библиотечный. Всё - труба.

> > А здесь уже рукой подать до управляемого кода и ВМ.

> Нет (только для оптимизаций а-ля llvm)

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

> Верю. Только надо добавить. И еще сделать, чтобы С++ проги с ним дружили (компились в быстрый код, как обычно)

Не с той стороны: макросистема должна позволить написать "встроенный" компилятор C++ кода вне зависимости от совпадения "базового" синтаксиса с требуемым.

> Может быть оптимизирован только _ваш_ МОП-код, но ни как не библиотечный. Всё - труба.

Такой МОП код должен выполнять без оптимизаций, а компилятор -- давать варнинги (или нотайсы).

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

>ДА - это "статическая оптимизация". НЕТ - если её добавить к JVM, то на "синтетических тестах" (а может и не только) при возможности "инлайня" виртуальные методы и используя ту-же статическую оптимизацию при jit-компиляции уже оптимизированного байт-кода JVM (любая другая очень умная ВМ) будет "рвать" любых конкурентов.

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

> Уже сейчас __есть__ что ограничивать.

Так мы "про сейчас" или про то что [возможно] будет?

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

Нет, это ещё и анализ выполняемого байт-кода и его оптимизация в зависимости от текущих (рантайм) условий. А это характеристика исключительно ВМ.

> Не с той стороны: макросистема должна позволить написать "встроенный" компилятор C++ кода вне зависимости от совпадения "базового" синтаксиса с требуемым.

Не понял.

Но если понял -- то это слишком круто.

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

2. Синтаксисы в общем-то должны быть эквивалентными, что-то типа даже взаимно-однозначного соответствия.

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

> Нет, это ещё и анализ выполняемого байт-кода и его оптимизация в зависимости от текущих (рантайм) условий. А это характеристика исключительно ВМ.

А вот без ваших оптимизаций -- О-БОЙ-ДЕМ-СЯ !!! и будет быстрее чем у вас, если не брать экзотику.

>> Уже сейчас __есть__ что ограничивать.

>Так мы "про сейчас" или про то что [возможно] будет?

И про то, и про другое.

> Такой МОП код должен выполнять без оптимизаций, а компилятор -- давать варнинги (или нотайсы).

Сорри, не понял - какой такой? И каике варнинги?

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

Ни кто с этим не спорит. Я лишь о том что рантайм-оптимизация ортогональна статической.

> Не понял насчет инлайна виртуальных методов. Это успешная борьба с трудностями, которых под с++ вообще нет? Если из исходника (С++, не ява) можно догадаться, что тут вирт. метод можно инлайнить -- это можно делать. Но если нельзя догадаться -- то я думаю и инлайнить нельзя... а вы что предлагаете?

Ок: библиотечный код, в "нутрях" - вызов виртуального метода. На момент компиляции библиотеки ничего не известно о переопределении метода у наследников - библиотека! Работающее приложение: ВМ в результате анализа определяет, что у данного библиотечного класса в данном приложении работают _только_ экземпляры одного наследника с переопределённым вирт. методом и переделывает байткод библиотеки инлайня все вызовы данного метода. А вот при jit-компиляции переделанного байткода можно занятся статической оптимизацией :)

> 2. Синтаксисы в общем-то должны быть эквивалентными, что-то типа даже взаимно-однозначного соответствия.

Оопс, это уж слишком толстое ограничение... Нет, тут мне с вами совсем не по пути :)

> А вот без ваших оптимизаций -- О-БОЙ-ДЕМ-СЯ !!!

ясно... Успехов!

> и будет быстрее чем у вас, если не брать экзотику.

Ты бы хоть смайлик поставил. А то я не знаю - то ли мне опасаться за твоё душевное здоровье, то-ли ты стал троллить напропалую... ;)

> >Так мы "про сейчас" или про то что [возможно] будет?

> И про то, и про другое.

Я так понял что только про первое. Второго я просто не вижу - сорри...

> А вот без ваших оптимизаций -- О-БОЙ-ДЕМ-СЯ !!! и будет быстрее чем у вас, если не брать экзотику.

Я имел в виду оптимизации управляемого кода.

А оптимизацию неуправляемого -- пожалуста, а-ля llvm.

> Оопс, это уж слишком толстое ограничение... Нет, тут мне с вами совсем не по пути :)

А у вас что будет, и с какой скоростью оно собирается работать?

> Я имел в виду оптимизации управляемого кода.

Да я понял. Я к тому что вы оставляете конкурентам возможность "таки вас уделать" :)

> А у вас что будет, и с какой скоростью оно собирается работать?

Зная себя... Если не найду достойного проекта - в лучшем случае будет "попытка" =) Про всё остальное говорить вообще не имеет смысла (пока)

> Ты бы хоть смайлик поставил. А то я не знаю - то ли мне опасаться за твоё душевное здоровье, то-ли ты стал троллить напропалую... ;)

Тут надо подумать немного -- и понять, что статическая оптимизация конечно нужна. А что касается скорости -- то даже в идеальном случае маленьких горячих циклов ява отстает.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&...

Да, и с вашей привязанностью к С++ может стоит повнимательнее присмотрется к D? Если его "допинать" - может получится довольно приемлемое решение с умеренными затратами. И можно сразу смотреть на D для llvm :)

> Зная себя... Если не найду достойного проекта - в лучшем случае будет "попытка" =) Про всё остальное говорить вообще не имеет смысла (пока)

А я, тоже зная себя, предпочитаю двигаться мелкими шажками -- например, начать с чего похожего на resyntaxed C++ -- а потом уже браться за такие суперпроекты.

Вспомните про яву, питон и перл -- никакой грандиозности, а вот добились успеха однако. Может и вам стоит начать с чего-то попроще?

>Да, и с вашей привязанностью к С++ может стоит повнимательнее присмотрется к D? Если его "допинать" - может получится довольно приемлемое решение с умеренными затратами. И можно сразу смотреть на D для llvm :)

Присматриваюсь, а как же. Но оно немного не то пока что.

> Тут надо подумать немного -- и понять, что статическая оптимизация конечно нужна.

Истину глаголешь... Только кто с этим спорил? :)

> А что касается скорости -- то даже в идеальном случае маленьких горячих циклов ява отстает.

ну мы же оба были в "Re: Техническая статья Sun "Делаем Java быстрее чем С, используя LRWP"" - тот искусственный тест показал, что анализировать и оптимизировать свой байткод в некоторых случаях JVM научилась очень хорошо. Научили бы ещё санки свои компиляторы такой оптимизации как llvm... :)

> А я, тоже зная себя, предпочитаю двигаться мелкими шажками -- например, начать с чего похожего на resyntaxed C++ -- а потом уже браться за такие суперпроекты.

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

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

> Присматриваюсь, а как же. Но оно немного не то пока что.

Так всё "немного не то". И даже то что вы может и сделаете - тоже будет "немного не то", причём не то что для других - и для вас тоже :)

> На момент компиляции библиотеки ничего не известно о переопределении метода у наследников - библиотека! Работающее приложение: ВМ в результате анализа определяет, что у данного библиотечного класса в данном приложении работают _только_ экземпляры одного наследника с переопределённым вирт. методом и переделывает байткод библиотеки инлайня все вызовы данного метода.

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