Здравствуйте, FR, Вы писали:
FR>Все так. Но компилятор это достаточно сложный продукт, и поэтому фичи локально улучшающие кодирование, на конечное время очень большого влияния не окажут. Другое дело что используя более мощный язык используются и более мощные идеомы и паттерны. Но монстры типа автора D я думаю тоже пользуются не менее мощными идеомами, так как опыт в таких делах по моему важнее чем используемый инструмент.
Опыт безусловно важная вещь, как и таналнт. Но я и сказал "при прочих равных". То есть будь у опытного и талантлиого человека более мощьный инструмент, то и достиг бы он большего. А вот объем кода возможно остался бы прежним.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, VladD2, Вы писали:
VD>Кстати авторы Скалы рассматривают ее как наследника ML-я?
Врядли — они хотят двинуть науку и создать идеальную компонентную систему.
Relationship between Scala and Other
Languages
Main influences on the Scala design:
• Java, C# for their syntax, basic types, and class libraries,
• Smalltalk for its uniform object model,
• Beta for systematic nesting,
• ML, Haskell for many of the functional aspects.
• OCaml, OHaskell, PLT-Scheme, as other combinations of FP
and OOP.
• Pizza, Multi-Java, Nice as other extensions of Java with
functional ideas.
(Too many influences in details to list them all)
Scala also seems to influence other new language designs, see for
instance the closures and comprehensions in C# 3.0.
Re: Действительно ли ML языки хороши в компиляторописании?
Тут есть некоторое ы. Чем лучше формализована задача, тем лучше подходит функциональные языки. Хороший пример реализация XQuery — Galax(реализован на CAML). Он разрабатывался параллельно XQuery на основе его текущей формальной семантики и данная семантика проверялась на нем. То есть гибкость при реализации/изменения формализмов очень высокая. Но по отзывам, реализации на С++ раза в 2 быстрее.(что тоже неудивительно).
Re: Действительно ли ML языки хороши в компиляторописании?
Наткнулся на древнюю статейку с ответом на мой вопрос Why ML/OCaml are good for writing compilers. Только все равно ситуация за почти десять лет никуда ни сдвинулась как писали компиляторы в основном на си так и пишут.
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, FR, Вы писали:
FR>Наткнулся на древнюю статейку с ответом на мой вопрос Why ML/OCaml are good for writing compilers. Только все равно ситуация за почти десять лет никуда ни сдвинулась как писали компиляторы в основном на си так и пишут.
часто ты заказываешь нелюбимое пиво? А если хочется гарантии удовольствия?
Re[3]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, FR, Вы писали:
FR>>Наткнулся на древнюю статейку с ответом на мой вопрос Why ML/OCaml are good for writing compilers. Только все равно ситуация за почти десять лет никуда ни сдвинулась как писали компиляторы в основном на си так и пишут.
КЛ>часто ты заказываешь нелюбимое пиво? А если хочется гарантии удовольствия?
Скорее ситуация такая, "мы даже пробовать эту фигню не будем, у нас свое (моча) отличное"
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, FR, Вы писали:
FR>Наткнулся на древнюю статейку с ответом на мой вопрос Why ML/OCaml are good for writing compilers. Только все равно ситуация за почти десять лет никуда ни сдвинулась как писали компиляторы в основном на си так и пишут.
Сейчас пишут в основном на Java.
Мое беглое исследование Google Code(т.е. в основном свежих проектов) дало следующие результаты:
Java ~25%
C ~15%
Pascal ~8%
Ruby ~7%
C# ~5%
Все остальные языки: Haskell, Ocaml, Scala, C++, Python, Lisp etc. в пределах 5%
Re[3]: Действительно ли ML языки хороши в компиляторописании
Z>Сейчас пишут в основном на Java. Z>Мое беглое исследование Google Code(т.е. в основном свежих проектов) дало следующие результаты: Z>Java ~25% Z>C ~15% Z>Pascal ~8% Z>Ruby ~7% Z>C# ~5% Z>Все остальные языки: Haskell, Ocaml, Scala, C++, Python, Lisp etc. в пределах 5%
Это именно по компиляторам или вообще?
И какова методика исследования?
Re[4]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, FR, Вы писали:
FR>Это именно по компиляторам или вообще? FR>И какова методика исследования?
По компиляторам, методика очень ad-hoc — ищем: label:compiler label:java
Re[3]: Действительно ли ML языки хороши в компиляторописании
Z>Сейчас пишут в основном на Java. Z>Мое беглое исследование Google Code(т.е. в основном свежих проектов) дало следующие результаты: Z>Java ~25% Z>C ~15% Z>Pascal ~8% Z>Ruby ~7% Z>C# ~5% Z>Все остальные языки: Haskell, Ocaml, Scala, C++, Python, Lisp etc. в пределах 5%
Мое беглое исследование показало, что в основном в мире пишут на Китайском и Хинди. Завязывал бы ты с Русским, а? А то водь от стада отобъешся.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Действительно ли ML языки хороши в компиляторописании
In the faster versions of the ray tracers, the OCaml implementations remain the most concise. However, although the most concise C++ is 2.4× longer than the most concise OCaml, the fastest C++ is only 1.65× longer than the fastest OCaml. This reflects that fact that both implementations are converging on the same low-level representation of the program in order to express more optimizations, i.e. OCaml's expressiveness must be sacrificed in order to reach competitive performance.
Re[3]: Действительно ли ML языки хороши в компиляторописании
FR>... This reflects that fact that both implementations are converging on the same low-level representation of the program in order to express more optimizations, i.e. OCaml's expressiveness must be sacrificed in order to reach competitive performance.
И правда, интересный вывод. Сколько еще придётся sacrefise что бы догнать по скорости
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[4]: Действительно ли ML языки хороши в компиляторописании
Во первых у обоих сравниваются неоптимизированные варианты, во вторых примерно полуторократное отставание очень хороший результат, учитывая насколько больше вложенно в низкоурвневую оптимизаци в VC по сравнению с Ocaml (который почти не делает таковую).
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, Didro, Вы писали:
D>У меня сходный вопрос, только про Haskell.
D>Захотелось реализовать Форт (Forth) на Haskell'e. D>
D>Да, Форт не имеет грамматики D>Да, Форт компилируемо-интерпретируемый D>Да, Форт в строках занимает совсем немного на любом языке D>D>Посмотрел реализации:
Делаем без монад. Даю пример на erlang.
Word = fun( Context ) -> Context2 | integer()
Code = { Word, Word, Word, ... }.
Context = { MathStack, CallStack, PC }
MathStack = CallStack = [Word ]
Плоскую память делать не обязательно. Делаем сегментную - по одному на слово-подпрограмму.
Соответственно,
PC = { Code, integer() }
SubroutineCall = call( Name, Dict ).
call( Name, Dict ) ->
Code = get( Name, Dict ),
fun( { DS, CS, PC } ) ->
{ DS, [ PC | CS ], Code }
end.
ret() ->
fun( { DS, [ Ret | CS ], _ } ) ->
{ DS, CS, Ret }
end.
Принцип понятен? Да, надо слова с мутабельной памятью предусмотреть. Ай-ай-ай. Что же делать-то.
А, ну да, конечно. PC = { integer(), integer() }, CodeStorage = array( Code ).
Ну вот, примерно так.
Насчет того, что код монадный? Извините, вы моделируете фон-неймановскую машину с мутабельными операциями. Лучше всего для этого, естественно, подходят мутабельные операции, поэтому импративный язык будет для такого однозначно лучше.
Re[4]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, FR, Вы писали:
FR>Во первых у обоих сравниваются неоптимизированные варианты
Я вообще не понял какие варианты сравнивались. Где там соотношения 2.4х и 1.65х
the 105-line C++ and 56-line OCaml programs
Компиляторовалось же с максимальной оптимизацией. Я тогда это делал, что бы показать, что за цифры в бенчмарках на сайте. Например, непонятно, посему именно GCC, и какую погрешность вносит инициализация рантайма.
FR>во вторых примерно полуторократное отставание очень хороший результат, учитывая насколько больше вложенно в низкоурвневую оптимизаци в VC по сравнению с Ocaml (который почти не делает таковую).
Согласен (хотя, кстати, С++ не разварачивал рекурсии). Но там есть некоторые заморочки с косвенными вызовами, подозреваю, что это какие-то не решаемые в общем случае проблемы, как у виртуальных функций в С++.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[6]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, gear nuke, Вы писали:
GN>Я вообще не понял какие варианты сравнивались. Где там соотношения 2.4х и 1.65х GN>
the 105-line C++ and 56-line OCaml programs
Да что-то напутали, но можно все брать с http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html
GN>Компиляторовалось же с максимальной оптимизацией. Я тогда это делал, что бы показать, что за цифры в бенчмарках на сайте. Например, непонятно, посему именно GCC, и какую погрешность вносит инициализация рантайма.
С gcc (3.4.2) я тоже проверил c -O3 время практически одинаково с ocaml.
FR>>во вторых примерно полуторократное отставание очень хороший результат, учитывая насколько больше вложенно в низкоурвневую оптимизаци в VC по сравнению с Ocaml (который почти не делает таковую).
GN>Согласен (хотя, кстати, С++ не разварачивал рекурсии). Но там есть некоторые заморочки с косвенными вызовами, подозреваю, что это какие-то не решаемые в общем случае проблемы, как у виртуальных функций в С++.
Попробовал в С++ добавить #pragma inline_recursion(on) не помогает.
