Попробовал поискать другие трансляторы но ничего хорошего пока не нашел.
Тут http://json.org/ конечно есть очень хороший для пенисометрии материал, простенький транслятор с реализацией на куче языков, но сравнивать тяжело, так как уровень подержки и качество реализации очень разное.
Можно еще конечно взять http://en.wikipedia.org/wiki/ECMAScript у которого тоже немало реализаций, в том числе и на C++, D и ML. Но опять я нашел только разные версии языка (у digitalmars v3 на ML v4):
Здравствуйте, FR, Вы писали:
FR>Хотелось бы еще примеров реализации трансляторов, на которых действительно можно нормально сравнить что дает высокоуровневый язык в этой сфере.
Вопрос поставлен довольно странно, и критерий (мерять строками) тоже довольно странный.
Для написания нетривиального компилятора на С вам придется реализовать систему управления памятью(или прикрутить консервативный GC), и придумать как вы будете обходить деревья (у вас не будет паттерн-матчинга). После этого, код все равно будет ужасным и нечитаемым .
Ява куда более приятный кандидат — там есть GC и "visitor". Про scala, например, известно, что после перепысывания ее с Явы на себе самой, код уменьшился в 2 раза — с 48k строк до 23. Скала, для этих целей, вполне похожа на ML без вывода типов
Про Lua: у Lua практически нет компилятора — там применена самая примитивная схема однопроходной трансляции, т.е. AST не создается, оптимизаций никаких не делается — прямо из парсера эммитится байткод VM.
LuaML в строках, может и не короче, зато создает AST и решает задачу типобезопасного расширения Lua из Ocaml, и потом вы сравнивали объем облитературенных исходников LuaML с практически некомментированным кодом Lua.
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, FR, Вы писали:
FR>>Хотелось бы еще примеров реализации трансляторов, на которых действительно можно нормально сравнить что дает высокоуровневый язык в этой сфере.
Z>Вопрос поставлен довольно странно, и критерий (мерять строками) тоже довольно странный. Z>Для написания нетривиального компилятора на С вам придется реализовать систему управления памятью(или прикрутить консервативный GC), и придумать как вы будете обходить деревья (у вас не будет паттерн-матчинга). После этого, код все равно будет ужасным и нечитаемым .
Ну консервативный GC вообще не проблема в той же реализации ECMAScript от DMD он 68 Kb всего занимает, правда там C++. Вообще это пока единственный нормальный доступный код для сравнения (правда рекламный ) но вот сравнить хотя бы С++ или D или C# с ML нет ничего.
Z>Ява куда более приятный кандидат — там есть GC и "visitor". Про scala, например, известно, что после перепысывания ее с Явы на себе самой, код уменьшился в 2 раза — с 48k строк до 23. Скала, для этих целей, вполне похожа на ML без вывода типов
А есть доступные исходники?
Кстати у меня есть опыт переписывания своей программы с C++ на опять же на C++ и тоже код уменьшился в полтора раза
Z>Про Lua: у Lua практически нет компилятора — там применена самая примитивная схема однопроходной трансляции, т.е. AST не создается, оптимизаций никаких не делается — прямо из парсера эммитится байткод VM. Z>LuaML в строках, может и не короче, зато создает AST и решает задачу типобезопасного расширения Lua из Ocaml, и потом вы сравнивали объем облитературенных исходников LuaML с практически некомментированным кодом Lua.
Это да комментариев я сразу не заметил.
Re: Действительно ли ML языки хороши в компиляторописании?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Вообще думал z00n даст ссылу, но раз он промолчал, то я: LCR>Scheme over Ocaml — имплементация схемы на окамле.
А с чем сравнивать то? Надо бы реализаций именно такого же варианта схемы на других языках.
Re[3]: Действительно ли ML языки хороши в компиляторописании
FR,
FR>А с чем сравнивать то? Надо бы реализаций именно такого же варианта схемы на других языках.
Ну скажем VSCM — на Си, тоже R4RS (правда Schoca реализует неполный R5RS).
Ещё есть, например, Gambit на C++, но этот компилятор намного круче, сильно оптимизирующий R6RS.
Можно ещё здесь реализации повыбирать, но тут вообще бездна
Ещё в качестве альтернативы предлагаю вот этот микробенчмарк, названный Jon Harrop Challenge Problem (дисклэймер по поводу микробенчмарков обычный). Задача состоит в том, чтобы упростить символическое алгебраическое выражение используя следующие правила переписывания:
rational n + rational m -> rational(n + m)
rational n * rational m -> rational(n * m)
symbol x -> symbol x
0+f -> f
f+0 -> f
0*f -> 0
f*0 -> 0
1*f -> f
f*1 -> f
a+(b+c) -> (a+b)+c
a*(b*c) -> (a*b)*c
Результаты здесь, сравниваются исходники на Qi, Lisp и Ocaml. Альтернативная реализация на Ocaml без использования полиморфных вариантов и ещё одна реализация на Лиспе.
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, FR, Вы писали:
FR>>Хотелось бы еще примеров реализации трансляторов, на которых действительно можно нормально сравнить что дает высокоуровневый язык в этой сфере.
Z>Вопрос поставлен довольно странно, и критерий (мерять строками) тоже довольно странный. Z>Для написания нетривиального компилятора на С вам придется реализовать систему управления памятью(или прикрутить консервативный GC), и придумать как вы будете обходить деревья (у вас не будет паттерн-матчинга). После этого, код все равно будет ужасным и нечитаемым .
прикручивание систему управления памятью задача специфичная не только для написания компайлеров. Кроме того, как же в языках без паттерн матчинга люди обходят деревья? Думаю, как-то справляются.
Z>Ява куда более приятный кандидат — там есть GC и "visitor". Про scala, например, известно, что после перепысывания ее с Явы на себе самой, код уменьшился в 2 раза — с 48k строк до 23. Скала, для этих целей, вполне похожа на ML без вывода типов
Визиторы есть везде
Z>Про Lua: у Lua практически нет компилятора — там применена самая примитивная схема однопроходной трансляции, т.е. AST не создается, оптимизаций никаких не делается — прямо из парсера эммитится байткод VM. Z>LuaML в строках, может и не короче, зато создает AST и решает задачу типобезопасного расширения Lua из Ocaml, и потом вы сравнивали объем облитературенных исходников LuaML с практически некомментированным кодом Lua.
Re[4]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>FR,
FR>>А с чем сравнивать то? Надо бы реализаций именно такого же варианта схемы на других языках.
LCR>Ну скажем VSCM — на Си, тоже R4RS (правда Schoca реализует неполный R5RS).
Уже можно сравнить, но не сильно впечатляет разница чуть боьше чем в два раза с си.
LCR>Ещё в качестве альтернативы предлагаю вот этот микробенчмарк, названный Jon Harrop Challenge Problem (дисклэймер по поводу микробенчмарков обычный). Задача состоит в том, чтобы упростить символическое алгебраическое выражение используя следующие правила переписывания:
Интересно
Есть подозрение что рефал порвет всех по краткости кода на этой задаче
(хотя perl наверно тоже)
Re[4]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Ещё в качестве альтернативы предлагаю вот этот микробенчмарк, названный Jon Harrop Challenge Problem .
Отличная мысль. Аналогично, Одерски как-то хвастался перед явистами паттерн-матчингом на таком примере:
// SCALA!class Term
case class Num(n: int) extends Term
case class Var(name: String) extends Term
case class Mul(l: Term, r: Term) extends Term
case class Add(l: Term, r: Term) extends Term
// Now let's say we want to implement some simplification rules on such terms.
// Two useful simplifications apply the equalities:
// 0 * x = 0
// 1 * x = x
def simplify(term: Term) = term match {
case Mul(Num(0), x) => Num(0)
case Mul(Num(1), x) => x
case _ => term
}
Ему ответили, что мултиплай — диспатч на яве — это просто
public interface TermMD extends pec.compile.multipledispatch.MultipleDispatch { // The methods in this interface are Multiply Dispatched
Term binarySimplify( Term toTheLeft, Term toTheRight );
Term unarySimplify( Term toTheRight );
}
public interface Term extends TermMD { // The method in this interface is Singly Dispatched
Term simplify();
}
public abstract class TerminalTerm implements Term {
public final Term binarySimplify( Term toTheLeft, Term toTheRight ) { throw new AssertionError(); } // Method body replaced by PEC - with a multiple dispatch callpublic static final Term binarySimplify( final Term kind, final Term toTheLeft, final Term toTheRight ) { return kind; } // Default simplifier for unary terms - do nothingpublic final Term unarySimplify( Term toTheRight ) { throw new AssertionError(); } // Method body replaced by PEC - with a multiple dispatch callpublic static final Term unarySimplify( final Term kind, final Term toTheRight ) { return kind; } // Default simplifier for binary terms - do nothingpublic Term simplify() { return this; } // Nothing to simplify for a terminal!
}
public abstract class UnaryTerm extends TerminalTerm {
protected final Term toTheRight;
protected UnaryTerm( final Term toTheRight ) { this.toTheRight = toTheRight.simplify(); }
public Term simplify() { return unarySimplify( toTheRight ); }
}
public abstract class BinaryTerm extends UnaryTerm {
protected final Term toTheLeft;
protected BinaryTerm( final Term toTheLeft, final Term toTheRight ) {
super( toTheRight );
this.toTheLeft = toTheLeft.simplify();
}
public Term simplify() { return binarySimplify( toTheLeft, toTheRight ); }
}
public final class Zero extends TerminalTerm {}
public final class NaN extends TerminalTerm {}
public final class Var extends TerminalTerm {}
public final class Mult extends BinaryTerm {
public Mult( final Term toTheLeft, final Term toTheRight ) { super( toTheLeft, toTheRight ); }
public static final Term binarySimplify( final Mult m, final Zero z, final Term t ) { return z; } // 0 * x = 0public static final Term binarySimplify( final Mult m, final Term t, final Zero z ) { return z; } // x * 0 = 0public static final Term binarySimplify( final Mult m, final Zero z, final Zero z2 ) { return z; } // 0 * 0 = 0, needed to resolve conflictpublic static final Term binarySimplify( final Mult m, final NaN n, final Term t ) { return n; } // NaN * x = NaNpublic static final Term binarySimplify( final Mult m, final Term t, final NaN n ) { return n; } // x * NaN = NaNpublic static final Term binarySimplify( final Mult m, final NaN n, final NaN n2 ) { return n; } // NaN * NaN = NaN, needed to resolve conflictpublic static final Term binarySimplify( final Mult m, final NaN n, final Zero z ) { return n; } // NaN * 0 = NaN, needed to resolve conflictpublic static final Term binarySimplify( final Mult m, final Zero z, final NaN n ) { return n; } // 0 * NaN = NaN, needed to resolve conflict
}
К вопросу о практической применимости вот реальный код (на Scala) из моего собственного компилятора:
def optimize : Decision => Decision = {
// optimizes IfEq(_,_,Failure,Failure) outcase IfEq(_,_,t1,t2) if (t1==t2) => t1
// #{...} >= 0 --- always truecase IfEq(_, LVec(_,0),t1,_) => t1
case x => x
}
Re: Действительно ли ML языки хороши в компиляторописании?
И собственно я увидел огромное число применений Monad, фактически код на 80% состоит из нотации "=do..." .
Возникли сомнения (отвращение): зачем мне использовать Haskell для таких задач, если он вынуждает меня обертывать 80% компилятора\интерпретатора в монады и работать фактически императивно.
Собственно возможные ответы:
Да, не стоит использовать Haskell для таких (простых) задач. Примеры выше — это из пушки по воробьям.
Да, на Haskell вообще без монад в компиляторах только AST можно обрабатывать.
Да, Haskell это круто! Монады позволяют явно отделить императивный мир от функционального! (и?)
Для тех кто не знает что такое Форт(Forth) — это stack-based (Concatenative) язык программирования, того же времени, что и LISP. Форт породил такие языки как Cat, Joy, Factor (не считая огромное число вариаций Форта). Изюминка Форта в его врожденной метапрограммируемости.
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Didro, Вы писали:
D>>У меня сходный вопрос, только про Haskell.
D>>Захотелось реализовать Форт (Forth) на Haskell'e.
FR>Это же кощунство, форт можно реализовывать только на форте, в самом крайнем случае минимальный бустрап на ассемблере
Не, ну я же не хочу встроить Форт в контроллер и интерактивно с ним работать, тут понятно дело, не-до-Хаскелла.
Я хочу компилятор Форта, на выходе которого я бы получил код под конкретный контроллер. А в процессе разработки мог бы расширять компилятор новыми словами.
Кроме того, если даже и не брать в рассмотрение Форт (а скажем взять тот же калькулятор), то Монады все равно никуды не деваются. И как мне кажется это такая характерная черта Хаскеля — Монады плодятся как сумасшедшие, как только мы коснулись в программе внешеного мира (генерация\интерпретация кода), я прав?
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, Didro, Вы писали:
D>И собственно я увидел огромное число применений Monad, фактически код на 80% состоит из нотации "=do..." . D>Возникли сомнения (отвращение): зачем мне использовать Haskell для таких задач, если он вынуждает меня обертывать 80% компилятора\интерпретатора в монады и работать фактически императивно.
Путаешь монады и императивность.
В первом примере такое обильное количество do из-за того, что парсер монадический.
do определяет что за чем следует в конструкции описываемого языка.
Здравствуйте, Didro, Вы писали:
D>Кроме того, если даже и не брать в рассмотрение Форт (а скажем взять тот же калькулятор), то Монады все равно никуды не деваются. И как мне кажется это такая характерная черта Хаскеля — Монады плодятся как сумасшедшие, как только мы коснулись в программе внешеного мира (генерация\интерпретация кода), я прав?
Нет, попытаюсь объяснить. Путаница идёт из-за непонимания разницы между IO и монадой. Монада — всего лишь интерфейс, под этот интерфейс в языке есть сахар — do-синтаксис.
IO-конкретная монада, относящаяся к внешнему миру. Да, как только мы её коснулись, то выйти из неё не можем, по одной простой причине — функции для работы с IO имеют тип "... -> IO a", функции "IO a -> b" нет (это не совсем верно, но для объяснений достаточно), соответственно, как только мы получили IO результат, будем ли мы его передавать в какую-нибудь функцию, на выходе обязательно будем иметь тот же IO a. Это касается характерная черта этой монады, которая не позволяет нам вынырнуть из мира с побочными эффектами в чистый.
Ни для генерации, ни для интерпретации IO не нужен. Для генерации можно использовать монадические парсеры, а можно писать разбор более явно. Монады всего лишь оборачивают вычисление и сокращают код, как, например, карринг.
Почитай про реализацию монадических парсеров, всё станет гораздо прозрачнее.
Здравствуйте, Didro, Вы писали:
D>Не, ну я же не хочу встроить Форт в контроллер и интерактивно с ним работать, тут понятно дело, не-до-Хаскелла. D>Я хочу компилятор Форта, на выходе которого я бы получил код под конкретный контроллер. А в процессе разработки мог бы расширять компилятор новыми словами.
Не понял, форт же один из самых расширяемых языков, он же легко сам на себе расширяется, и метапрограмирование там не уступает лиспу (и превосходит хаскель )
Re[5]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Didro, Вы писали:
D>>Не, ну я же не хочу встроить Форт в контроллер и интерактивно с ним работать, тут понятно дело, не-до-Хаскелла. D>>Я хочу компилятор Форта, на выходе которого я бы получил код под конкретный контроллер. А в процессе разработки мог бы расширять компилятор новыми словами.
FR>Не понял, форт же один из самых расширяемых языков, он же легко сам на себе расширяется, и метапрограмирование там не уступает лиспу (и превосходит хаскель )
С выделенным согласен на 100%.
Я имел в виду, что Форт можно и на Haskell написать, если мы не планиурем потом эту реализацию Форта в микроконтроллеры запихивать. А если планируем, тогда да — Форт пишем на Форте + загрузчик на asm'e.
В моем же случае нужен компилятор Форта (т.е. мой Форт не будет работать на микроконтроллерах как некоторые Форты), поэтому написать его можно и на Haskell. В микроконтроллерах будет работать уже asm-код сгенерированный компилятором Форта, который я хотел написать на Haskell.
Re[6]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, Didro, Вы писали:
D> Я имел в виду, что Форт можно и на Haskell написать, если мы не планиурем потом эту реализацию Форта в микроконтроллеры запихивать. А если планируем, тогда да — Форт пишем на Форте + загрузчик на asm'e. D> В моем же случае нужен компилятор Форта (т.е. мой Форт не будет работать на микроконтроллерах как некоторые Форты), поэтому написать его можно и на Haskell. В микроконтроллерах будет работать уже asm-код сгенерированный компилятором Форта, который я хотел написать на Haskell.
Хозяин барин конечно
Но что мешает написать ядро на хаскеле (вместо ассеблера очень крутая замена ) а дальше уже поступать как прововерный фортист
Re[5]: Действительно ли ML языки хороши в компиляторописании
Про размеры коментариев (без них ML-версия минимум в 2 раза короче), разницу в функциональности и простоту задачи тебе тут уже сказали.
Я же хочу поделиться интересны наблюдением. Объемы программ направленных на решение сходных задач почему-то очень часто являются похжими. Это один из примеров. Другой пример полноценного компилируемого языка вроде D и Nemerle. Их объемы тоже похожи. Казалось бы напрашивается вывод, что пофигу на чем писать. Вот только это если не сравнивать качество решения. Ведь сложность компилторов может быть разная. Все же паттерн-матчинг, более мощьный вывод типов, макросы и т.п. они многого стоят. И будучи написанными на С++ увеличат компилятор еще не в один раз.
Так вот, конечно любую программу можно написать на любом ЯП... по определению. И ресурсом тут является исключительно человеческие возможности. Так что не странно, что объемы компиляторов или интерпретаторов сходны. Это показатель ограничения человеческих возможностей. Так что понято, что раота сделанная на более мощном языке (при прочих равных) получается более качественным, проще расширяется и поддерживается.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, VladD2, Вы писали:
VD>Я же хочу поделиться интересны наблюдением. Объемы программ направленных на решение сходных задач почему-то очень часто являются похжими. Это один из примеров. Другой пример полноценного компилируемого языка вроде D и Nemerle. Их объемы тоже похожи. Казалось бы напрашивается вывод, что пофигу на чем писать. Вот только это если не сравнивать качество решения. Ведь сложность компилторов может быть разная. Все же паттерн-матчинг, более мощьный вывод типов, макросы и т.п. они многого стоят. И будучи написанными на С++ увеличат компилятор еще не в один раз.
Все так. Но компилятор это достаточно сложный продукт, и поэтому фичи локально улучшающие кодирование, на конечное время очень большого влияния не окажут. Другое дело что используя более мощный язык используются и более мощные идеомы и паттерны. Но монстры типа автора D я думаю тоже пользуются не менее мощными идеомами, так как опыт в таких делах по моему важнее чем используемый инструмент.
VD>Так вот, конечно любую программу можно написать на любом ЯП... по определению. И ресурсом тут является исключительно человеческие возможности. Так что не странно, что объемы компиляторов или интерпретаторов сходны. Это показатель ограничения человеческих возможностей. Так что понято, что раота сделанная на более мощном языке (при прочих равных) получается более качественным, проще расширяется и поддерживается.
С этим вполне согласен, при прочих равных более мощный язык это хорошо.
Re[3]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, 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) не помогает.
Re[4]: Действительно ли ML языки хороши в компиляторописании
.
) но вот сравнить хотя бы С++ или D или C# с ML нет ничего.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
