7 ms·

Arm’s Cortex A510: Two Kids in a Trench Coat

130 points by picture 3y ago

20after4 3y ago
Or maybe it's three raccoons in a trench coat
- leetrout 3y ago
  I read the title as "two kids in trench coats" and was thinking about Columbine.
  - hotsauceror 3y ago
    Yikes. Has the metaphor really fallen that far out of favor? I guess kids don't really need to sneak into R-rated movies any more.
  - chunk_waffle 3y ago
    Same here, the only reason I clicked on the article was to try and find out how they could possibly justify it and then I realized what they meant.
bpye 3y ago
> Two A510 cores can be clustered and share a L2 cache, FPU, and L2 TLB. Arm calls this a merged core configuration, and hopes it’ll increase area efficiency with minimal performance impact. Isn’t this also a lot like what AMD did with Bulldozer?
- skavi 3y ago
  from TFA: > Note on Bulldozer > Bulldozer is an obvious comparison because it also shares substantial resources between core pairs. However, shared resources had little to do with Bulldozer’s performance problems. In fact, Bulldozer was most competitive in multithreaded applications where there could be contention for shared resources. Bulldozer issues came from having less per-thread reordering capacity and higher cache latency than Sandy Bridge in a market where single-thread performance was of paramount importance. Cortex A510 does not target the high performance market. If performance did matter A510 would be held back by its in-order execution scheme, not shared resources. Instead of performance, A510 targets low power and area. Sharing resources fits that goal perfectly.
  - a-french-anon 3y ago
    Yep, I dare to say that Piledriver wasn't bad at all, when you weren't just needing single-threaded performance. Power consumption was horrid, though.
    - hajile 3y ago
      AMD would have been far ahead of the game if they'd made 1 big ALU, 1 big FPU, and 1-3 little ALUs. They'd have been competitive on single-thread performance while getting a big boost in multithreaded performance without all the complexity of SMT.
- AlotOfReading 3y ago
  That's not an inherently terrible thing. Bulldozer did many things wrong that led to that awful performance, it wasn't just the CMT. AMD sacrificed a lot to get the frequencies up, and every other number in the system suffered for it. Worse, the schedulers available at the time weren't smart enough to properly keep the things turboing, so that sacrifice ended up being for naught. ARM is competent enough to avoid the obvious pitfalls there and it's a decent strategy for the what the A5xx series is supposed to be (power efficient/cost-optimized).
  - happycube 3y ago
    So ironic given how AMD ran circles around intel during the P4 era... and AMD didn't have the things intel had to fall back on when Netburst/Tejas really went off the rails.
- rsaxvc 3y ago
  Architecturally similar to Sun S1 cores found in Niagara/T1 chips, when SMT is disabled.
- Symmetry 3y ago
  The problem with Bulldozer was mostly the wonky cache hierarchy, not the modularization. Well, the shared front end was a big problem but AMD fixed that in Steamroller and the A510 isn't making that mistake.
gchadwick 3y ago
I worked on the A510 (codenamed Klein) at Arm on the L1 memory system design. It was a fun core to work on, really pushing the bounds of what you can do with an in order core and made me realise the out of order/in order boundary is a lot more blurry than you might think. Plenty of out of order stuff happening in the memory system for instance. Whilst there's plenty of reuse from the A55 the memory system was sufficiently different we built the load store unit from scratch. I got the honor of writing the RTL for the new one (normally you'd start with existing RTL and rework it). I wonder how many years those files will live on til they decide to start afresh? It's a real shame the microarchitecture of these things isn't more open articles like this give you some info but not the full picture. I can see why they described it as a '5 entry load buffer' for instance but it's not really accurate to the true microarchitecture. There's also lots of fun details of the crazy things you have to do to hit your frequency target (often where you just ignore certain rare hazard or error conditions and detect them later and fix it up). I'm not at Arm any more (I work on Open Silicon now though around embedded/IoT/Security applications not application class CPU cores). I do miss the days of working on the A510, CPU design is a lot of fun.
- clamchowder 3y ago
  Author here. > I can see why they described it as a '5 entry load buffer' for instance but it's not really accurate to the true microarchitecture. That's what it looks like to software. I can put 5 loads between two other loads that miss cache, and the cache miss latency will overlap. It feels like a 5 entry load buffer to software. I'm more than happy to describe the true microarchitecture if Arm talks about it :) Otherwise it'll be "hey, how does it look to software from a performance perspective?" > There's also lots of fun details of the crazy things you have to do to hit your frequency target (often where you just ignore certain rare hazard or error conditions and detect them later and fix it up). Yeah people do this everywhere. Sometimes you can find 20+ cycle penalties for stuff like a load that depends on a page-crossing store. The trick is making sure the hazards are indeed rare relative to the penalty. Also the biggest penalties in practice are cache misses and DRAM latency in the hundreds of cycles. Intra-core penalties never come close.
