[htfy96]

Sometimes I feel many comparisons against LLVM's performance is somewhat unfair: You can easily reach -O0/-O1 performance of LLVM with much simpler infrastructure and only a limited number of cheap passes, which leads to a considerable performance boost, but many competitors like Cranelift claiming they are fast in compilation will never reach -O2 performance without major infrastructure changes.

These compilers are mainly designed for extreme performance. People complaining slow compilation of LLVM must never used ICC's -fast mode before, where a helloworld can take ~30s to compile. Developers still spend thousands on it because it squashed every drop of performance.

[sanxiyn]

I am not sure what is unfair about it. LLVM is inferior if you want fast build and -O1 performance. Many people are looking for fast build and -O1 performance, so it makes sense to let them know that LLVM is not what they want.

[Crinus]

I'd say most people, by far, are perfectly fine with -O1 performance. -O2 (and higher) is only needed for very small and specific parts of a codebase (e.g. the inner parts of encoding and rendering).

The problem is having both at the same time (i haven't seen any build configuration try to mix optimization levels) without compromising on compiler speed for -O1, so projects that require -O2 for a 0.1% of their codebase apply it for 100% of it.

In theory depending on the language you could mix different compilers, but that is a big can of worms (and other bugs).

[nmca]

LuaJIT springs to mind here... Famously performant.

[tachyonbeam]

LuaJIT also does a lot less work for a given piece of code than LLVM. It generates relatively well optimized code for a dynamic language, but it doesn't do much of the low level optimizations that LLVM and GCC do.

[Crinus]

Yes, that is how it usually goes, you exchange code performance for compiling performance but my point (a couple messages above) is that most of the time this performance is perfectly fine and it is only a tiny part of the codebase that may need the extra low level optimizations that LLVM and GCC can do (if it needs it at all). Of course this is a generality, the specifics depend on the project (chances are, the rendering parts of a CPU-based raytracer for CGI movies will need these optimizations much more than most projects, whereas a file manager most likely wont need them at all).

[rujuladanh]

A quick remark: general purpose compilers (including all the common ones) aren't really built for "extreme" performance. They always pick big tradeoffs and don't try everything they could.

In other words, it is not "hard" to build compilers with better performance. What is hard is getting performance without build times exploding.

[htfy96]

Just curious: which compilers according to your statement are designed for extreme performance? I know at the very right of the compilation time/performance axis lies SAT-based "super optimizers", but what lies between super optimizers and general-purpose compilers like icc?

[sanxiyn]

For example, Unison is an alternative code generator for LLVM, which uses constraint programming to do combined register allocation and instruction selection. It is very slow, but it does generate optimal (not just improved!) code, within its performance model.

http://unison-code.github.io/

[htfy96]

Thanks for the information. It seems that it is a super optimizer[0].

[0]: https://en.wikipedia.org/wiki/Superoptimization

[sanxiyn]

Unison is not a superoptimizer. Superoptimizer is evem slower.