Twitter | Pretraživanje | |
Patrick Walton 2. velj
Rust compiler performance is hard to have meaningful discussions about because: (1) There’s no single part of the compiler which is slow. In fact the compiler is pretty well optimized.
Reply Retweet Označi sa "sviđa mi se"
Patrick Walton
(2) There’s no high-profile language design decision you can point to and say “aha, that was a mistake!” No header files, for example. The slowness comes from a lot of smaller things that have real benefits, such as the borrow check.
Reply Retweet Označi sa "sviđa mi se" More
Zorro Notorious M. E. B he / him 3. velj
Odgovor korisniku/ci @pcwalton
I don't know about whether this is meaningful to a language like Rust, but back in the 1960s / 70s when there was massive investment in Fortran compiler technology, there were two types of compilers:
Reply Retweet Označi sa "sviđa mi se"
Zorro Notorious M. E. B he / him 3. velj
Odgovor korisniku/ci @pcwalton
1. Highly optimizing compilers - they spent a lot of compile time grinding out the best code they could. All the tricks in the book were fair game. 2. "Student" compilers, like WATFOR - they were optimized for compile speed. They were glorified macro assemblers.
Reply Retweet Označi sa "sviđa mi se"
Rik Arends 2. velj
Odgovor korisniku/ci @pcwalton
Seems like there may be only one path then: be more incremental. First time compile is alright since you can sortof manage that yourself by not snowballing deps. But i'd love the ability to change small bits of code and hotload them rapidly. Doing that now for shaders but yea.
Reply Retweet Označi sa "sviđa mi se"
Darius Jahandarie 2. velj
Odgovor korisniku/ci @pcwalton
I think the basic architectural decision to make the compiler offline (instead of an online differential/incremental dataflow) is one thing that makes it “slow” (where “slow” is to be understood as something which lengthens the development feedback cycle).
Reply Retweet Označi sa "sviđa mi se"
Paolo G. Giarrusso 2. velj
Odgovor korisniku/ci @djahandarie @pcwalton
Honest question: is there any evidence that *fine-grained* incrementalization would help *in a compiler for such a complex language*? Embarrassingly parallel tasks parallelize well, but compilation ain't it, even if you ignore monomorphization.
Reply Retweet Označi sa "sviđa mi se"
Saoirse Shipwreckt 2. velj
Odgovor korisniku/ci @pcwalton
I think there are some clear unforced errors like name resolution (though these matter more for IDE responsiveness than batch throughput)
Reply Retweet Označi sa "sviđa mi se"
Connie Hilarides 3. velj
Odgovor korisniku/ci @pcwalton
Is the borrow checker even what's slow? I always thought llvm was the big bottle neck even in debug builds
Reply Retweet Označi sa "sviđa mi se"
infinitesimal 2. velj
Odgovor korisniku/ci @pcwalton
Does the borrow checker *need* to be slow, though?
Reply Retweet Označi sa "sviđa mi se"
soc 2. velj
Odgovor korisniku/ci @pcwalton
Tests in main sources?
Reply Retweet Označi sa "sviđa mi se"
lambic pentameter 3. velj
Odgovor korisniku/ci @oxnrtr @pcwalton
#[cfg(test)]
Reply Retweet Označi sa "sviđa mi se"