31–40 of 80 posts
Earlier quoted context omitted.
A single flagged comment and we've declared someone irredeemable. Amazing. https://news.ycombinator.com/item?id=31738035
I dont think that's right, because there are 6 non-dead comments after that one. But very new accounts are likely to be banned after a single flag, to avoid ban evasion.
Earlier 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".
And lots of your code has similar hot paths to everyone elses code. It turns out that `for x in pixels { }` is probably going to be a hot loop... But `for x in serial_ports { }` probably isn't a hot loop...
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…
Quoted post unavailable.
Quoted post unavailable.
Earlier 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…
Perhaps a better approach would be some sort of per-library profile?
I'm imagining for example a 'profile server', which anyone can upload profiler data to, and that the compiler queries to get profile data for any given file it wants to compile.
Earlier quoted context omitted.
> 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.
(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 convert a 32-bit signed integer into an unsigned one clearly fails for some values, that's a core::num::TryFromIntError you need to handle)
So we're left only with errors which don't happen. But who says? On my workload maybe the profile image file doesn't exist 0% of the time since I'm actually making the image files, so of course they exist, but in your workload the user gets to specify the filename and so they type it wrong about 0.1% of the time, and in somebody else's workload the hostile adversary spews nonsense filename values like "../../../../../etc/passwd" to try to exploit bugs in some PHP code from 15 years ago, so they see almost 10% errors. What would we learn from a "general profile"? Nothing useful.
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…
Earlier quoted context omitted.
Consider error handling paths.
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…
$ process Some Image Name.png
Could not find file “Some”
$ process “Some Image Name.png”
Done.
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…
The difficulty with "as much open source code as they can find" is that we need to execute the code to make a profile. And unless we're running the code under real-world conditions, there's no guarantee that we'll generate a useful profile. So we need to be a little careful about which code we look at from a performance perspective. Even when we have a profile, it's a count of branches taken for the specific code that was compiled, and it's not normally applicable to either a different version of the compiler or any input that's not identical to the input used for profiling. With link-time optimisations, even a "common" profile for library code isn't necessarily going to be useful: which bits of a library we'll try to inline will vary according to the code that's calling it.