Apple's new Processor Trace instrument is incredible (victorwynne.com)

> Instead of statistical sampling like most profilers, you get a complete picture of your app’s execution flow.

Potentially interesting, but it's not really clear whether this is anything new or not. valgrind + kcachegrind does this too.

https://developer.apple.com/documentation/xcode/analyzing-cp...

These screenshots look a lot like kcachegrind with a slightly reimagined UI. Is there actually anything new here, or is this another case of Apple finally catching up to the open source world?

I feel like it probably would work on older hardware, this very much smacks of forced obsolescence. Just guessing though.

Finally, a processor manufacturer defects from the obfuscatory equilibrium. Granted, Apple’s processor people are not saints—I’ve yet to see even a full table of throughputs, latencies, and port loads from them, let alone an accurate CPU model—but I welcome anything that might maybe, hopefully, pretty please start a race of giving more accurate data to people doing low-level optimization.

Longer term I sort of dream of doing computing from the inside out, using all this tracing data we've started gathering not just for observability but as a log and engine of compute: the record of what computing has been done as an event-source, for an event sourcing computing architecture.

Is there anything like this for more commodity arm cores (neoverse v2) or do we think the insights from apple silicon cores will generalize well to those other ARM architectures?

Hardware wise, this seems quite similar to many existing Tracing systems from other CPU cores.

I know Arm and XTensa have offered on board trace buffers for ages so operating systems could record themselves.

What's neat here is that Apple has bundled this nicely into a polished developer tool rather than one more discreet tool.

This is just standard instruction trace.

Intel has supported such capability via Intel Processor Trace (PT) since at least 2014 [1]. Here is a full trace recorder built by Jane Street feeding into standard program trace visualizers [2].

ARM has supported such capability via the standard CoreSight Program Trace Macrocell (PTM)[3]/Embedded Trace Macrocell (ETM)[4] since at least 2000.

If you pair it with standard data trace, which is less commonly available, then you have the prerequisites for a hardware trace time travel debugger as originally seen in the early 2000s [5]

You can get similar performance/function tracing entirely in software via software-instrumented instruction trace and similar debugging information (though less granular performance information) via record-replay time travel debugger recordings.

[1] https://www.intel.com/content/www/us/en/support/articles/000...

[2] https://blog.janestreet.com/magic-trace/

[3] https://developer.arm.com/documentation/ihi0035/b/Program-Fl...

[4] https://developer.arm.com/documentation/ddi0158/d

[5] https://jakob.engbloms.se/archives/1564

> The catch, as usual with new Apple features, is the hardware requirements. This only works on M4 chips and iPhone 16 devices, which means you’re out of luck if you’re still developing on older hardware. It’s frustrating but not surprising. Apple has a habit of using new developer tools to push hardware upgrades.

This seems unfair. Isn’t there a pretty good likelihood that the number of performance counters in the CPU (or whatever) simply don’t exist in the production versions of the previous CPUs?