Live data from Hacker News

How Rust 1.64 became faster on Windows

tomaszs2.medium.com

51–60 of 80 posts

Re: How Rust 1.64 became faster on Windows

#53
post #28

Is it possible that the profile is over-fitting to the benchmark tests?

Yes that's likely. But the idea is that even if that's the case, it is still better than no PGO.

Edit: I'd like to add that if the 10-20% mentioned is measured on the benchmark that was used to do the pgo, then that figure might indeed not be representative of the real gain.

Re: How Rust 1.64 became faster on Windows

#54
post #39

Earlier quoted context omitted.

Rust will already end up optimising out the error handling that can't happen because Infallible is an Empty Type (it makes no sense to emit code for an Empty Type because no values of this type can exist, so during monomorphization this code evaporates) (e.g. trying to convert a 16-bit unsigned integer into a 32-bit signed integer can't fail, that always works so its error type is Infallible, whereas trying to conver…

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 is ASCII, so you can just write lowercase letters in the physical directory entries. (I've seen at least one FAT implementation that actually uses that to 'support' lowercase filenames.)

Re: How Rust 1.64 became faster on Windows

#57
post #28

Is it possible that the profile is over-fitting to the benchmark tests?

Their main benchmark test is compiling every publicly released crate on crates.io. This is also their main regression test.

If you manage to overfit against that, it's still probably an amazing general purpose solution.

Re: How Rust 1.64 became faster on Windows

#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 profiles generated a long time ago on a workload that may or may not be representative.

Re: How Rust 1.64 became faster on Windows

#60

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 bunch of OSS software out there). I’m unaware of any research showing PGO being worse than not doing it even if your profile isn’t the workload (you’d probably have to try to specially build such a situation and unlikely to come up in practice).

Have you actually seen otherwise?

Post reply on HN