4 ms·

What if it just emitted C as its IR instead? MLton (the SML compiler) uses C as its primary backend (while they also have an x86 one) for portability and ease o

by jjice 5y ago

What if it just emitted C as its IR instead? MLton (the SML compiler) uses C as its primary backend (while they also have an x86 one) for portability and ease of implementation. By doing so, it bundles a small runtime needed for SML (garbage collection, closures, and such). Would you also consider that a transpiler? I personally wouldn't because SML to C is a drastic change, especially from the abstraction point of view. C just makes a convenient backend at that point. But since it also has native backends and C is its only other high level language, would you still consider it a compiler since you specifically mentioned "several other languages"? I think it's kind of fun to look at this philosophically, since these are broad terms without perfect definitions.

frou_dh 5y ago
I just tried MLton with the "-verbose 2" flag and it seems to use "amd64Codegen" by default, on MacOS at least.
- jjice 5y ago
  Oh neat! I'm assuming then that C is the default for anything that doesn't have a specific backend for. I believe I heard that they had an x86 backend, but it was a pain to work with (maybe not as fast). Those are probably old concerns though, since their x86 64 backend must be more performant.
Zababa 5y ago
Speaking about MLton, I've often heard that it's "special" as it's a " whole-program optimizing compiler", but I was under the impression that it's already what compilers do. Is there a difference between MLton and let's say Clang, GCC or something like that?
- jjice 5y ago
  GCC will compile one set of files at a time into .o files, and then those are linked together later on, so each "module" (using that term loosely) is compiled separately. MLton takes in the entire program source, including the standard library, at once. Because of that, there's a ton of information we know, which helps a ton for things like dead code elimination. Because of this, there's a lot of memory required, since we have the entire program's syntax/parse/any other type of tree in memory, and it's not going to be as fast as something like GCC since we're recompiling everything every time in MLton instead of only recompiling the changed modules. Despite MLton being a bit slower to compile, it's truly an incredible compiler. I had Dr Fluet, the lead maintainer, as my compiler professor in college, and he's a wealth of knowledge. The compiler we wrote in class was in SML and compiled with MLton. The amount of optimizations that occur is insane, it made damn fast executables, and that applies to most big compilers like GCC, Clang, Rustc, etc. The big difference in optimizations is how much information we have at optimization time. Languages like C are a bit looser and thus information may be harder to derive. Rust has a stricter set of rules, so we have more guarantees about a program to base our optimizations around.
  - Zababa 5y ago
    Thank you for the explanation. While that explain what makes MLton special, I now wonder why other compilers aren't doing the same. There is probably lots of money to make by optimising some performance critical code, especially C/C++. But you seem to say that MLton is one of a kind. I don't understand that part.
    - jjice 5y ago
      The full program optimization is more applicable in a more formally specified language like SML I believe. Big projects take quite some time to compile, which is definitely a pain while developing. So I'm out of my depth at this point, but this post from the SE Stack Exchange was interesting in that it highlights that those cross boundary optimizations can be handled at link time. I'm not sure how much is possible compared to MLton. MLton will have more access to type info, I'd assume, but maybe some metadata is stored in a .o file that I'm just not aware of. I don't know much about this serious level of optimization, but I assume big C compilers get optimizations that are equally, if not more impressive and do just fine. https://softwareengineering.stackexchange.com/a/370242 https://softwareengineering.stackexchange.com/a/370242

by jjice 5y ago

frou_dh 5y ago

I just tried MLton with the "-verbose 2" flag and it seems to use "amd64Codegen" by default, on MacOS at least.

jjice 5y ago
Oh neat! I'm assuming then that C is the default for anything that doesn't have a specific backend for. I believe I heard that they had an x86 backend, but it was a pain to work with (maybe not as fast). Those are probably old concerns though, since their x86 64 backend must be more performant.

Zababa 5y ago

Speaking about MLton, I've often heard that it's "special" as it's a " whole-program optimizing compiler", but I was under the impression that it's already what compilers do. Is there a difference between MLton and let's say Clang, GCC or something like that?

jjice 5y ago
GCC will compile one set of files at a time into .o files, and then those are linked together later on, so each "module" (using that term loosely) is compiled separately. MLton takes in the entire program source, including the standard library, at once. Because of that, there's a ton of information we know, which helps a ton for things like dead code elimination. Because of this, there's a lot of memory required, since we have the entire program's syntax/parse/any other type of tree in memory, and it's not going to be as fast as something like GCC since we're recompiling everything every time in MLton instead of only recompiling the changed modules. Despite MLton being a bit slower to compile, it's truly an incredible compiler. I had Dr Fluet, the lead maintainer, as my compiler professor in college, and he's a wealth of knowledge. The compiler we wrote in class was in SML and compiled with MLton. The amount of optimizations that occur is insane, it made damn fast executables, and that applies to most big compilers like GCC, Clang, Rustc, etc. The big difference in optimizations is how much information we have at optimization time. Languages like C are a bit looser and thus information may be harder to derive. Rust has a stricter set of rules, so we have more guarantees about a program to base our optimizations around.
- Zababa 5y ago
  Thank you for the explanation. While that explain what makes MLton special, I now wonder why other compilers aren't doing the same. There is probably lots of money to make by optimising some performance critical code, especially C/C++. But you seem to say that MLton is one of a kind. I don't understand that part.
  - jjice 5y ago
    The full program optimization is more applicable in a more formally specified language like SML I believe. Big projects take quite some time to compile, which is definitely a pain while developing. So I'm out of my depth at this point, but this post from the SE Stack Exchange was interesting in that it highlights that those cross boundary optimizations can be handled at link time. I'm not sure how much is possible compared to MLton. MLton will have more access to type info, I'd assume, but maybe some metadata is stored in a .o file that I'm just not aware of. I don't know much about this serious level of optimization, but I assume big C compilers get optimizations that are equally, if not more impressive and do just fine. https://softwareengineering.stackexchange.com/a/370242 https://softwareengineering.stackexchange.com/a/370242