Здравствуйте, Кирилл Лебедев, Вы писали:

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

Блин, так требовать изменить под себя правила форума, с которыми большинство соглашается, и которые уже не раз обсуждались можно рассматривать как пример неуважительного отношения к другим участникам форума с ВАШЕЙ стороны.

Не нравится конкретно человек, так что мешает просто не отвечать ему или найти портал наследников благородных кровей , где обращение не унижает ВАШИ моральные устои, или мы действуем согласно принципу:

Ёжики плакали, но продолжали есть кактус

Здравствуйте, Кирилл Лебедев, Вы писали:

AVK>>Конкретные примеры чего? На абстрактные мысли о нарастании абстракции сложновато привести конкретные примеры, не находишь?

КЛ>Вот статья. В ней разобраны три примера: пример 1, пример 2 и пример 3. Если Вам непонятно, как закономерность, описанная в конце статьи, соотносится с примерами, Вы можете обратиться к разделу "Чем "исторические примеры" похожи на три предыдущих" или спросить.

Уж поверьте на слово: и прочитал, и разобрался. Продемонстрированная закономерность представляется мне, мягко говоря, упрощённой оценкой практики программирования. Ну, если опять-таки прибегнуть к грубоватой аналогии, то нельзя выводить подобие грузовика и, например, кирпича, только потому, что и там и там имеется образующий параллелепипед. Или ещё проще — Холмогоры не восходят этимологически к Гомгардии ((c) к/ф "Ломоносов"). Один (всего лишь один, зато какой!) упущенный аспект в мотивации я уже показал. А чтобы написать полный разбор полётов потребуется слишком много времени.

КЛ>Но для этого должно быть желание разобраться .

В чём разбираться? В закономерности, выделенной на основании поверхностного анализа, когда эта поверхностность видна невооружённым глазом? Вам знаком тезис, что любая проблема программирования может быть решена введеним дополнительного уровня абстракции, за исключением проблемы слишком большого количества уровней абстракции? Заметьте, сказано это остаточно давно, чтобы уже стать притчей во языцех. А вы тут пытаетесь нам "продать" этот же рецепт, но под лозунгом ТРИЗ. И кто тут кого обманывает?

AndrewVK совершенно прав, когда говорит, что такие мысли приходят почти каждому программисту в первые три года работы. И здесь я его дополню, что почти каждый же начинает их подавать с не меньшим апломбом и претензией на открытие закона "всех явлений видимых, яко же и глазу неподвластных". Одобрение коллег, правда, такие персонажи зачастую заслуживают только благодаря тому, что демонстрируют самостоятельное мышление (это довольно-таки редкое явление, представляющее самостоятельную ценность), а отнюдь не в силу "глубины" изысканий. Понимаете разницу, да?

Отдельный момент — это обсуждение применимости ТРИЗ к программированию вообще. Понимаете ли, в чём дело, вводить в рассуждения и в модели новые сущности (то есть, по сути, заниматься изобретательством в чистом виде) — это наша работа. Вопрос только в количестве и достаточности оснований для появления этих сущностей.

Hello, VladD2!
You wrote on Wed, 07 Feb 2007 19:06:11 GMT:

YK>> Работала. Ухудшаться ситуация начала версии с пятой, в шестой
YK>> тормоза порою начинают доставать.

V> В ГУИ? Не поверю.

Во-первых, ГУИ сам по себе в IDEA далеко не летает (Swing), но с этим можно жить.
Во-вторых, там помимо ГУИ есть чему тормозить и часто эти тормоза наблюдаются посредством ГУИ.

Turtle.BAZON.Group wrote:

>> > Ага. Только тоже имеет те же проблемы с семантикой.
> .>О какой ты семантике говоришь при обсуждении *Abstract* Syntax Tree?..
> А если Abstract, то почему нет обобщения?

an abstract syntax tree (AST) is a finite, labeled, directed tree, where the internal nodes are labeled by operators,
and the leaf nodes represent the operands of the operators.

В общем всё. Обобщение идёт в том смысле, что выкидываются некоторые лексемы (типа скобок группирующих), ибо для
представления в виде дерева они не нужны. Короче говоря, это промежуточный результат, который получается после работы
парсера, но до семантики дело ещё не дошло. Ведь переменная в императивном языке совсем не то, что в функциональном.

> ПС: ладно, тема зашла в тупик. Было приятно пообщаться.
Похоже не сошлись в терминологии.

