3 ms·

I don't know for certain but I believe it's mostly slow because of traits, lifetime/borrow checker, etc... The compiler is basically a proof system and would be

by hderms 6y ago

I don't know for certain but I believe it's mostly slow because of traits, lifetime/borrow checker, etc... The compiler is basically a proof system and would be doing work that's hard to compare to V8

deleted 6y ago
[deleted]
josephg 6y ago
Sure ... My question is, what do you think the upper bound on performance is for a performance-oriented rust compiler? Like, if the whole compiler were written to optimize the edit-build-run cycle, how many times faster could it go? Exhibit A, in our recent history of compilers we've had lots of examples of compilers / runtimes which seemed like they were pretty close to the threshold, only for another compiler to come out of nowhere and compile many times faster. Examples: (everything before V8) -> V8, Lua -> LuaJIT, Gcc -> clang (when it was new). And this is cheating but I'm doing it - every C compiler -> Go's compiler. So the question is, how surprised would you be if some serious, experienced compiler people were capable of making a rust compiler that was 3x faster than rustc? Personally I would be not surprised at all. I suspect a lot of rustc's slowness comes from a combination of unavoidable time spent in llvm plus all the work rustc needs to do to convert rust to llvm IR. Its a bit of a smoking gun that most compilers built on top of llvm are pretty slow - swift, c++, rustc, pony, etc. And all the fast compilers have their own backend (go, v8, luajit, jai, etc). So yeah, I'm hopeful for MIRI and cheering from the sidelines.
- hderms 6y ago
  I think that's totally valid, especially because there are likely tons of bottlenecks that make the entire process slower than it otherwise could be. I just think there are some challenges to compiling Rust that might make the upper bound of efficiency less than desired

3 ms·

I don't know for certain but I believe it's mostly slow because of traits, lifetime/borrow checker, etc... The compiler is basically a proof system and would be

by hderms 6y ago

deleted 6y ago
[deleted]
josephg 6y ago
Sure ... My question is, what do you think the upper bound on performance is for a performance-oriented rust compiler? Like, if the whole compiler were written to optimize the edit-build-run cycle, how many times faster could it go? Exhibit A, in our recent history of compilers we've had lots of examples of compilers / runtimes which seemed like they were pretty close to the threshold, only for another compiler to come out of nowhere and compile many times faster. Examples: (everything before V8) -> V8, Lua -> LuaJIT, Gcc -> clang (when it was new). And this is cheating but I'm doing it - every C compiler -> Go's compiler. So the question is, how surprised would you be if some serious, experienced compiler people were capable of making a rust compiler that was 3x faster than rustc? Personally I would be not surprised at all. I suspect a lot of rustc's slowness comes from a combination of unavoidable time spent in llvm plus all the work rustc needs to do to convert rust to llvm IR. Its a bit of a smoking gun that most compilers built on top of llvm are pretty slow - swift, c++, rustc, pony, etc. And all the fast compilers have their own backend (go, v8, luajit, jai, etc). So yeah, I'm hopeful for MIRI and cheering from the sidelines.
- hderms 6y ago
  I think that's totally valid, especially because there are likely tons of bottlenecks that make the entire process slower than it otherwise could be. I just think there are some challenges to compiling Rust that might make the upper bound of efficiency less than desired