How Rust 1.64 became faster on Windows
21–30 of 80 posts
Re: How Rust 1.64 became faster on Windows
#22Great 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 of libraries that everyone uses, and will probably still help closed source code (since it will probably be written in a similar style to opensource code).
Re: How Rust 1.64 became faster on Windows
#23No post body was provided.
Re: How Rust 1.64 became faster on Windows
#24Great 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…
I think you can already build shared libraries with PGO, although this doesn't really work with header only libraries for C++...
Re: How Rust 1.64 became faster on Windows
#25Great 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…
I think a cool project to work on would be model-based ML-generated profiles that takes a set of parameters like:
* application type (e.g. client, server, batch process, parser, etc.) * target architecture, vendor, model, etc. * target resources like RAM, HD Types, Network interfaces, etc.
I would think you could get very close to an actual PGO level of performance with just a handful of parameters and lot of data.
Re: How Rust 1.64 became faster on Windows
#26Great 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…
> 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.
What would be the point? The whole thing about PGO is that it measures which paths of _your_ code are "hot".
Re: How Rust 1.64 became faster on Windows
#27Earlier quoted context omitted.
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…
> 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. What would be the point? The whole thing about PGO is that it measures which paths of _your_ code are "hot".
Consider error handling paths.
Re: How Rust 1.64 became faster on Windows
#28Is it possible that the profile is over-fitting to the benchmark tests?
Re: How Rust 1.64 became faster on Windows
#29No post body was provided.
Re: How Rust 1.64 became faster on Windows
#30What is the common consensus on benchmarking test suites in Rust? From what I understood: Criterion was the gold standard, but there is a built-in benchmark suite but that is only supported in Nightly. What’s the difference?
There's the bencher crate as well, which provides a similar API to nightly through macros that work on stable. On one of the projects I maintain we reverted from criterion to bencher because the criterion results sometimes made no sense.