4 ms·

> I believe it's (LLVM) far too slow at compiling and far too big to be fixed from the inside What are you doing to make sure Tilde does not end up like this?

fermigier 2y ago
"You either die a hero or live long enough to see yourself become the villain".
- Ygg2 2y ago
  You either reinvent the wheel but square or live long enough to make it a circle.
snowfarthing 2y ago
I just had a random thought: perhaps it would be a good idea to have a project that doesn't do optimizations, but just focuses on fast compiling. Then again, I now can't help but wonder if LLVM (or even GCC) would be fast, if you just turned off all the optimizations ... (Of course, at this point, I can't help but think "you don't need to worry about the speed of compilation" in things like Common Lisp or Smalltalk, because everything is compiled incrementally and immediately, so you don't have to wait for the entire project to compile before you could test something ...)
- ajross 2y ago
  > Then again, I now can't help but wonder if LLVM (or even GCC) would be fast, if you just turned off all the optimizations ... It's not the optimizations really, it's the language front ends. Rust and C++ are extremely analysis-heavy. Try generating a comparable binary in C (or a kernel build, which is likely to be much larger!) and see how fast these compilers can be.
- christophilus 2y ago
  Go’s internal compiler / linker is kind of like that. So is qbe[0] iirc. https://c9x.me/compile/ https://c9x.me/compile/
negate32 2y ago
One of the big things which makes LLVM very slow is the abundance of passes, I believe I last counted 75 for an unoptimized function? My solution for this is writing more combined passes, due to the SoN design I'm combining a lot of things which are traditionally separate passes. For instance, my equivalent to "SimplifyCFG" "GVNPass", "InstCombine", "EarlyCSEPass" and "JumpThreadingPass" is one combined peephole solver which runs faster than all of these passes separately. This is for two main reasons: * Less cache churn, I'm doing more work per cacheline loaded in (rather than rescanning the same function over and over again). * Combining mutually beneficial optimizations can lead to less phase ordering problems and a better solve (this is why SCCP is better than DCE and constant prop separately). In a few years when TB is mature, I'd wager I'll have maybe 10-20 real passes for the "-O2 competitive" optimizer pipeline because in practice there's no need to have so many passes.
- DannyBee 2y ago
  I'm very confused what magic you believe will achieve what has not so far been achieved. I'm also confused why you believe LLVM didn't start out the exact same way? I say this as one of the main people responsible for working on combined pass replacements in both GCC and LLVM for things that were reasonable to be combined. I actually love destroying lots of passes in favor of better combined ones. In that sense, i'm the biggest fan in the world of these kinds of efforts. But the reason these passes exist is not cruft, or 20 years of laziness, - it's because it's very hard to replace them with combined algorithms that are both faster, and achieve the same results. What exactly do you plan on replacing GVN + Simplify CFG + Jump Threading + correlated value prop with? It took years of cherrypicking research and significant algorithm development to develop algorithms for this that had reasonable timebounds, were faster, and could do better than all of them combined. The algorithm is quite complex, and it's hard to prove it terminates in all cases, actually. The number of people who understand it is pretty small because of the complexity. That's before you get to applied engineering of putting it in a production compiler. These days, as the person originally responsible for it, i'd say it's not better enough for the complexity, even though it is definitely faster and more complete and would let you replace these passes. Meanwhile, you seem to think you will mature everything and get there in a few years. I could believe you will achieve some percent of GCC or LLVM's performance, but that's not the reason these passes exist. They exist because that is what it reasonably takes to achieve LLVM (and GCC's) performance across a wide variety of code, for some acceptable level of algorithm complexity and maintainability. So if you told me you were only shooting for 80% across some particular subset code, i could believe 10-20 passes. If you told me you were going to build a different product that targets a different audience, or in a different way, i could maybe believe it. But for what you say here, I think you vastly underestimate the difficult and vastly underappreciate the effort that goes into these things. This is hundreds of very smart people working on things for decades. It's one thing to have a healthy disrespect for the impossible. It's another to think you will, in a few years, outdo hundreds of smart, capable engineers on pure technical achievement. That strikes me as somewhere between hubris and insanity. People also pretty much stopped building and publishing general purpose compiler optimization algorithms a decade ago, moving towards much more specialized algorithms and ML focused things and whatnot. This is because in large part, there isn't a lot left worth doing. So unless you've got magic bullets nobody else has, either you won't achieve the same performance level, or it will be slow, or it will take you a significant amount of algorithm development and engineering well beyond "a few years". I say this not to dissuade you, but to temper your apparent expectations and view. Honestly - I wish you the best of luck, and hope you succeed at it.

fermigier 2y ago

"You either die a hero or live long enough to see yourself become the villain".

Ygg2 2y ago
You either reinvent the wheel but square or live long enough to make it a circle.

snowfarthing 2y ago

I just had a random thought: perhaps it would be a good idea to have a project that doesn't do optimizations, but just focuses on fast compiling. Then again, I now can't help but wonder if LLVM (or even GCC) would be fast, if you just turned off all the optimizations ... (Of course, at this point, I can't help but think "you don't need to worry about the speed of compilation" in things like Common Lisp or Smalltalk, because everything is compiled incrementally and immediately, so you don't have to wait for the entire project to compile before you could test something ...)

ajross 2y ago
> Then again, I now can't help but wonder if LLVM (or even GCC) would be fast, if you just turned off all the optimizations ... It's not the optimizations really, it's the language front ends. Rust and C++ are extremely analysis-heavy. Try generating a comparable binary in C (or a kernel build, which is likely to be much larger!) and see how fast these compilers can be.
christophilus 2y ago
Go’s internal compiler / linker is kind of like that. So is qbe[0] iirc. https://c9x.me/compile/ https://c9x.me/compile/

negate32 2y ago

One of the big things which makes LLVM very slow is the abundance of passes, I believe I last counted 75 for an unoptimized function? My solution for this is writing more combined passes, due to the SoN design I'm combining a lot of things which are traditionally separate passes. For instance, my equivalent to "SimplifyCFG" "GVNPass", "InstCombine", "EarlyCSEPass" and "JumpThreadingPass" is one combined peephole solver which runs faster than all of these passes separately. This is for two main reasons: * Less cache churn, I'm doing more work per cacheline loaded in (rather than rescanning the same function over and over again). * Combining mutually beneficial optimizations can lead to less phase ordering problems and a better solve (this is why SCCP is better than DCE and constant prop separately). In a few years when TB is mature, I'd wager I'll have maybe 10-20 real passes for the "-O2 competitive" optimizer pipeline because in practice there's no need to have so many passes.

DannyBee 2y ago
I'm very confused what magic you believe will achieve what has not so far been achieved. I'm also confused why you believe LLVM didn't start out the exact same way? I say this as one of the main people responsible for working on combined pass replacements in both GCC and LLVM for things that were reasonable to be combined. I actually love destroying lots of passes in favor of better combined ones. In that sense, i'm the biggest fan in the world of these kinds of efforts. But the reason these passes exist is not cruft, or 20 years of laziness, - it's because it's very hard to replace them with combined algorithms that are both faster, and achieve the same results. What exactly do you plan on replacing GVN + Simplify CFG + Jump Threading + correlated value prop with? It took years of cherrypicking research and significant algorithm development to develop algorithms for this that had reasonable timebounds, were faster, and could do better than all of them combined. The algorithm is quite complex, and it's hard to prove it terminates in all cases, actually. The number of people who understand it is pretty small because of the complexity. That's before you get to applied engineering of putting it in a production compiler. These days, as the person originally responsible for it, i'd say it's not better enough for the complexity, even though it is definitely faster and more complete and would let you replace these passes. Meanwhile, you seem to think you will mature everything and get there in a few years. I could believe you will achieve some percent of GCC or LLVM's performance, but that's not the reason these passes exist. They exist because that is what it reasonably takes to achieve LLVM (and GCC's) performance across a wide variety of code, for some acceptable level of algorithm complexity and maintainability. So if you told me you were only shooting for 80% across some particular subset code, i could believe 10-20 passes. If you told me you were going to build a different product that targets a different audience, or in a different way, i could maybe believe it. But for what you say here, I think you vastly underestimate the difficult and vastly underappreciate the effort that goes into these things. This is hundreds of very smart people working on things for decades. It's one thing to have a healthy disrespect for the impossible. It's another to think you will, in a few years, outdo hundreds of smart, capable engineers on pure technical achievement. That strikes me as somewhere between hubris and insanity. People also pretty much stopped building and publishing general purpose compiler optimization algorithms a decade ago, moving towards much more specialized algorithms and ML focused things and whatnot. This is because in large part, there isn't a lot left worth doing. So unless you've got magic bullets nobody else has, either you won't achieve the same performance level, or it will be slow, or it will take you a significant amount of algorithm development and engineering well beyond "a few years". I say this not to dissuade you, but to temper your apparent expectations and view. Honestly - I wish you the best of luck, and hope you succeed at it.