VladD2 wrote: > Сказки не рассказывай. Есть исследовательские работы. Приемуществнно > IBM-овские. Но в ХотСпоте пока что таких оптимизаций нет. Да и анализ > там не постоянный, а при подгрузке типов.
Спорим?
> Слава богу ява не позволяет изменять загруженные классы.
Анализ кода нужен для спекулятивного инлайнинга обычных виртуальных вызовов.
> C>Конечно, для инлайнинга name-based полиморфных функций придется сделать > C>намного больше работы. > Ага. А судя по том, что коропрации вроде MS, Sun и IBM не сделали это > пока для Явы с Шарпом, можно сделать вывод, что задача крайне сложная > если нужны не научные звания, а действительно быстрый код.
Нет, просто сильный интерес к динамическим языкам только недавно
появился. В конце концов, сколько лет прошло от первого JITа до Java JVM
и Strongalk?
> Пол Немерла — это полезное применение макросов. А у тебя не в одном > глазу. Тут дело не в Немерле, а в глазах.
Ну так давайте примеры прикладного кода. Я пока что видел, в основном,
один и тот же пример с байндингом SQL-запроса.
> C> А вот eao197 приводил вполне полезные примеры из > C>своей build-системы. > Скорее, бесполезные. На Немерле можно создать подобную систему и она > даже будет куда более строго контролировать формат выдавая понятные > сообщения об ошибках.
Ну так покажите класс.
Хотя... Можно создать билд-систему на ассемблере, которая будет круче
всех существующих.
> Но зачем это делать кода есть Ant и MSBuild?
А зачем нужен был ant, когда был make?
Здравствуйте, Oyster, Вы писали:
V>>И все из-за невозможности в дотнет использовать интегральных констант в качестве параметров генериков. Тогда бы решалась в лет и можно было бы сделать не пенисонометрии ради, а спокойствия за код для.
O>Да нет же Отсутствие возможности использования скаляров как параметров генериков никоим образом не помешает решить задачу на Nemerle, в котором есть гораздо более развитые средства метапрограммирования. Не надо смотреть на решение задачи под углом C++ — лучше поближе ознакомиться с Nemerle для начала.
Я не про Nemerle, а про дотнет вообще. Эту задачу и на C# можно было бы решить.
Здравствуйте, eao197, Вы писали:
E>Сомневаюсь, что компилятор способен убрать эти проверки для векторов и массивов, чья размерность во время компиляции неизвестна.
Это не вопрос сомнений. Это доказанный факт. Джит распознает паттерн индексации и выносит проверки индекса за пределы цикла.
Проблема только в том, что пока что это делается довольно примитивно. Любые манипуляции с индексом обычно делают оптимизацию недостпной. Но ничто не помешает усложнить алгоритм в будещем.
E> А в большинстве случаев размерности как раз в run-time определяются, и память для них динамически выделяется.
В дотнет и Ява в 100 процентах, так как массивы — это объекты. А все объекты создаются динамически. Правда не загорами оптимизация когда локальные объекты будут создаваться в стеки и инлайниться. Но это уже частности.
VD>>В общем, ясно. Импытываем фобии к управляемому коду и в это время пользуемся одним из самых медленных интерпретаторов в мире.
E>Так я же Ruby не для числодробительных задач применяю
Дык ты и С++ не для них используешь.
E>Видимо у меня другие понятия о красоте, или еще недостаточно Scala покурил.
Думаю, второе.
E>У D есть отличная фишка -- поддержка RAII.
Когда нибудь ты поймешь, что эта фича не столь замечательна чтобы компенсировать остальные просчеты. Заметь все кто на практике пробовал using+IDispose обычно через некоторое время перестают уделять этой фиче огромное значение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>> IBM-овские. Но в ХотСпоте пока что таких оптимизаций нет. Да и анализ там не постоянный, а при подгрузке типов. C>Спорим?
Спорь. А лучше ссылку приведи.
>> Слава богу ява не позволяет изменять загруженные классы. C>Анализ кода нужен для спекулятивного инлайнинга обычных виртуальных вызовов.
Еще раз. Это пока только в планах.
C>Нет, просто сильный интерес к динамическим языкам только недавно появился.
Он не больше чем во времена QBaisic/Turbo Baisic. А про Лисп я вообще молчу.
C> В конце концов, сколько лет прошло от первого JITа до Java JVM и Strongalk?
А столько лет прошло от появления первого скрипта?
C>Ну так давайте примеры прикладного кода. Я пока что видел, в основном, один и тот же пример с байндингом SQL-запроса.
Скачай Немерле и погляди его деректории с исходниками. Там тонны прикладного кода.
C>Ну так покажите класс.
Я не больной на спор делать совершенно не нужные вещи.
C>Хотя... Можно создать билд-систему на ассемблере, которая будет круче всех существующих.
Можно, но сложно.
>> Но зачем это делать кода есть Ant и MSBuild? C>А зачем нужен был ant, когда был make?
По пользуйся обоими — узнашь. Особно прикольно пользоваться make-ом на разных ОС. Знашь почему Цигвин ташит за собой сотни метров утилит?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: >> > IBM-овские. Но в ХотСпоте пока что таких оптимизаций нет. Да и анализ > там не постоянный, а при подгрузке типов. > C>Спорим? > Спорь. А лучше ссылку приведи.
Начнем с Wikipedia:
Its name derives from the fact that as it runs Java byte-code, it continually analyzes the program's performance for "hot spots"
which are frequently or repeatedly executed. These are then targeted for
optimization, leading to high performance execution with a minimum of
overhead for less performance-critical code.
The Hotspot VM begins by interpreting all code, but it monitors
the execution of that code. As mentioned earlier, most programs spend 80
to 90 percent of their time executing 10 to 20 percent of the code. By
monitoring the program execution, the Hotspot VM can figure out which
methods represent the program's "hot spot" -- the 10 to 20 percent of
the code that is executed 80 to 90 percent of the time.
When the Hotspot VM decides that a particular method is in the hot spot,
it fires off a background thread that compiles those bytecodes to
native and heavily optimizes the native code. Meanwhile, the program
can still execute that method by interpreting its bytecodes. Because the
program isn't held up and because the Hotspot VM is only compiling and
optimizing the "hot spot" (perhaps 10 to 20 percent of the code), the
Hotspot VM has more time than a traditional JIT to perform optimizations.
...
The Hotspot VM keeps the old bytecodes around in case a method moves
out of the hot spot. (The hot spot may move somewhat as the program
executes.) If a method moves out of the hot spot, the VM can discard
the compiled code and revert back to interpreting that method's
bytecodes.
Вот статья с тестом, демонстрирующим эффекты HotSpot'а: http://www.javaworld.com/javaworld/javaqa/2003-04/01-qa-0411-hotspot.html
>> > Слава богу ява не позволяет изменять загруженные классы. > C>Анализ кода нужен для спекулятивного инлайнинга обычных виртуальных > вызовов. > Еще раз. Это пока только в планах.
Так, теперь про инлайнинг:
One advantage Hotspot's adaptive optimization approach has over static
compilation is that, because it is happening at runtime, it can use
information not available to a static compiler. For example, even though
there may be 30 possible implementations that may get called for a
particular method invocation, at run-time perhaps only two of them are
ever called. The Hotspot approach enables only those two to be inlined,
thereby reducing the exploding size problem.
> Скачай Немерле и погляди его деректории с исходниками. Там тонны > прикладного кода.
Мне не сэмплы нужны. Нужно реальное приложение, с сильным использованием
макросов.
> По пользуйся обоими — узнашь. Особно прикольно пользоваться make-ом на > разных ОС. Знашь почему Цигвин ташит за собой сотни метров утилит?
Ну вот, билд-система eao197 для С++ намного удобнее ant'а. Сейчас,
правда, я пользуюсь Boost.Build v2, которая еще удобнее.
Здравствуйте, Cyberax, Вы писали:
>> По пользуйся обоими — узнашь. Особно прикольно пользоваться make-ом на >> разных ОС. Знашь почему Цигвин ташит за собой сотни метров утилит? C>Ну вот, билд-система eao197 для С++ намного удобнее ant'а. Сейчас, C>правда, я пользуюсь Boost.Build v2, которая еще удобнее.
Спасибо за добрые слова
Сейчас на rubyforge делается версия 1.1, которая стала еще чуть-чуть удобнее, да и поддержка манифестов VC++8.0 добавилась. Так что, если было что-то, что тебе в mxx_ru не понравилось, то отпиши туда в форум -- попробуем улучшить
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >>> > IBM-овские. Но в ХотСпоте пока что таких оптимизаций нет. Да и анализ >> там не постоянный, а при подгрузке типов. >> C>Спорим? >> Спорь. А лучше ссылку приведи. C>Начнем с Wikipedia:
Неотносящаяся к делу фигня поскипана.
C>Так, теперь про инлайнинг: C>
C>One advantage Hotspot's adaptive optimization approach has over static
C>compilation is that, because it is happening at runtime, it can use
C>information not available to a static compiler. For example, even though
C>there may be 30 possible implementations that may get called for a
C>particular method invocation, at run-time perhaps only two of them are
C>ever called. The Hotspot approach enables only those two to be inlined,
C>thereby reducing the exploding size problem.
Где здесь говорится о том, что ХотСпот делает спекулятивный инлайнинг?
>> Скачай Немерле и погляди его деректории с исходниками. Там тонны >> прикладного кода. C>Мне не сэмплы нужны. Нужно реальное приложение, с сильным использованием C>макросов.
Вот компилятор и есть такое приложение. Он сам на себе создается и использует море макросов.
>> По пользуйся обоими — узнашь. Особно прикольно пользоваться make-ом на >> разных ОС. Знашь почему Цигвин ташит за собой сотни метров утилит? C>Ну вот, билд-система eao197 для С++ намного удобнее ant'а. Сейчас, C>правда, я пользуюсь Boost.Build v2, которая еще удобнее.
Серьезно? А ведь "билд-система eao197 для С++ намного удобнее ant'а"! Что же ты пользуешся чем попало?
А мэйком почему не пользуешся?
Вообще забавный разговор выходит. Мэйк форевар, мэйк крут. Но один велосипед на тему мэйка изобретает, а другой испльзует нестандарткую приблуду из библиотеки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
C>>Сейчас, C>>правда, я пользуюсь Boost.Build v2, которая еще удобнее.
E>Спасибо за добрые слова E>Сейчас на rubyforge делается версия 1.1, которая стала еще чуть-чуть удобнее, да и поддержка манифестов VC++8.0 добавилась. Так что, если было что-то, что тебе в mxx_ru не понравилось, то отпиши туда в форум -- попробуем улучшить
Прими и от меня добрые слова. Маладец! Я тоже пользуюсь не твоей системой, а МСБилдом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Oyster, Вы писали:
V>>Я не про Nemerle, а про дотнет вообще. Эту задачу и на C# можно было бы решить.
O>А смысл говорить про .NET вообще, если речь идёт о Nemerle? Эту задачу и на VB можно было бы решить, если б там были шаблоны со скалярными параметрами
Блин, епрст... Ну ты бы хоть предположил самостоятельно, лучше это было бы или хуже для дотнета... Вернись на пару постов назад и посмотри к чему и как это было сказано...
Здравствуйте, VladD2, Вы писали:
VD>Прими и от меня добрые слова. Маладец! Я тоже пользуюсь не твоей системой, а МСБилдом.
Подтасовкой фактов занимаетесь, правдоречивый вы наш. В исходном сообщении было так:
C>Ну вот, билд-система eao197 для С++ намного удобнее ant'а. Сейчас,
C>правда, я пользуюсь Boost.Build v2, которая еще удобнее.
Спасибо за добрые слова
Спасибо относилось к признанию того факта, что mxx_ru для C++ удобнее ant-а. А так же, запоздалое спасибо за то, что Cyberax в свое время предлагал boost-оводом mxx_ru в качестве build-системы.
То, что лично Cyberax пользуется не mxx_ru, а Boost.Build v2 меня не обижает. Лично ему удобнее. Значит есть что в mxx_ru улучшать.
Ты же пользуйся хоть чем -- твои сексуальный проблемы меня абсолютно не волнуют.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
V>Блин, епрст... Ну ты бы хоть предположил самостоятельно, лучше это было бы или хуже для дотнета... Вернись на пару постов назад и посмотри к чему и как это было сказано...
Шестое чувство мне подсказывает, что решение не позволять использовать целочисленные константы как параметры генериков было сделано неспроста. Конкретно — в MS испугались, что это превратит C# (и VB.NET) в сложный язык, как C++. MS как раз пытается сохранить C# простым. При этом я не говорю, что это правильное решение (возможно, я даже не считаю так). Но я и не считаю, что скалярные параметры генериков это лучшее средство для метапрограммирования. Скорее, наоборот — подход Nemerle (подход Лиспа или Схемы, на самом деле, насколько я понимаю) мне нравится больше.
Кто-то может сказать, что за неимением другого и скалярные параметры генериков прокатят. Но другое-то как раз имеется...
Здравствуйте, Oyster, Вы писали:
O>Шестое чувство мне подсказывает, что решение не позволять использовать целочисленные константы как параметры генериков было сделано неспроста. Конкретно — в MS испугались, что это превратит C# (и VB.NET) в сложный язык, как C++.
Нет, сложность шаблонов в С++ никак не от целочисленных констант, а от:
— возможности полной либо частичной специализации, т.е. иногда НЕОЧЕВИДНО, во что же именно выливается применение шаблона, ибо надо единовременно рассматривать ВСЕ полные либо частичные специализации
— система зависимых типов, т.е. очень много шаблонов (чуть ли не 90%) работает с зависимыми типами, либо вводимыми как typedef т.е. тип-член другого типа, либо выводимыми из namespace используемых аргументов.
Введение целочисленного параметра никак не повлияет на ОЧЕВИДНОСТЬ генерик-кода (очевидность — основное отличие генериков .Net от шаблонов C++)
O>MS как раз пытается сохранить C# простым. При этом я не говорю, что это правильное решение (возможно, я даже не считаю так). Но я и не считаю, что скалярные параметры генериков это лучшее средство для метапрограммирования. Скорее, наоборот — подход Nemerle (подход Лиспа или Схемы, на самом деле, насколько я понимаю) мне нравится больше.
А мне не очень нравится . Сам дотнет не поддерживает функциональные типы как первоклассные значения. Делегаты — это адаптер, но не представляет из себя функциональный тип. (т.е. создать экземпляр делегата — не значит создать экземпляр ф-ии).
Более того, ситуация, при которой делегаты разного типа, но имеющие одинаковую сигнатуру Invoke не совместимы — это вообще нонсенс на уровне грубой ошибки проектирования (!!!). Пусть устранят эти баги, тогда функциональная часть программисткого направления станет более естественной для дотнета, и Nemerle в т.ч.
--------
Говорю неспроста. У самого есть черновик интерпретатора Схемы под дотнет, и исследовал более десятка вариантов имплементаций Схемы/Лиспа под Яву и дотнет. В общем, кое-какие ограничения не позволяют делать результирующий код достаточно эффективным. Тоже самое относитя к Форту. Несмотря на то, что байт-машина дотнет по своей вычислительной модели представляет из себя именно Форт-машину, написать компилятор Форта "напрямую" — никак, ибо верификатор дотнета не пропускает код, у которого указатель стека на входе и на выходе метода не совпадает . Поэтому единственная удачная реализаци Форта для дотнет использует эмуляцию обоих стеков Форта.
Здравствуйте, vdimas, Вы писали:
V>Введение целочисленного параметра никак не повлияет на ОЧЕВИДНОСТЬ генерик-кода (очевидность — основное отличие генериков .Net от шаблонов C++)
Ну не знаю. Сравни, например, код для решения одной и той же задачи на C++
. Имхо на Nemerle всё-таки понятнее малость. Но на вкус и цвет... кому-то, наверное, нагромождение угловых скобочек понравится больше...
V>А мне не очень нравится . Сам дотнет не поддерживает функциональные типы как первоклассные значения. Делегаты — это адаптер, но не представляет из себя функциональный тип. (т.е. создать экземпляр делегата — не значит создать экземпляр ф-ии).
V>Более того, ситуация, при которой делегаты разного типа, но имеющие одинаковую сигнатуру Invoke не совместимы — это вообще нонсенс на уровне грубой ошибки проектирования (!!!). Пусть устранят эти баги, тогда функциональная часть программисткого направления станет более естественной для дотнета, и Nemerle в т.ч.
Ну в Nemerle чуть иначе. Ты можешь посмотреть — они не используют делегаты для лямбд. У них для етого специальные классы есть.Поэтому для них, например, проблема несовместимости, описанная тобой, не стоит. Плюс в итоге конкретный экземпляр функционального типа сам содержит код функции (то, о чём ты тоже говорил).
eao197 wrote: > C>Ну вот, билд-система eao197 для С++ намного удобнее ant'а. Сейчас, > C>правда, я пользуюсь Boost.Build v2, которая еще удобнее. > Спасибо за добрые слова > Сейчас на rubyforge <http://rubyforge.org/projects/mxx-ru> делается > версия 1.1, которая стала еще чуть-чуть удобнее, да и поддержка > манифестов VC++8.0 добавилась. Так что, если было что-то, что тебе в > mxx_ru не понравилось, то отпиши туда в форум -- попробуем улучшить
Мне, в принципе, все понравилось.
Просто в BBv2 сейчас намного больше функциональности: variant builds,
больше переносимых настроек компилятора, лучшая поддержка unit-тестов,
да и Буст он напрямую поддерживает.
The Java HotSpot dynamic compiler uses runtime analysis to perform
inlining aggressively, yet safely. Once the Java HotSpot profiler
has collected runtime information about program hot spots, it not only
compiles the hot spot into native code, but performs extensive method
inlining on that code. The Java HotSpot compiler can afford to be
aggressive in the way it inlines because it can always back out an
inlining optimization if it determines that the method inheritance
structure has changed during runtime due to dynamic class loading.
...
Furthermore, method inlining is synergistic with other optimizations.
Inlining produces large blocks of code which make additional
optimizations easier for the compiler to perform. The ability of the
Java HotSpot Server VM to do aggressive inlining is a key factor in
making HotSpot faster than current JIT and static compilers.
Что, мне из исходников JVM цитаты приводить?
> C>Мне не сэмплы нужны. Нужно реальное приложение, с сильным использованием > C>макросов. > Вот компилятор и есть такое приложение. Он сам на себе создается и > использует море макросов.
Компилятор языка прикладным приложением не является по определению.
> C>Ну вот, билд-система eao197 для С++ намного удобнее ant'а. Сейчас, > C>правда, я пользуюсь Boost.Build v2, которая еще удобнее. > Серьезно? А ведь "билд-система eao197 для С++ намного удобнее ant'а"!
Вы понимаете, операция сравнения транзитивна. То есть из выражения
BootBuild.v2 > mxx_ru > ant > make
(где знак ">" следует читать как "лучше")
вытекает, что:
BootBuild.v2 > ant
и
BootBuild.v2 > mxx_ru
?
> Вообще забавный разговор выходит. Мэйк форевар, мэйк крут. Но один > велосипед на тему мэйка изобретает, а другой испльзует нестандарткую > приблуду из библиотеки.
Кстати, make пока по скорости еще никто не превзошел. Так что он в своем
роде лучший.
А насчет "приблуды из библиотеки" — посмотрите хоть на BBv2.
ЗЫ: а если бы никто не изобретал велосипедов, то Ant'а сейчас не было бы...
Отсутствие возможности использования скаляров как параметров генериков никоим образом не помешает решить задачу на Nemerle, в котором есть гораздо более развитые средства метапрограммирования. Не надо смотреть на решение задачи под углом C++ — лучше поближе ознакомиться с Nemerle для начала.
Он не больше чем во времена QBaisic/Turbo Baisic. А про Лисп я вообще молчу.
. Сам дотнет не поддерживает функциональные типы как первоклассные значения. Делегаты — это адаптер, но не представляет из себя функциональный тип. (т.е. создать экземпляр делегата — не значит создать экземпляр ф-ии).
Если нам не помогут, то мы тоже никого не пощадим.
