4 ms·

Use a sampling profiler. They're faster, more accurate, and don't require recompiling.

by mhh__ 4y ago

AlotOfReading 4y ago
On the other hand, it's a lot more difficult to implement a sampling profiler than an instrumenting profiler on a bare metal target. There's definitely a niche for the latter and I've made use of the GCC instrumentation hooks for all sorts of analysis tools over the years.
- mhh__ 4y ago
  I suppose you're right but working on a compiler/language has made me very wary of "But what about embedded!" as a technical point. You can basically argue any point using embedded.
  - AlotOfReading 4y ago
    That's a totally fair objection and one I'm sensitive to as a vocal advocate for moving ES teams away from the custom crap that we've spent the past 40 years doing. I still think the weird limitations you get from "what about embedded" are often just obvious canaries for problems present throughout much of the vast diversity of computing. For example, sampling profilers used to have serious issues on WSL (where perf must still be manually compiled) and WINE. Having instrumentation hooks also makes things like AFL and custom sanitizers possible. The flexibility isn't always reasonable (e.g. don't assume little endian, don't assume 8-bit bytes), but there may be valid use cases that weren't considered at the toolchain/language level.
gnufx 4y ago
"more accurate"? The rationale for (typically expensive) tracing in HPC circles is that sampling can miss things you want to pick up. I think that's also covered in the vi-hps.org workshop introductions, for instance. (It doesn't necessarily involve recompilation.)
- mhh__ 4y ago
  "More accurate" is a condensed version of a longer (disclaimer-attached) statement about how I think they're more useful for typical profiling. If you want to know the exact ratios of how hot code is, then yes instrumentation can be a godsend, however in my experience most people are simply mislead by them because a naive instrumenting profiler usually does not have enough information to capture the right context (i.e. the call stack). For most applications profiling is basically just an exercise in proving your own mental model of execution correct, not fine-tuning (initially at least). https://youtu.be/6TDZa5LUBzY https://youtu.be/6TDZa5LUBzY I gave a talk on this in November.

Use a sampling profiler. They're faster, more accurate, and don't require recompiling.

by mhh__ 4y ago

Use a sampling profiler. They're faster, more accurate, and don't require recompiling.

On the other hand, it's a lot more difficult to implement a sampling profiler than an instrumenting profiler on a bare metal target. There's definitely a niche for the latter and I've made use of the GCC instrumentation hooks for all sorts of analysis tools over the years.

mhh__ 4y ago
I suppose you're right but working on a compiler/language has made me very wary of "But what about embedded!" as a technical point. You can basically argue any point using embedded.
- AlotOfReading 4y ago
  That's a totally fair objection and one I'm sensitive to as a vocal advocate for moving ES teams away from the custom crap that we've spent the past 40 years doing. I still think the weird limitations you get from "what about embedded" are often just obvious canaries for problems present throughout much of the vast diversity of computing. For example, sampling profilers used to have serious issues on WSL (where perf must still be manually compiled) and WINE. Having instrumentation hooks also makes things like AFL and custom sanitizers possible. The flexibility isn't always reasonable (e.g. don't assume little endian, don't assume 8-bit bytes), but there may be valid use cases that weren't considered at the toolchain/language level.

gnufx 4y ago

"more accurate"? The rationale for (typically expensive) tracing in HPC circles is that sampling can miss things you want to pick up. I think that's also covered in the vi-hps.org workshop introductions, for instance. (It doesn't necessarily involve recompilation.)

mhh__ 4y ago
"More accurate" is a condensed version of a longer (disclaimer-attached) statement about how I think they're more useful for typical profiling. If you want to know the exact ratios of how hot code is, then yes instrumentation can be a godsend, however in my experience most people are simply mislead by them because a naive instrumenting profiler usually does not have enough information to capture the right context (i.e. the call stack). For most applications profiling is basically just an exercise in proving your own mental model of execution correct, not fine-tuning (initially at least). https://youtu.be/6TDZa5LUBzY https://youtu.be/6TDZa5LUBzY I gave a talk on this in November.