Presumably also the author has now learned this, after discovering at the end that compiling with the sanitizer enabled immediately showed which is the bug, which would have saved a lot of time if he had always used it.
> Notice how Apple focused on running their CPUs no higher then 4.2Ghz or something... So even if their CPU boosts to 100%, that thermal peak will be maybe 7W.
If you max out your processor it will be more than happy to draw 20W+
Was gonna say the same thing. There are tons of projects that support older unsupported OS versions or even different platforms. Whether that's macOS, Windows, or older versions of the Linux kernel.
> Admittedly the impression isn’t helped by a dreadful piece of psychology, as those E cores at 100% are probably running at a frequency a quarter of those of P cores shown at the same 100%
It’s about half, actually
> The fact that an idle Mac has over 2,000 threads running in over 600 processes is good news
Your first example is a CPU limitation that Instruments doesn't model (does perf?), but is still mostly better than Intel chips that are limited to 4 dynamic counters (I think still? At least that's what I see in the Alder Lake's Golden Cove perfmon files...)
Your second example, is the complaint that Instruments doesn't have flamegraph visualization? That was true a decade ago when it was written, and is not true today. Or that Instrument's trace file format isn't documented?
So far I have provided you with examples of how Instruments.app loses to perf. Perf does not have these limitations. You have not provided any examples in the reverse direction.
Both of your examples are actually very good at explaining my point. Both Instruments and perf largely expose the same information, since they use trace features in the hardware together with kernel support to profile code. Where they differ is the UI they provide. perf provides almost nothing; Instruments provides almost everything. This is because perf is basically a library and Instruments is a tool that you use to find performance problems.
Why do I like Instruments and think it is better? Because the people who designed it optimized it for solving real performance problems. There are a bunch of "templates" that are focused on issues like "why is my thing so slow, what is it doing" to "why am I using too much memory" to "what network traffic is coming out of this app". These are real, specific problems while perf will tell you things like "oh this instruction has a 12% cache miss rate because it got scheduled off the core 2ms ago". Which is something Instruments can also tell you, but the idea is that this is totally the wrong interface that you should be presenting for doing performance work since just presenting people with data is barely useful.
What people do instead with perf is they have like 17 scripts 12 of which were written by Brendan Gregg to load the info into something that can be half useful to them. This is to save you time if you don't know how the Linux kernel works. Part of the reason why flamegraphs and Perfetto are so popular is because everyone is so desperate to pull out the info and get something, anything, that's not the perf UI that they settle for what they can get. Instruments has exceptionally good UI for its tools, clearly designed by people who solve real performance problems. perf is a raw data dump from the kernel with some lipstick on it.
Mind you, I trust the data that perf is dumping because the tool is rock-solid. Instruments is not like that. It's buggy, sometimes undocumented (to be fair, perf is not great either, but at least it is open source), slow, and crashes a lot. This majorly sucks. But even with this I solve a lot more problems clicking around Instruments UI and cursing at it than I do with perf. And while they are slow to fix things they are directionally moving towards cleaning up bugs and allowing data export, so the problems that you brought up (which are very valid) are solved or on their way towards being solved.
> Because the people who designed it optimized it for solving real performance problems.
The implication that perf is not is frankly laughable. Perhaps one major difference is that perf assumes you know how the OS works, and what various syscalls are doing.
> perf assumes you know how the OS works, and what various syscalls are doing.
You just proved again that it's not optimized for reality because that knowledge can't be assumed as the pool of people trying to solve real performance problems is much wider than the pool with that knowledge
> Nobody's going to pay me (assuming I even had the skills) to optimize for consumer GPUs?
People will but probably less, not many people are doing AI at the edge that can pay the mega millions
> And likewise similar fundamental differences between consumer and cloud hopper (where the majority of the perf is the cloud one's ISA?)
I think Hopper was the version where they did a clean split and it’s only for datacenter
> So I guess I'm wondering if I should buy a GPU myself or should I just rent on the cloud if I wanted to start getting some experience in this field. How do you even get experience in this normally anyways, do you get into really good schools and into their AI labs which have a lot of funding?
You can do performance work on any system you have really it’s just that the details change depending on what you’re targeting. You can definitely learn the basics on like a 3060 by following blog posts
reply