A Deep Dive into AMD’s Rome Epyc Architecture

The servethehome review of Rome is a pretty detailed look at the architecture.

https://www.servethehome.com/amd-epyc-7002-series-rome-deliv...

I despair that the market is more interested in things like mobile apps and LED equipped RAM than serious in-depth technical reporting on microprocessor internals.

Anandtech still does that, just no longer written by Anand himself ( He is working in Apple now ). So the writing aren't as good. Even though the technical details are still there.

One of the problem is that the market for these kind of review are very much a niche. And just like all forms of free media, if there aren't enough page view they stop doing it.

I have always thought some of these media will consolidate, I mean I only ever read Anandtech, Servethehome and some Ars, and that is about it. I have RSS Header news feed from a few other sources such as Tom's hardware, Engadget but if Anandtech cover the same topic I always go there first.

Not only has that not happen, most of these website manage to stay afloat catering for different market. But I have no idea how the market segmentation works. I could tell site like Wcctech is sort of 100% rumours site with very little if any technical knowledge in writing. And yet it gathers huge amount of audience.

While others like Tom's Hardware seems to have retain enough of its news reader to become sustainable.

Wikichip is my go-to for these things.

Wikichip is nice, but tbh a lot of this stuff ends up in analyst reports nowadays. Look at conference proceedings if you're interested

I think the tech press still tells us what they can, and stuff like execution ports, reorder windows, etc. is still publicly disclosed. AT talked about what was publicly said about Zen 2 (https://www.anandtech.com/show/14525/amd-zen-2-microarchitec...) and Sunny Cove (https://www.anandtech.com/show/14514/examining-intels-ice-la...). And their reviews do try to report the top observable results (memory latencies, relative performance on different kinds of task, power/clock info) and all that's arguably of more practical importance to lots of folks anyway.

There's also just the trend of modern designs being tricky enough it's harder to infer as much about them and harder to write accessibly about what you do know; it's not super easy to figure out and describe, say, modern branch predictors simply because they're all layering a lot of strategies on each other.

For example, from Haswell on, Agner Fog essentially said Intel's large-core branch predictors are good at lots of things but there's not much he can say about how they work (p29 at https://www.agner.org/optimize/microarchitecture.pdf). Writing code to beat Cortex-A76 prefetchers, AT's Andrei Frumusanu had difficulty fooling them with anything other than essentially-random access patterns and compared them to "black magic" (https://twitter.com/andreif7/status/1102230575522430977). These aren't just random folks saying "wow, CPUs are complicated"; they successfully figured lots of stuff about past generations of CPU.

AMD did reference the TAGE family of branch predictors, which there's lots about in public literature. There might be some broadly interesting stuff in the vendors' contributions to gcc/LLVM (machine models and arch-specific optimizations).

Maybe ARM implementors talk a little more about their stuff? That might have something to do with the dynamics of the relatively open/diverse market for ARM SoCs versus the long-running one-on-one-ish x86 rivalry.

Hard to boil all that down to a single point, but if AMD and Intel want to talk more about the guts of their products, I'm sure plenty of grateful wonks would lap it up. :)

I’m pretty sure they roll their own. I would be surprised if simulation tools were not the most well guarded secrets of these companies.

They have many levels of simulations for their processor designs yes but they’re proprietary.

Oh yes. That's been the dominant approach at least since Computer Architecture: A Quantitative Approach came out in '89. The search space is pretty complicated, though, given the physical interactions as well as the logical ones.

Yeah but they're often trying to predict where the software industry will go years in advance. You can see that in the disagreements between AMD and Intel on AVX-512: there's a chicken and egg situation where it's not always clear what's right to optimise for, as it depends on changing workloads and software platforms. For instance the big chip companies were caught out by the need for low precision maths for AI inferencing. That all came out of Google.

Tools like that are a core part of the design process. You write that software along with the choice of parametrization of the design. It's not an off the shelf thing. But yes, that's how it works.

It's also important to note that decisions like this are hugely workload-specific. There's no single best processor for all applications. In extreme examples: almost every transistor on a vector SIMD unit is wasted when trying to optimize for a client Javascript benchmark; streaming symmetric encryption gets no benefit from L3 cache (which is like half the chip these days!); etc...

http://gem5.org/Main_Page Is an open source CPU simulator.

I used it in undergrad to run benchmarks with different cache sizes and cache coherence strategies to see which were more effective. I'm sure Intel and AMD have much more advanced simulation tools though. Most likely multiple, or at least multiple levels of granularity (so you could do stuff like, simulate these potential branch predictor designs at a gate level, and then turn around and simulate the entire CPU at a higher level of abstraction.)

So yes, plenty of simulators exist, many internal ones as well as gem5* but automated search space exploration, say like with mcmc, isn't in widespread use yet iirc, although plenty of academic papers have explored the topic.

*which I swear every company has their own version of

> Every documentation I've seen is quite light on the branch prediction improvements.

In one of the pictures in the article, it says the new architecture uses the TAGE Branche predictor. This is likely based on the work of Andre Seznec. There are many articles on the implementation (but they can be difficult to understand if you are not already familiar with his work).

I've implemented the bare bone predictor on a computer architecture course, you can see an abridged version of my presentation slides here[1]. Note this only describes the bare bone predictor, in recent work Andre Senzec added a Loop predictor and a Statistical Correlation Unit to increase the accuracy.

There are some work using TAGE with perceptions in the Statistical Correlation unit.

[1] https://docs.google.com/presentation/d/1aUrwD-ENYPB7pMrCoYmE...

> the picture from AMD in this review makes me think it can hit 16 memory channels with the two socket version. Does anyone know if this is true?

Yes, if the motherboard provides all the necessary slots. The inter-socket communication is achieved by re-purposing CPU pins used for PCIe, not pins used for DRAM. Each CPU has the full 8 DRAM channels of its own.

Somewhere at 50 to 60% down in the article:

"There are a total of eight DDR4 memory controllers on this hub chip, the same number in total that were on the Naples complex; both support one DIMM per channel and have two channels per controller, but Rome memory runs slightly faster – 3.2 GHz versus 2.67 GHz – and therefore with all memory slots filled, yields a maximum of 410 GB/sec of peak memory bandwidth per socket. That’s 45 percent higher than the Cascade Lake Xeon SP processor, which has six memory controllers for a total of 282 GB/sec of memory bandwidth running at 2.93 GHz and 21 percent higher than the 340 GB/sec that Naples turns in running that 2.67 GHz DRAM. (Those are ratings for two-socket servers.)"

Are you replying to this thread? https://news.ycombinator.com/item?id=20724679

But separate silicon is what gives AMD an almost insurmountable cost advantage. They can bin each chiplet separately, their yields are much higher because each die is smaller and the cherry on top is the different, cheaper process for the I/O die.