pmu-tools
hotspot
pmu-tools | hotspot | |
---|---|---|
3 | 16 | |
1,913 | 3,882 | |
- | 1.4% | |
9.2 | 9.3 | |
15 days ago | 4 days ago | |
Python | C++ | |
GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pmu-tools
-
Gallery of Processor Cache Effects
I am not seeing it mentioned anywhere, but for people looking for a good starting point on "low-level" CPU performance debugging, intel's CPU top-down u-architecture method (https://www.intel.com/content/www/us/en/docs/vtune-profiler/...) is a good systematic way to understand where you CPU is speeding most of it's cycle.
They also have two tools which basically implement this analysis and spit a bunch of very useful metric that are actionable and very easy to understand
- Intel Vtune is a fantastic tool to start with. It's currently free to use, support most OSes and very friendly to use for beginner.
- Intel pmu-tools (https://github.com/andikleen/pmu-tools) is basically command line version of Vtune.
-
if you had to restart at 0 knowledge what would you do?
Install some tool that would help you see the performance of your system, like a graph of the CPU usage, the top processes being used, disk activity/read/write, etc. Every time you run your program, glance at those numbers, eventually you'll develop an intuition. Basically write code and profile. A good exercise would be practicing with data structures, this site has an exhaustive list of them, find some stuff that's interesting then google the implementation, then build it yourself, test it, debug, profile, optimize, and understand the performance constraints. Eventually you'll develop better understanding and can compare between other people's works, optimizing them. If you want to go beyond, read some papers on lock-free algorithms https://github.com/JCTools/JCTools/tree/master/resources then read Brendan Gregg's blog and books. Read about how profiling tools work https://github.com/andikleen/pmu-tools/wiki/toplev-manual
-
Linux Perf Examples
Toplev is a godsend (thank you Andi Kleen!). If you work with perf you'll love this.
https://github.com/andikleen/pmu-tools
hotspot
- Hotspot: A GUI for the Linux perf profiler
-
What is your favourite profiling tool for C++?
perf with Hotspot 👌
-
Profiling C code on an M1 mac
If you’re able to use perf on Linux, I would recommend hotspot for visualizing the results.
-
What is the problem with transfer speeds withing Dolphin?
I can recommend you using the https://github.com/KDAB/hotspot/ tool whenever you want to study performance.
-
Data-driven performance optimization with Rust and Miri
Every Linux C/C++/Rust developer should know about https://github.com/KDAB/hotspot. It's convenient and fast. I use it for Rust all the time, and it provides all of these features on the back of regular old `perf`.
-
How to interpret a flamegraph?
Flamegraphs alone aren't a full picture of what your application is doing, but it can give you hints as to where to look. Another tool I often use is Hotspot which can open the perf.data file and provide more options for filtering and digging into the gathered data beyond the single flamegraph.
-
Twenty Years of Valgrind
Ignore the command, it's just a placeholder to get meaningful values. The -d flag adds basic cache events, by adding another -d you also get load and load miss events for the dTLB, iTLB and L1i cache.
But as mentioned, you can instrument any event supported by your system. Including very obscure events such as uops_executed.cycles_ge_2_uops_exec (Cycles where at least 2 uops were executed per-thread) or frontend_retired.latency_ge_2_bubbles_ge_2 (Retired instructions that are fetched after an interval where the front-end had at least 2 bubble-slots for a period of 2 cycles which was not interrupted by a back-end stall).
You can also record data using perf-record(1) and inspect them using perf-report(1) or - my personal favorite - the Hotspot tool (https://github.com/KDAB/hotspot).
Sorry for hijacking the discussion a little, but I think perf is an awesome little tool and not as widely known as it should be. IMO, when using it as a profiler (perf-record), it is vastly superior to any language-specific built-in profiler. Unfortunately some languages (such as Python or Haskell) are not a good fit for profiling using perf instrumentation as their stack frame model does not quite map to the C model.
-
Linux Perf Examples
> [...] how Perf compares to vendor tools like vTune [...] ?
Regarding the hardware events that Perf can capture on x86, it has pretty much all of them. So it should be equivalent to vTune for all practical purposes.
The big difference is in the UI -- or absence thereof. Perf is a low-level tool and its output is mostly text files. There is a curses-based TUI for perf-report (and even gtk version, but it is essentially the same as the TUI, just using GTK2 widgets), but that's about it.
By contrast, vTune comes with a heavy (electron-based?) GUI and is quite helpful in guiding beginners, with many graphs and explanations.
Of course, one can (and is expected to) complement Perf with an assortment of tools that process its output for visualization. For example, the flamegraph [1] and heat map [2] tools described in the article. But also KDAB hotspot [3] or HPerf for a vTune-style perf-report.
[1] https://github.com/brendangregg/FlameGraph
[2] https://github.com/brendangregg/HeatMap
[3] https://github.com/KDAB/hotspot
[4] https://www.poirrier.ca/hperf/
-
Parsers that don't yet exist?
https://github.com/KDAB/hotspot might contain parsing code you could use as an example (other than perf script). It always accepts raw perf.data, and there doesn't seem to be a way to feed it the output of perf script, so it might be parsing it directly instead of calling perf script.