> Panthera represents low-background steel for computer systems. It is an end-to-end, industrial-grade performance model conceived, designed, and hand-crafted entirely by human architects before the era of generative AI. This repository represents over 8 years of work and 6000 individual git commits by 45 people. By making this human-authored codebase public, we hope it serves as a trusted, high-watermark reference for human engineers and future automated hardware-modeling tools alike.
This is a cycle accurate simulator. It takes a list of instructions and simulates how long it would take to actually execute those instructions. In addition it keeps track of counters for various things (cache misses, interrupts, etc). Correlation refers to making sure the counter values reported by the sim are within some ballpark of the same values on a real chip. Cycle accurate sims are used for architecture research (trying out new features) as well as pre-silicon software work - chip isn't taped out but you want to start building a compiler. They are generally very slow (1000x slower than running on device) because they are generally written by HW people who have no idea how to write fast code. I would be interested to know how fast this one is.
Is it really a “write fast code” problem? I always assumed 1000x was more of a ceiling because of how much must be modeled. Think of how emulating a different architecture often runs at least 10x slower, and there is significantly less work there to do.
The reason is not bad SW engineering for the simulator, but rather a different goal.
Cycle accurate simulations means you emulated the exact CPU behaviour - easily spending 1000 instructions to compute what happened and maybe even log the results for later inspection. You want to be flexible to try different things, so not over optimize and still compare detailed behaviour.
If you build a performance multi core CPU and emulated on a single regular core, I would not be surprised to be 1000000x the runtime.
If you think a little bit harder about this you will realize this is impossible. The hardware modeling people are the SMEs - they read the arch spec and implement the sim to match as closely as possible.
Also speaking from experience at one of the largest chip orgs in the world, it's empirically not the case.
Yes, but for now it is well behind the cores designed by the Arm company or by NVIDIA for server CPUs, or the other Arm-based cores of Apple and Qualcomm.
The server CPUs of Amazon and Microsoft use cores designed by the Arm company.
Nonetheless it is very good that now Ampere has completely documented their core.
With good documentation, either written, or even better, provided by such a simulator, it is frequently possible to optimize a critical application to achieve a better performance on the documented CPU, than on a faster, but undocumented CPU.
Until now, only the Arm company provided adequate optimization documentation for their CPUs (possibly also Fujitsu for their customers, but I do not know anything about that).
The other designers of Arm cores, Apple, Qualcomm and NVIDIA, suck badly at providing technical documentation for their hardware.
> Panthera represents low-background steel for computer systems. It is an end-to-end, industrial-grade performance model conceived, designed, and hand-crafted entirely by human architects before the era of generative AI. This repository represents over 8 years of work and 6000 individual git commits by 45 people. By making this human-authored codebase public, we hope it serves as a trusted, high-watermark reference for human engineers and future automated hardware-modeling tools alike.
This is a cycle accurate simulator. It takes a list of instructions and simulates how long it would take to actually execute those instructions. In addition it keeps track of counters for various things (cache misses, interrupts, etc). Correlation refers to making sure the counter values reported by the sim are within some ballpark of the same values on a real chip. Cycle accurate sims are used for architecture research (trying out new features) as well as pre-silicon software work - chip isn't taped out but you want to start building a compiler. They are generally very slow (1000x slower than running on device) because they are generally written by HW people who have no idea how to write fast code. I would be interested to know how fast this one is.
Is it really a “write fast code” problem? I always assumed 1000x was more of a ceiling because of how much must be modeled. Think of how emulating a different architecture often runs at least 10x slower, and there is significantly less work there to do.
The reason is not bad SW engineering for the simulator, but rather a different goal.
Cycle accurate simulations means you emulated the exact CPU behaviour - easily spending 1000 instructions to compute what happened and maybe even log the results for later inspection. You want to be flexible to try different things, so not over optimize and still compare detailed behaviour.
If you build a performance multi core CPU and emulated on a single regular core, I would not be surprised to be 1000000x the runtime.
In larger orgs these cycle accurate simulators are generally written by SW people (or SW people with a HW background).
If you think a little bit harder about this you will realize this is impossible. The hardware modeling people are the SMEs - they read the arch spec and implement the sim to match as closely as possible.
Also speaking from experience at one of the largest chip orgs in the world, it's empirically not the case.
Speaking from experience, you are both right. It depends on the team, even within the same company.
Too bad they can't use this to design a high performance core.
It's used to validate a high performance core.
I thought Ampere has their own data center core
Yes, but for now it is well behind the cores designed by the Arm company or by NVIDIA for server CPUs, or the other Arm-based cores of Apple and Qualcomm.
The server CPUs of Amazon and Microsoft use cores designed by the Arm company.
Nonetheless it is very good that now Ampere has completely documented their core.
With good documentation, either written, or even better, provided by such a simulator, it is frequently possible to optimize a critical application to achieve a better performance on the documented CPU, than on a faster, but undocumented CPU.
Until now, only the Arm company provided adequate optimization documentation for their CPUs (possibly also Fujitsu for their customers, but I do not know anything about that).
The other designers of Arm cores, Apple, Qualcomm and NVIDIA, suck badly at providing technical documentation for their hardware.
Ampere's cores are pretty high performing, have been in the ballpark of AWS's Graviton cores, for example.
Not even close. Graviton 4 and 5 absolutely smoke anything Ampere has released to date.