5 ms·

On the contrary. Compilers written in a high-level language are at a distinct advantage: they're easier to optimize (significantly so), easier to debug, and su

by daeken 17y ago

On the contrary. Compilers written in a high-level language are at a distinct advantage: they're easier to optimize (significantly so), easier to debug, and support forms that are difficult to deal with in a low(er)-level language like C or C++. I do compiler development every day, and I no longer touch low-level compilers. Everything I write is Boo (for my OS), Ruby (for my startup -- by far my favorite language for compiler dev, despite not liking it in general), or Python. As a result, I have far more maintainable code than the majority, and the code I output is incredibly well optimized. Edit: To clarify, by 'support forms that are difficult to deal with ...' I mean things like using a pure S-exp structure. Rather than a traditional intermediary form, you can represent your compiler state as an S-exp and iteratively optimize and compile it. Standardizing around a form like that, when it's easy to deal with, greatly simplifies code. (This is actually the reason Ruby is my compiler language of choice these days.)

ilkhd2 17y ago
if you read carefully what I said, i never said that hig-level languages are bad - I said only this: 1) Compiler written in python, ruby and other "slow" (do not beleive that pyruby is slow?) languages going to take eternity to compile linux kernel. 2) You need to have _precise_ mapping between types in compiler and the language you implement. It is so important that gcc use a software library for floating point computation, otherwise you are locked-in wit you cpu's FP implementation and can not write cross-compilers.
- daeken 17y ago
  You said they were impractical, then went on to explain why. I then explained why they are not impractical. The speed I'll give you, but the type issue is nonsensical. GCC's use of a software FP implementation is in support of this. Regardless of the language, you'll need to have an FP implementation that matches the target, which is nearly always done in software. High-level languages for compilation are, 9 times out of 10, a better choice.
  - ilkhd2 17y ago
    1. FP is almost never done in software, it hurts performance big time, The only reason gcc uses it - it wants to be cross-platform, otherwise it might have perfectly used native FP. Also a lot more convenient to use different floating point point formats whene they are supported by language and hardware you running on, than messing with libraries. 2. Another example : OCaml. It has no "single float" type, and that is a reason I am not gonna use it for making a compiler; I'd choose haskell or F# - both of them have float32. 3. Depends what kind of HLL we are tslking about - Python and Ruby are defintely very poor choice for a compiler : lack of strong typing, only one type of FP is used, needs explicit watch for integer operations overflow, poor performance, lack of mature, bug free implementation (compared to C++ or ML for example). ML derived languages, however are very good for making compilers.
    - daeken 17y ago
      1. Any compiler that supports cross-compilation supports a software FP implementation. GCC, MSVC (CL, that is), and many others. You take a speed hit, but it's downright negligible in a compiler. 2. Having never used OCaml for compiler dev, I can't speak on this. 3. The lack of strong typing has no effect on the ability of Python or Ruby to handle compilation. Like the Lisp family, these are very, very flexible languages with strong benefits to compiler developers, and I wouldn't trade them for anything else I've used. TBH, I think ML-based languages are poor choices for compiler development. You spend as much time worrying about your own code as you do the code you're compiling, which you just don't do when you write a compiler in Scheme, Ruby, or another 'dynamic' language.
      - ilkhd2 17y ago
        1. No not any. Many cross-compilers do not if the binary formats and pecularities of arithmetic operations maps well between host system and target system - why waste time? Example = x86 and x64, two different platforms, with same binary representation. About performance - not sure if it is negligible - optimisation takes a lot of time in moder compilers. 3. You have not seen ml code I am sure. ML has type inference, you are not bothered about types too much. And it has pattern matching, very good when traversing trees. Neither scheme nor pyruby has this. ML also a language with completely formalized semantics, in combination with strong type it allows you to prove that you compiler is correct by means of formal provers.