ГВ>В чём разбираться? В закономерности, выделенной на основании поверхностного анализа, когда эта поверхностность видна невооружённым глазом? Вам знаком тезис, что любая проблема программирования может быть решена введеним дополнительного уровня абстракции, за исключением проблемы слишком большого количества уровней абстракции? Заметьте, сказано это остаточно давно, чтобы уже стать притчей во языцех. А вы тут пытаетесь нам "продать" этот же рецепт, но под лозунгом ТРИЗ. И кто тут кого обманывает?

есть такой интересный момент — когда какая-то идея переходиьт из чисто практической сферы под сень некоей научной методологии, к ней оказывается прилоджим весь тот спектр методов, который уже наработан в этой науке. в данном случае ТРИЗ известнет своими наработками в сфере решения сложных творческих задач и его методы вполне возможно удастся перенести в сферу разраьботки ПО, открыв программистам новые подходы к решению их задач, которые они не смогли изобрести сами

Здравствуйте, BulatZiganshin, Вы писали:

BZ>есть такой интересный момент — когда какая-то идея переходиьт из чисто практической сферы под сень некоей научной методологии, к ней оказывается прилоджим весь тот спектр методов, который уже наработан в этой науке. в данном случае ТРИЗ известнет своими наработками в сфере решения сложных творческих задач и его методы вполне возможно удастся перенести в сферу разраьботки ПО, открыв программистам новые подходы к решению их задач, которые они не смогли изобрести сами

Угу только ТРИЗ пытаются приложить к программированию с конца 80 — начала 90 и никаких результатов не видно. Мне кажется ТРИЗ очень эффективная методика для решения очень узкого круга проблем.

Здравствуйте, ., Вы писали:

.>представления в виде дерева они не нужны. Короче говоря, это промежуточный результат, который получается после работы
.>парсера, но до семантики дело ещё не дошло. Ведь переменная в императивном языке совсем не то, что в функциональном.

Собственно, об этом и говорил.

>> ПС: ладно, тема зашла в тупик. Было приятно пообщаться.
.>Похоже не сошлись в терминологии.

Да, видать...

Здравствуйте, YК, Вы писали:

YК>Hello, VladD2!
YК>You wrote on Wed, 07 Feb 2007 19:06:11 GMT:

YK>>> Работала. Ухудшаться ситуация начала версии с пятой, в шестой
YK>>> тормоза порою начинают доставать.

V>> В ГУИ? Не поверю.

YК>Во-первых, ГУИ сам по себе в IDEA далеко не летает (Swing), но с этим можно жить.
YК>Во-вторых, там помимо ГУИ есть чему тормозить и часто эти тормоза наблюдаются посредством ГУИ.

Возможно, стоило начать новую тему (или найти старую, наверняка была ) но все же...
Из всех новых веяний я вполне понимаю почему на смену C++ предложили сначала Java а потом C#
Я прекрасно понимаю преимущества таких вещей как reflection, сборки мусора и т.п., которых очень не хватает в C++ (равно как и многих вещей из функционального программирования, да и много чего еще)

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

Здравствуйте, x-code, Вы писали:

XC>Но вот почему вместо процессора, который просто создан для того чтобы выполнять команды ввели виртуальные машины, которые делают ровно то же самое но медленнее...
У тебя неправильное понимание того, что такое виртуальная машина. Виртуальная машина — это всего лишь идеализированный образ. Она позволяет компилятору сгенерировать такое представление программы, в котором нет излишних деталей вроде того, какие регистры для чего использовать и каким образом передавать аргументы вызовов. При этом этот образ достаточно детален (пока), чтобы отображение на реальную архитектуру не было чрезмерно сложным. В итоге компилятор отдает не "сырые" инструкции, а недокомпилированный код. Этот код, конечно, можно интерпретировать (как можно интерпретировать и код x86), а можно компилировать сразу в целевую архитектуру (как сейчас в основном и делается).
Поэтому реально все команды выполняет процессор. И очень быстро. А насчет медленнее, напомню, что собственно x86 — виртуальная машина. Реально внутри стоит RISC процессор, а то, что ты видишь как x86 код, интерпретируется на нем перед выполнением. Ну и как, достаточно быстро он выполняет CMPXCHG?

XC>Объясните плиз... (заранее извините за то что тема поднимается наверняка не в первый раз)

Здравствуйте, Sinclair, Вы писали:

S>У тебя неправильное понимание того, что такое виртуальная машина. Виртуальная машина — это всего лишь идеализированный образ. Она позволяет компилятору сгенерировать такое представление программы, в котором нет излишних деталей вроде того, какие регистры для чего использовать и каким образом передавать аргументы вызовов.

