Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Rust 1.64 became faster on Windows

tomaszs2.medium.com

Post reply on HN
Print view View original

61–70 of 80 posts

Re: How Rust 1.64 became faster on Windows

#61

Post by dhosek »

a1369209993 wrote: post #54
hinkley wrote: post #39

Earlier quoted context omitted.

Or a perennial favorite of mine: $ process Some Image Name.png Could not find file “Some” $ process “Some Image Name.png” Done.

> Some Image Name.png ... Urg, that . If I ever implement a bespoke file system format, it is going to be encoding-level impossible to represent file names with spaces. Not FAT-style[0] "the spec says to replace that with a underscore" or something, but more "the on-disk character encoding does not contain any sequence of bits that represents space". 0: (non-ex-)FAT stores filenames in all caps, but the data of disk…

Meh, I remember the move from DOS 3.3 to ProDOS back in the Apple //e days and the loss of spaces in filenames was something that seemed a regression to me.

Re: How Rust 1.64 became faster on Windows

#62

Post by dhosek »

dhosek wrote: post #61
a1369209993 wrote: post #54

Earlier quoted context omitted.

> Some Image Name.png ... Urg, that . If I ever implement a bespoke file system format, it is going to be encoding-level impossible to represent file names with spaces. Not FAT-style[0] "the spec says to replace that with a underscore" or something, but more "the on-disk character encoding does not contain any sequence of bits that represents space". 0: (non-ex-)FAT stores filenames in all caps, but the data of disk…

Meh, I remember the move from DOS 3.3 to ProDOS back in the Apple //e days and the loss of spaces in filenames was something that seemed a regression to me.

I’d rather see a ban on non-Unicode strings as file paths. ^&*# Windows.

Re: How Rust 1.64 became faster on Windows

#63

Post by hinkley »

dhosek wrote: post #61
a1369209993 wrote: post #54

Earlier quoted context omitted.

> Some Image Name.png ... Urg, that . If I ever implement a bespoke file system format, it is going to be encoding-level impossible to represent file names with spaces. Not FAT-style[0] "the spec says to replace that with a underscore" or something, but more "the on-disk character encoding does not contain any sequence of bits that represents space". 0: (non-ex-)FAT stores filenames in all caps, but the data of disk…

Meh, I remember the move from DOS 3.3 to ProDOS back in the Apple //e days and the loss of spaces in filenames was something that seemed a regression to me.

And all this time I’ve been blaming Windows for bringing us white spaces in file names.

Re: How Rust 1.64 became faster on Windows

#64

Post by tnh »

londons_explore wrote: post #22
wongarsu wrote: post #5

Great to see how huge the benefit of profile-guided optimization is. I feel it's one of the more underappreciated techniques. Rust adding support for it on windows, and showcasing what a big improvement it makes on the compiler is pretty big (in addition to just having a faster compiler)

Unfortunately, many projects never benefit from PGO, because there is quite a lot of complexity involved in setting up a profiling workload, storing the profile somewhere, and using it for future builds. I'd like compiler writers to embed a 'default profile' into the compiler, which uses data from as much opensource code as they can find all over github etc. This default profile will improve the performance of lots o…

Agree this difficulty is the biggest obstacle to PGO's success. A language/ecosystem that works out how to integrate this as smoothly as testing would have a sizeable performance boost in practice.

The default profile is a nice hack. We do this by default for C++ builds at [company], it works great. Teams that care can build a custom profile which performs better, but most don't.

> I'd like compiler writers to embed a 'default profile' into the compiler, which uses data from as much opensource code as they can find all over github etc.

Working out how to build, let alone profile all that code is no joke. And the result will be large, and maybe not that much overlap with the average program. As a sibling points out, maybe using ML to recognize patterns instead of concrete code would help?

I'd settle for profiling of the standard library. In an ecosystem like Rust, per-crate default profiles that you could stitch together would be amazing.

Re: How Rust 1.64 became faster on Windows

#67

Post by summerlight »

jeff-davis wrote: post #58

For databases, I'm reluctant to rely on PGO (profile-guided optimization) because the workloads are so varied. There's a risk of over-fitting to the profiled workloads at the expense of others. Though there may be a lot of opportunity with some database subsystems that have a more consistent usage pattern. Edit: also, PGO is closely related to JIT techniques, which are based on current runtime information rather than…

PGO will still likely improve general performance even with biased workloads because in many cases we want compilers to focus on optimizing happy paths, but this is not always well executed even when it's pretty trivial for human eyes.

Re: How Rust 1.64 became faster on Windows

#69

Post by Filligree »

vlovich123 wrote: post #60
jeff-davis wrote: post #58

For databases, I'm reluctant to rely on PGO (profile-guided optimization) because the workloads are so varied. There's a risk of over-fitting to the profiled workloads at the expense of others. Though there may be a lot of opportunity with some database subsystems that have a more consistent usage pattern. Edit: also, PGO is closely related to JIT techniques, which are based on current runtime information rather than…

I think in practice enabling PGO will be a net gain even if it’s suboptimal on some workloads (ie you should still see some performance gain across the board even if the specific workload isn’t profiled). The reason is that it’s using the profiles to make decisions in lieu of heuristics which should be a win even for non profiled workloads because heuristics are essentially just general case profiles (ie tuned to a b…

Throughput isn't everything, and improving OPS at the expensive of tail latency can be a problem. Depends on your specific workload, but it isn't something I'd enable by default.

Re: How Rust 1.64 became faster on Windows

#70

Post by pjmlp »

londons_explore wrote: post #22
wongarsu wrote: post #5

Great to see how huge the benefit of profile-guided optimization is. I feel it's one of the more underappreciated techniques. Rust adding support for it on windows, and showcasing what a big improvement it makes on the compiler is pretty big (in addition to just having a faster compiler)

Unfortunately, many projects never benefit from PGO, because there is quite a lot of complexity involved in setting up a profiling workload, storing the profile somewhere, and using it for future builds. I'd like compiler writers to embed a 'default profile' into the compiler, which uses data from as much opensource code as they can find all over github etc. This default profile will improve the performance of lots o…

That is the beauty of modern JITs with feedback PGO data, it can be saved across execution sessions and with time the data with grow towards an optimal data point.
Post reply on HN