- Topfi 3y ago
  Amazing to hear from someone so deeply involved in the design process. Thanks for clarifying that some parts of the article are not 100% accurate. Concerning: > [...] really pushing the bounds of what you can do with an in order core and made me realise the out of order/in order boundary is a lot more blurry than you might think. Plenty of out of order stuff happening in the memory system for instance. Are you able to expand on that a bit or point me in a direction on where to get some more information (books, articles, papers)? I'd love to read some more on what can be done to bridge the gap between the two and the specifics of A510 in that regard. Only if you want and are able to (NDA wise) of course. Would you speculate that a future design is going to lean even more heavily/be entirely based around OOE or is such a "hybrid approach" (please excuse my layman terms) still something that can serve certain applications (e.g. space efficiency) well in the future? I understand if you don't want to make a statement one-way or another of course.
em500 3y ago
If you're wondering about the actual performance of these cores, I think they'll end up around 300-350 single thread Geekbench6 points (comparable to Intel Goldmont N4020, or the ancient Core 2 E8400/Q9500). This is based on extrapolating ARMs public estimates (35% better than A55, or up to 90% of A73 performance). The A55 (2017) wasn't great from a perf/watt standpoint (modest power savings but massive performance reduction vs their A7x middle cores), and it doesn't look like the A510 (2021) is a big leap forward. It's nowhere near Apple's very impressive efficiency cores (which reach A7x like performance at lower power than the A55). Anandtech has more details: https://www.anandtech.com/show/16693/arm-announces-mobile-armv9-cpu-microarchitectures-cortexx2-cortexa710-cortexa510/4 https://www.anandtech.com/show/16693/arm-announces-mobile-ar... As of the latest generation of SoCs, Apple’s efficiency cores were around 4x faster than any Cortex-A55 based SoC. Which, running at roughly the same system active power, also made them 3-4x more efficient in the traditional benchmarks. As presented, a theoretical A510 SoC won't be able to close that efficiency gap at all. See also https://www.anandtech.com/show/16983/the-apple-a15-soc-performance-review-faster-more-efficient/2 https://www.anandtech.com/show/16983/the-apple-a15-soc-perfo... especially the last graph, which shows how far ahead Apple is on perf/watt.
- rsaxvc 3y ago
  Given the memory latency impact on in-order cores, I wonder how much of the gap is core design and how much is Apple's tending to fit much larger caches to their designs.
- green7ea 3y ago
  There's perf/watt but also area on the core that's an important factor. Watt and area are often related but not always. Do you know how the A510 cores and Apple's efficiency cores compare on area?
  - skavi 3y ago
    Apple’s efficiency cores are significantly larger than A5x cores.
    - 3y ago

130 points by picture 3y ago

20after4 3y ago

Or maybe it's three raccoons in a trench coat

leetrout 3y ago
I read the title as "two kids in trench coats" and was thinking about Columbine.
- hotsauceror 3y ago
  Yikes. Has the metaphor really fallen that far out of favor? I guess kids don't really need to sneak into R-rated movies any more.
- chunk_waffle 3y ago
  Same here, the only reason I clicked on the article was to try and find out how they could possibly justify it and then I realized what they meant.

bpye 3y ago

> Two A510 cores can be clustered and share a L2 cache, FPU, and L2 TLB. Arm calls this a merged core configuration, and hopes it’ll increase area efficiency with minimal performance impact. Isn’t this also a lot like what AMD did with Bulldozer?

skavi 3y ago
from TFA: > Note on Bulldozer > Bulldozer is an obvious comparison because it also shares substantial resources between core pairs. However, shared resources had little to do with Bulldozer’s performance problems. In fact, Bulldozer was most competitive in multithreaded applications where there could be contention for shared resources. Bulldozer issues came from having less per-thread reordering capacity and higher cache latency than Sandy Bridge in a market where single-thread performance was of paramount importance. Cortex A510 does not target the high performance market. If performance did matter A510 would be held back by its in-order execution scheme, not shared resources. Instead of performance, A510 targets low power and area. Sharing resources fits that goal perfectly.
- a-french-anon 3y ago
  Yep, I dare to say that Piledriver wasn't bad at all, when you weren't just needing single-threaded performance. Power consumption was horrid, though.
  - hajile 3y ago
    AMD would have been far ahead of the game if they'd made 1 big ALU, 1 big FPU, and 1-3 little ALUs. They'd have been competitive on single-thread performance while getting a big boost in multithreaded performance without all the complexity of SMT.
AlotOfReading 3y ago
That's not an inherently terrible thing. Bulldozer did many things wrong that led to that awful performance, it wasn't just the CMT. AMD sacrificed a lot to get the frequencies up, and every other number in the system suffered for it. Worse, the schedulers available at the time weren't smart enough to properly keep the things turboing, so that sacrifice ended up being for naught. ARM is competent enough to avoid the obvious pitfalls there and it's a decent strategy for the what the A5xx series is supposed to be (power efficient/cost-optimized).
- happycube 3y ago
  So ironic given how AMD ran circles around intel during the P4 era... and AMD didn't have the things intel had to fall back on when Netburst/Tejas really went off the rails.