- viraptor 17y ago
  > You need to have _precise_ mapping between types in compiler and the language you implement. No. You don't need that. You can treat your data however you want until you place it into the final binary. Before that, you can even treat all your numbers as strings if you really want to. If you need some constant expression evaluation, you just have to replicate the target machine's math operations in software - no magic involved here. As long as you get the right result, noone cares what you do internally. If your compilation machine == target machine, you can even construct a function that calculates the expression and actually run it to get the result.
  - ilkhd2 17y ago
    When you make optimization you need to do intermediate calclulation _exactly_ the same way the target machine does. Even if the number is ascii or unicode string, you need to do the computations strictly same way s target machine does, otherwise you'd break assumptions of the programmer, and lead to unreproducible code.
- mahmud 17y ago
  Compiler written in python, ruby and other "slow" .. languages going to take eternity to compile linux kernel. What makes you think everyone is out to write a C compiler?
  - ilkhd2 17y ago
    What make you think that I think this way? Linux kernel is just an example of relatively big program, where performance of the compiler is an important issue. Another example of performance-sensitive application of compilers is background Java compiler in Eclipse - even for rather small programs it has to be fast. Ruby is 10-100 (actually more than that) times slower than C/Java, So if you optimizer (wriiten in C/Java/Haskell) needs 0.5 second to optimize code, same code will need (by very optimistic measure) 30 sec. Python not much better. Scheme a bit better (especially Stalin compiler), Lisp almost good.
    - pc 17y ago
      Have you actually used Stalin? Compiling anything with it is shockingly slow. It does, of course, produce very fast programs—but it can take minutes to generate them, even in simple cases.
      - ilkhd2 17y ago
        No I did not, butI read papers, written by the author. Indeed it is slow, but still be good for final compilation. Alas it is r4rs, and also I heard that it sometimes generate incorrect code. Still Scheme is better choice in my opinion for performance sensitive code, than ruby/python.
        mahmud 17y ago
        Stalin and Mlton are whole-program optimizing compilers. They take a bit longer than other compilers, but the results are impressive.
      - ilkhd2 17y ago
        You probably missed the point - my concern is not the speed of compilation _of_ _the_ _compiler_ _itself_ - it is totally irrelevant, what is important is the performance of _created_ _compiler_, which is going to be ok, taking into account the quality of Stalins optimizer.
judofyr 17y ago
May I ask you what tools you use in Ruby?
ilkhd2 17y ago
Ok, the discussion is becoming pointless: you like ruby for compiler construction. Well I'd rather use a language with proper tail recursion, algebraic data types, with pattern matching as a part of it, fast, strongly typed [I beleive algebraic types with pat. matching gives roughly same possibilities as does dyn. typing, for this task], with standard or at least big industrial backing behind - such as F# or Haskell. And at the end of the day get warm feeling that my code is "green" - does not waste joules, by working fast. I appreciate your choice, but I'd myself do differently.

by daeken 17y ago

ilkhd2 17y ago

if you read carefully what I said, i never said that hig-level languages are bad - I said only this: 1) Compiler written in python, ruby and other "slow" (do not beleive that pyruby is slow?) languages going to take eternity to compile linux kernel. 2) You need to have _precise_ mapping between types in compiler and the language you implement. It is so important that gcc use a software library for floating point computation, otherwise you are locked-in wit you cpu's FP implementation and can not write cross-compilers.

