Can you describe how to make rustc 10x as fast? Everyone says that of course it’s possible, 10x is easy to get, it’s just that nobody cares about compiler perf, etc. etc., And then everyone who tries ends up with, like, a perf boost of 10% if that.
-
-
Replying to @pcwalton @BRIAN_____ and
you can work on latency instead of throughput (i.e. incremental) for the bootstrap case, second-order incremental *would be* a thing, but that would require a pure language to write a compiler in, and Rust ain't that I am seriously waiting for advances in linear-dependent types
2 replies 0 retweets 1 like -
as for speedups within rustc written in Rust: compile type-matching into a bytecode, and use a type representation that makes an interpreter fast, or even JIT it (like CSS selectors ;)) make LLVM cheaper with optimizations on MIR (superlinear wins from it being polymorphic)
2 replies 0 retweets 3 likes -
Replying to @eddyb_r @BRIAN_____ and
I should also mention that MIR opts are nice but the low-hanging fruit has mostly already been picked here. Inlining, etc has not been the silver bullet people thought it might be.
3 replies 0 retweets 0 likes -
They are most definitely not. For example rustc checks two discriminants when doing matches over (T, T) where all the arms repeat the same pattern twice (e.g. code like PartialEq::eq), which led me to write some stupid stuff in Servo.https://github.com/servo/servo/pull/19956 …
2 replies 0 retweets 0 likes -
I’m sure we have plenty of peephole optimizations we can do. My point is that fixing that is not going to move the needle much on compile time. It’s whack-a-mole.
1 reply 0 retweets 0 likes -
As we all know, LLVM could do a lot better with certain optimizations, but nobody thinks a 2x across-the-board runtime performance (or compile time) increase is likely with LLVM improvements. The point of diminishing returns was long past. MIR is fast approaching this point too.
1 reply 0 retweets 0 likes -
Maybe. Maybe not. Getting a 5% benchmark improvement by just tweaking a bunch of PartialEq::eq functions makes me think MIR peephole optimisations could change a lot.
1 reply 0 retweets 0 likes -
I’ve seen enough potential silver bullets go by at this point to know better. :) Inlining and copy prop was far more potentially impactful, and it didn’t really help much.
1 reply 0 retweets 0 likes -
I’m not trying to be doom and gloom, BTW. I think Cranelift has potential to move the needle quite a bit: https://github.com/bjorn3/rustc_codegen_cranelift/issues/133#issuecomment-439475172 … But that gets back to my point about rewrites of subsystems being necessary for big improvements. Also interesting how Amdahl’s Law kicks in.
2 replies 0 retweets 2 likes
Amdahl’s Law in action: https://github.com/bjorn3/rustc_codegen_cranelift/issues/133#issuecomment-450382679 … Note that the bottlenecks are in the parts of Rust that don’t have analogues in old languages with fast compilers: borrow check and metadata encoding.
-
-
Well, given I keep being told to actually measure stuff when I have an idea, I still want to see those peephole optimisations in action before I say they are not that much of an improvement.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.