4 ms·

It means things don't usually get better until you admit they're not as good as they can be.

by civility 9y ago

sametmax 9y ago
The rust compiler provide huge guaranties no other provide, like for memory safety. This has a performance impact.
- cakoose 9y ago
  The memory safety checking (or more generally, the type checking) isn't what makes the compiler slow. That part is pretty fast because it's intentionally modular. It's the cross-module optimizations that make the compiler slow. Those optimizations are in service of C++-inspired ideal of being able to use layers of abstraction to make your code cleaner, but having the compiler flatten them down so your program still runs fast.
coldtea 9y ago
I hope you see the irony in accusing them of that in a post announcing that the compiler just got better.
- civility 9y ago
  It's not ironic. I see this kind of thing all the time. Rather than cleanup and speedup an implementation, engineers will make it multi-threaded or send it off to a GPU, generally achieving limited improvements and greater complexity. In this case, rather than make the compiler faster, they hack it up with incremental compilation. It's still slow, but they apply the slow code to less data and call it a win.
  - pcwalton 9y ago
    Nobody who reads the rustc commit history would agree that this is what is going on. The number of straightforward changes that are constantly made in the service of small performance improvements far outweighs the work on incremental compilation.
ComputerGuru 9y ago
I’m pretty sure no one in their right mind claims that rustc is “as good as can be.” It’s called incremental progress.
pcwalton 9y ago
rustc could definitely be faster. I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. Compiler performance has more or less much been the #1 goal for well over a year now. The Rust compiler team (which hasn't included me for years, by the way) is fantastic. We'd all like for there to be some magic bullet that makes the compiler faster, but at this point I don't believe it exists. It's hard work from here on out.
- deleted 9y ago
  [deleted]
- civility 9y ago
  > I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. [...] magic bullet I didn't suggest low hanging fruit or a magic bullet. If anything, incremental compilation is being promoted as that kind of thing, and I just wanted call it into question.
  - pcwalton 9y ago
    Nobody thinks incremental compilation is a magic bullet! The article specifically says "This is still not the end story for compiler performance generally, nor incremental compilation specifically."

It means things don't usually get better until you admit they're not as good as they can be.

sametmax 9y ago

The rust compiler provide huge guaranties no other provide, like for memory safety. This has a performance impact.

cakoose 9y ago
The memory safety checking (or more generally, the type checking) isn't what makes the compiler slow. That part is pretty fast because it's intentionally modular. It's the cross-module optimizations that make the compiler slow. Those optimizations are in service of C++-inspired ideal of being able to use layers of abstraction to make your code cleaner, but having the compiler flatten them down so your program still runs fast.

coldtea 9y ago

I hope you see the irony in accusing them of that in a post announcing that the compiler just got better.

civility 9y ago
It's not ironic. I see this kind of thing all the time. Rather than cleanup and speedup an implementation, engineers will make it multi-threaded or send it off to a GPU, generally achieving limited improvements and greater complexity. In this case, rather than make the compiler faster, they hack it up with incremental compilation. It's still slow, but they apply the slow code to less data and call it a win.
- pcwalton 9y ago
  Nobody who reads the rustc commit history would agree that this is what is going on. The number of straightforward changes that are constantly made in the service of small performance improvements far outweighs the work on incremental compilation.

ComputerGuru 9y ago

I’m pretty sure no one in their right mind claims that rustc is “as good as can be.” It’s called incremental progress.

pcwalton 9y ago

rustc could definitely be faster. I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. Compiler performance has more or less much been the #1 goal for well over a year now. The Rust compiler team (which hasn't included me for years, by the way) is fantastic. We'd all like for there to be some magic bullet that makes the compiler faster, but at this point I don't believe it exists. It's hard work from here on out.

deleted 9y ago
[deleted]
civility 9y ago
> I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. [...] magic bullet I didn't suggest low hanging fruit or a magic bullet. If anything, incremental compilation is being promoted as that kind of thing, and I just wanted call it into question.
- pcwalton 9y ago
  Nobody thinks incremental compilation is a magic bullet! The article specifically says "This is still not the end story for compiler performance generally, nor incremental compilation specifically."