daeken 17y ago
You said they were impractical, then went on to explain why. I then explained why they are not impractical. The speed I'll give you, but the type issue is nonsensical. GCC's use of a software FP implementation is in support of this. Regardless of the language, you'll need to have an FP implementation that matches the target, which is nearly always done in software. High-level languages for compilation are, 9 times out of 10, a better choice.
- ilkhd2 17y ago
  1. FP is almost never done in software, it hurts performance big time, The only reason gcc uses it - it wants to be cross-platform, otherwise it might have perfectly used native FP. Also a lot more convenient to use different floating point point formats whene they are supported by language and hardware you running on, than messing with libraries. 2. Another example : OCaml. It has no "single float" type, and that is a reason I am not gonna use it for making a compiler; I'd choose haskell or F# - both of them have float32. 3. Depends what kind of HLL we are tslking about - Python and Ruby are defintely very poor choice for a compiler : lack of strong typing, only one type of FP is used, needs explicit watch for integer operations overflow, poor performance, lack of mature, bug free implementation (compared to C++ or ML for example). ML derived languages, however are very good for making compilers.
  - daeken 17y ago
    1. Any compiler that supports cross-compilation supports a software FP implementation. GCC, MSVC (CL, that is), and many others. You take a speed hit, but it's downright negligible in a compiler. 2. Having never used OCaml for compiler dev, I can't speak on this. 3. The lack of strong typing has no effect on the ability of Python or Ruby to handle compilation. Like the Lisp family, these are very, very flexible languages with strong benefits to compiler developers, and I wouldn't trade them for anything else I've used. TBH, I think ML-based languages are poor choices for compiler development. You spend as much time worrying about your own code as you do the code you're compiling, which you just don't do when you write a compiler in Scheme, Ruby, or another 'dynamic' language.
    - ilkhd2 17y ago
      1. No not any. Many cross-compilers do not if the binary formats and pecularities of arithmetic operations maps well between host system and target system - why waste time? Example = x86 and x64, two different platforms, with same binary representation. About performance - not sure if it is negligible - optimisation takes a lot of time in moder compilers. 3. You have not seen ml code I am sure. ML has type inference, you are not bothered about types too much. And it has pattern matching, very good when traversing trees. Neither scheme nor pyruby has this. ML also a language with completely formalized semantics, in combination with strong type it allows you to prove that you compiler is correct by means of formal provers.
viraptor 17y ago
> You need to have _precise_ mapping between types in compiler and the language you implement. No. You don't need that. You can treat your data however you want until you place it into the final binary. Before that, you can even treat all your numbers as strings if you really want to. If you need some constant expression evaluation, you just have to replicate the target machine's math operations in software - no magic involved here. As long as you get the right result, noone cares what you do internally. If your compilation machine == target machine, you can even construct a function that calculates the expression and actually run it to get the result.
- ilkhd2 17y ago
  When you make optimization you need to do intermediate calclulation _exactly_ the same way the target machine does. Even if the number is ascii or unicode string, you need to do the computations strictly same way s target machine does, otherwise you'd break assumptions of the programmer, and lead to unreproducible code.
mahmud 17y ago
Compiler written in python, ruby and other "slow" .. languages going to take eternity to compile linux kernel. What makes you think everyone is out to write a C compiler?
- ilkhd2 17y ago
  What make you think that I think this way? Linux kernel is just an example of relatively big program, where performance of the compiler is an important issue. Another example of performance-sensitive application of compilers is background Java compiler in Eclipse - even for rather small programs it has to be fast. Ruby is 10-100 (actually more than that) times slower than C/Java, So if you optimizer (wriiten in C/Java/Haskell) needs 0.5 second to optimize code, same code will need (by very optimistic measure) 30 sec. Python not much better. Scheme a bit better (especially Stalin compiler), Lisp almost good.
  - pc 17y ago
    Have you actually used Stalin? Compiling anything with it is shockingly slow. It does, of course, produce very fast programs—but it can take minutes to generate them, even in simple cases.
    - ilkhd2 17y ago
      No I did not, butI read papers, written by the author. Indeed it is slow, but still be good for final compilation. Alas it is r4rs, and also I heard that it sometimes generate incorrect code. Still Scheme is better choice in my opinion for performance sensitive code, than ruby/python.
      - mahmud 17y ago
        Stalin and Mlton are whole-program optimizing compilers. They take a bit longer than other compilers, but the results are impressive.
    - ilkhd2 17y ago
      You probably missed the point - my concern is not the speed of compilation _of_ _the_ _compiler_ _itself_ - it is totally irrelevant, what is important is the performance of _created_ _compiler_, which is going to be ok, taking into account the quality of Stalins optimizer.

judofyr 17y ago

May I ask you what tools you use in Ruby?

ilkhd2 17y ago

Ok, the discussion is becoming pointless: you like ruby for compiler construction. Well I'd rather use a language with proper tail recursion, algebraic data types, with pattern matching as a part of it, fast, strongly typed [I beleive algebraic types with pat. matching gives roughly same possibilities as does dyn. typing, for this task], with standard or at least big industrial backing behind - such as F# or Haskell. And at the end of the day get warm feeling that my code is "green" - does not waste joules, by working fast. I appreciate your choice, but I'd myself do differently.