rsaxvc 3y ago
Architecturally similar to Sun S1 cores found in Niagara/T1 chips, when SMT is disabled.
Symmetry 3y ago
The problem with Bulldozer was mostly the wonky cache hierarchy, not the modularization. Well, the shared front end was a big problem but AMD fixed that in Steamroller and the A510 isn't making that mistake.

gchadwick 3y ago

I worked on the A510 (codenamed Klein) at Arm on the L1 memory system design. It was a fun core to work on, really pushing the bounds of what you can do with an in order core and made me realise the out of order/in order boundary is a lot more blurry than you might think. Plenty of out of order stuff happening in the memory system for instance. Whilst there's plenty of reuse from the A55 the memory system was sufficiently different we built the load store unit from scratch. I got the honor of writing the RTL for the new one (normally you'd start with existing RTL and rework it). I wonder how many years those files will live on til they decide to start afresh? It's a real shame the microarchitecture of these things isn't more open articles like this give you some info but not the full picture. I can see why they described it as a '5 entry load buffer' for instance but it's not really accurate to the true microarchitecture. There's also lots of fun details of the crazy things you have to do to hit your frequency target (often where you just ignore certain rare hazard or error conditions and detect them later and fix it up). I'm not at Arm any more (I work on Open Silicon now though around embedded/IoT/Security applications not application class CPU cores). I do miss the days of working on the A510, CPU design is a lot of fun.

clamchowder 3y ago
Author here. > I can see why they described it as a '5 entry load buffer' for instance but it's not really accurate to the true microarchitecture. That's what it looks like to software. I can put 5 loads between two other loads that miss cache, and the cache miss latency will overlap. It feels like a 5 entry load buffer to software. I'm more than happy to describe the true microarchitecture if Arm talks about it :) Otherwise it'll be "hey, how does it look to software from a performance perspective?" > There's also lots of fun details of the crazy things you have to do to hit your frequency target (often where you just ignore certain rare hazard or error conditions and detect them later and fix it up). Yeah people do this everywhere. Sometimes you can find 20+ cycle penalties for stuff like a load that depends on a page-crossing store. The trick is making sure the hazards are indeed rare relative to the penalty. Also the biggest penalties in practice are cache misses and DRAM latency in the hundreds of cycles. Intra-core penalties never come close.
Topfi 3y ago
Amazing to hear from someone so deeply involved in the design process. Thanks for clarifying that some parts of the article are not 100% accurate. Concerning: > [...] really pushing the bounds of what you can do with an in order core and made me realise the out of order/in order boundary is a lot more blurry than you might think. Plenty of out of order stuff happening in the memory system for instance. Are you able to expand on that a bit or point me in a direction on where to get some more information (books, articles, papers)? I'd love to read some more on what can be done to bridge the gap between the two and the specifics of A510 in that regard. Only if you want and are able to (NDA wise) of course. Would you speculate that a future design is going to lean even more heavily/be entirely based around OOE or is such a "hybrid approach" (please excuse my layman terms) still something that can serve certain applications (e.g. space efficiency) well in the future? I understand if you don't want to make a statement one-way or another of course.

em500 3y ago

If you're wondering about the actual performance of these cores, I think they'll end up around 300-350 single thread Geekbench6 points (comparable to Intel Goldmont N4020, or the ancient Core 2 E8400/Q9500). This is based on extrapolating ARMs public estimates (35% better than A55, or up to 90% of A73 performance). The A55 (2017) wasn't great from a perf/watt standpoint (modest power savings but massive performance reduction vs their A7x middle cores), and it doesn't look like the A510 (2021) is a big leap forward. It's nowhere near Apple's very impressive efficiency cores (which reach A7x like performance at lower power than the A55). Anandtech has more details: https://www.anandtech.com/show/16693/arm-announces-mobile-armv9-cpu-microarchitectures-cortexx2-cortexa710-cortexa510/4 https://www.anandtech.com/show/16693/arm-announces-mobile-ar... As of the latest generation of SoCs, Apple’s efficiency cores were around 4x faster than any Cortex-A55 based SoC. Which, running at roughly the same system active power, also made them 3-4x more efficient in the traditional benchmarks. As presented, a theoretical A510 SoC won't be able to close that efficiency gap at all. See also https://www.anandtech.com/show/16983/the-apple-a15-soc-performance-review-faster-more-efficient/2 https://www.anandtech.com/show/16983/the-apple-a15-soc-perfo... especially the last graph, which shows how far ahead Apple is on perf/watt.

rsaxvc 3y ago
Given the memory latency impact on in-order cores, I wonder how much of the gap is core design and how much is Apple's tending to fit much larger caches to their designs.
green7ea 3y ago
There's perf/watt but also area on the core that's an important factor. Watt and area are often related but not always. Do you know how the A510 cores and Apple's efficiency cores compare on area?
- skavi 3y ago
  Apple’s efficiency cores are significantly larger than A5x cores.
  - 3y ago