как раз это я понимаю. и знаю что реально методы компилируются в реальный код x86 при первом вызове. Непонятно — зачем? Какие преимущества дает операция "докомпилировать при первом вызове, запомнить в кэше и выполнить" по сравнению с просто "выполнить"?
Я не против собственно VM, у них есть масса достоинств, но почему не сделать опцию в компиляторе "генерировать код для VM" и "генерировать код для x86" (а заодно "генерировать код для процессора/VM "X", где X — некоторая архитектура, а для компилятора — просто некоторый плагин)?

При этом этот образ достаточно детален (пока), чтобы отображение на реальную архитектуру не было чрезмерно сложным. В итоге компилятор отдает не "сырые" инструкции, а недокомпилированный код. Этот код, конечно, можно интерпретировать (как можно интерпретировать и код x86), а можно компилировать сразу в целевую архитектуру (как сейчас в основном и делается).
S>Поэтому реально все команды выполняет процессор. И очень быстро. А насчет медленнее, напомню, что собственно x86 — виртуальная машина. Реально внутри стоит RISC процессор, а то, что ты видишь как x86 код, интерпретируется на нем перед выполнением. Ну и как, достаточно быстро он выполняет CMPXCHG?

Я полностью согласен с тем что архитектура x86 кривая, устаревшая и тянущая за собой ошибки 20-летней давности. Мне непонятна сама идеология. Вот например переход с 32 на 64 бита можно было совместить с переходом на новую (например RISC) архитектуру, ввести в процессор поддержку безопасности и вообще ввести все что нужно для поддержки современных парадигм программирования. Пусть 32-битные приложения выполнялись бы как раньше на микропрограммной VM, а 64-битные — на RISC. Но нет — архитектура осталась той же, а вместо этого нам предлагают по сути двойную VM. Страшно подумать что будет, когда окажется что C# слишком низкоуровневый и придумают какой-нибудь скриптовый язык, который будет интерпретироваться, а интерпретатор будет написан на C#

x-code wrote:
> как раз это я понимаю. и знаю что реально методы компилируются в
> реальный код x86 при первом вызове. Непонятно — *зачем*? Какие
> преимущества дает операция "докомпилировать при первом вызове, запомнить
> в кэше и выполнить" по сравнению с просто "выполнить"?
Во-первых, кроссплатформенность. Во-вторых, в теории Java-код может
работать быстрее аналогичного С-шного кода из-за механизма HotSpot.

> Я полностью согласен с тем что архитектура x86 кривая, устаревшая и
> тянущая за собой ошибки 20-летней давности. Мне непонятна сама
> идеология. Вот например переход с 32 на 64 бита можно было совместить с
> переходом на новую (например RISC) архитектуру, ввести в процессор
> поддержку безопасности и вообще ввести все что нужно для поддержки
> современных парадигм программирования. Пусть 32-битные приложения
> выполнялись бы как раньше на микропрограммной VM, а 64-битные — на RISC.
Рассказать что случилось с Intel Itanic, проститие, Intel Itanium? Линус
об этом хорошо сказал:
http://www.ussg.iu.edu/hypermail/linux/kernel/0302.2/1909.html

Здравствуйте, Cyberax, Вы писали:

C>x-code wrote:
>> как раз это я понимаю. и знаю что реально методы компилируются в
>> реальный код x86 при первом вызове. Непонятно — *зачем*? Какие
>> преимущества дает операция "докомпилировать при первом вызове, запомнить
>> в кэше и выполнить" по сравнению с просто "выполнить"?
C>Во-первых, кроссплатформенность. Во-вторых, в теории Java-код может
C>работать быстрее аналогичного С-шного кода из-за механизма HotSpot.
если кроссплатформенность, то "докомпиляцию" можно было бы выполнить один раз на этапе инсталляции программы, а не делать это каждый раз при запуске. Это же элементарная оптимизация — вынести независящее от цикла вычисление за пределы цикла...

Насчет HotSpot — почитал статью, он может выполняться быстрее в 2 раза чем обычный Java-код. Большая часть этой оптимизации доступна на этапе компиляции для того же си. А вся "статистическая" real-time оптимизация, основанная на сборе статистики о наиболее часто вызываемых методах и т.п. — да, ее конечно проще всего реализовать на VM, но совсем не обязательно только на VM.

C>Рассказать что случилось с Intel Itanic, проститие, Intel Itanium? Линус
C>об этом хорошо сказал:
C>http://www.ussg.iu.edu/hypermail/linux/kernel/0302.2/1909.html
Я думаю, основная причина — несовместимость с огромным количеством существующего ПО.

x-code wrote:
> C>Во-первых, кроссплатформенность. Во-вторых, в теории Java-код может
> C>работать быстрее аналогичного С-шного кода из-за механизма HotSpot.
> если кроссплатформенность, то "докомпиляцию" можно было бы выполнить
> *один раз* на этапе инсталляции программы, а не делать это *каждый раз*
> при запуске. Это же элементарная оптимизация — вынести независящее от
> цикла вычисление за пределы цикла...
.NET так умеет делать. В Sun JVM это затруднительно из-за организации
самой виртуальной машины. Хотя прекомпилировать классы стандартной
библиотеки оно умеет.

> Насчет HotSpot — почитал статью, он может выполняться быстрее в 2 раза
> чем обычный Java-код.
Бред. Что за статья?

HotSpot — это именно технология runtime-оптимизации, которую в принципе
невозможна сделать статически.

Здравствуйте, Cyberax, Вы писали:


C>HotSpot — это именно технология runtime-оптимизации, которую в принципе
C>невозможна сделать статически.

Статически нет а без виртуальной машины вполне.

FR wrote:
> C>HotSpot — это именно технология runtime-оптимизации, которую в принципе
> C>невозможна сделать статически.
> Статически нет а без виртуальной машины вполне.
Как? Нам надо уметь как-то в runtime перекомпилировать код.

В принципе, если есть доступ к исходникам — можно перекомпилировать из
исходников. Но это все равно будет слегка извращенная VM.

Здравствуйте, x-code, Вы писали:
XC>если кроссплатформенность, то "докомпиляцию" можно было бы выполнить один раз на этапе инсталляции программы, а не делать это каждый раз при запуске. Это же элементарная оптимизация — вынести независящее от цикла вычисление за пределы цикла...
Это уже сделано, по крайней мере для .Net. RTFM "ngen tool".

XC>Насчет HotSpot — почитал статью, он может выполняться быстрее в 2 раза чем обычный Java-код. Большая часть этой оптимизации доступна на этапе компиляции для того же си.
Плохо читал. Не в 2, а в любое количество раз. И эти оптимизации совершенно недоступны для си, т.к. у него нет информации о статистике реального выполнения. К примеру, си не может инлайнить косвенный вызов.

XC>А вся "статистическая" real-time оптимизация, основанная на сборе статистики о наиболее часто вызываемых методах и т.п. — да, ее конечно проще всего реализовать на VM, но совсем не обязательно только на VM.
Не обязательно. Но VM — это удобная абстракция.

Здравствуйте, x-code, Вы писали:

XC>Я думаю, основная причина — несовместимость с огромным количеством существующего ПО.

Либо несовместимость с огромным колличеством существующих программистов.

Здравствуйте, Cyberax, Вы писали:

C>FR wrote:
>> C>HotSpot — это именно технология runtime-оптимизации, которую в принципе
>> C>невозможна сделать статически.
>> Статически нет а без виртуальной машины вполне.
C>Как? Нам надо уметь как-то в runtime перекомпилировать код.

Ну Profile Guided Optimization уже давно есть. Он вполне может обходится не перекомпиляцией исходников, а переоптимизацией объектников

C>В принципе, если есть доступ к исходникам — можно перекомпилировать из
C>исходников. Но это все равно будет слегка извращенная VM.

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

Здравствуйте, Sinclair, Вы писали:

XC>>Насчет HotSpot — почитал статью, он может выполняться быстрее в 2 раза чем обычный Java-код. Большая часть этой оптимизации доступна на этапе компиляции для того же си.
S>Плохо читал. Не в 2, а в любое количество раз. И эти оптимизации совершенно недоступны для си, т.к. у него нет информации о статистике реального выполнения. К примеру, си не может инлайнить косвенный вызов.

Доступны и делаются, VC 8 и Intel умеют.

FR wrote:
> C>Как? Нам надо уметь как-то в runtime перекомпилировать код.
> Ну Profile Guided Optimization уже давно есть. Он вполне может обходится
> не перекомпиляцией исходников, а переоптимизацией объектников
PGO может оптимизировать только для некоторых случаев. Горячие точки
ведь могут мигирировать во время работы программы.

> C>В принципе, если есть доступ к исходникам — можно перекомпилировать из
> C>исходников. Но это все равно будет слегка извращенная VM.
> Если оптимизировать прямо у клиента то исходники не нужны, достаточно
> объектников и правильного линкера.
А как ты будешь оптимизировать виртуальные вызовы, например?