AMD Gives Details on EPYC Zen4: Genoa and Bergamo, Up to 96 and 128 Cores | Hacker News Reader

AMD Gives Details on EPYC Zen4: Genoa and Bergamo, Up to 96 and 128 Cores

anandtech.com

138 pointsrbanffy54 comments

Zen4 has been widely rumored* to support AVX-512. Did AMD confirm or refute the rumor in this press release? Is it perhaps only available on one of the two core types?

* through a data leak at Gigabyte

Is Intel planning to release future CPUs with AVX-512? Didn't they remove it from Adler Lake?

It's still there in the server chips, they just removed it from consumer parts.

It's actually there in Alder Lake's performance cores and can be used on at least some motherboards if the efficiency cores are disabled.

Disabling the E-cores apparently activates AVX-512. So it was planned and engineered to be there all along, but was disabled to match the marketing talking points. [https://www.phoronix.com/vr.php?view=30664]

I expect it was disabled so that the P&E cores have the same ISA support and threads can be moved freely between them. A large portion of people, especially at launch, would be running on a scheduler which isn't optimized for ADL which would be a disaster. Also complicated to market and explain: "supports AVX512 but only on windows 11." This way they don't have to characterize the AVX512 units and it makes binning easier.

A shame because the ADL AVX512 units are much more efficient.

> P&E cores have the same ISA support and threads can be moved freely between them.

Wouldn't an illegal instruction fault suffice to flag a thread running on a mismatched core and allow it to be moved to a suitable one? Or do they lose state when the fault occurs?

Maybe OSes could do that but they don't today.

At the moment they also don't differentiate between fast and slow cores either. It's interesting to route processes that need to be more responsive to the faster cores and dedicate the slower ones to more lag-tolerant things, a bit how mainframes route IO tasks to specialized processors or macOS routes system threads to the efficient cores, leaving the good ones to the user.

They would also need to know which specific instructions are really invalid and which just don’t exist on this specific core.

X86 doesn’t make that easy.

CPU flags should take care of that. Besides, you can examine where the program counter was when the core encountered the invalid instruction.

I wouldn't be surprised if the x86 would let us down here however. Wouldn't be the 8367th time.

There’s no CPU flag to say “this instruction exists on another core”. X86 disassemblers are very complex if you want to handle more than just the happy path. X86 instructions can be up to 15 bytes long.

Then there is the issue with new instructions that get added.

People are going to be running existing software (Windows 10 and Linux) which do not have support for Alder Lake. These schedulers don't know to handle the SIGILL. What you'd get instead is applications randomly crashing as their threads migrate to the E-cores. I'm sure they'll get there eventually, but they probably just didn't have enough time.

No existing scheduler does that, but it wouldn't be impossible to implement one that does.

But the OS should be able to handle it by masking out the feature bits in cpuid (and/or preventing threads using AVX512 from being migrated to the E cores).

Yes, you need OS support, but then again, you need support for the ThreadDirector anyway.

Wouldn't this break a lot of kernel-level code?

OTOH, this could allow us to have very heterogeneous processors in a single system, each with an ISA tailored to a kind of task and the OS knowing which core can run which program.

Despite years of talk about heterogeneous computing, I don't think there are any production kernels for any general-purpose operating system that are instruction-set-feature aware.

Linux and Windows both have partitioned schedulers, available through per-process and per-thread affinity masks. So it doesn't seem like it should be all that hard to implement. Its "just" a matter of expressing the process's (thread's?) requirements.

To clarify here, it requires both the E-cores disabled and a specific option enabled in the BIOS. The option was removed from the Intel firmware provided to vendors, but all the motherboard vendors found what bit to flip to get it to work. MSI played safe and initial BIOSes didn't have the option, the rest put it in there from launch. MSI are now releasing BIOSes with the AVX-512 option.

Beyond that, AVX-512 is not POR. It's not validated, checked for IEEE accuracy, and YMMV on whether it works at what frequency with the correct outputs.

Source: AnandTech.... where I wrote about it :)

> Source: AnandTech.... where I wrote about it :)

if you wrote it, it I wouldn't count it as a source /s

isn't that than a bit risky to put something into the bios which might disable intels advances? and especially if not even intel tested it correctly? I mean as a consumer what would happen if I enable it and something breaks?

I think they said it was gone so they could keep the software simpler i.e. switching a process from a big to little core could require a fair amount of logic if they have completely different instruction sets.

It's also possible it's buggy.

If they had completely different instruction sets, this wouldn't be feasible. The OS would need to be aware of that and move tasks between cores with a compatible ISA.

A possible workaround would be to use the invalid instruction fault to look for a core that implements that instruction.

That, however, wouldn't work if they were completely different, as in a couple GreenArray cores and a couple x86 ones.

>> Zen4 has been widely rumored* to support AVX-512.

I've been hoping AVX-512 goes away. Intel doesn't even seem to be embracing it very well, probably due to the huge increase in power consumption.

I look forward to RISC-V Vectors, which allow scaling the hardware without changing the instruction set.

The increased instruction set included in AVX-512 would hopefully stay though, even if the 512 wide processing unit goes away.

To keep the instructions also means keeping the extra wide registers. Not sure how big a deal that is. I suspect the wider vector registers aren't such a big deal but there are also twice as many of them. The old AMD strategy of running a 4-element vector through 2 units of half size (or sequentially through one unit of half size) could work but the increased register set is still a burden to some extent.

My understanding is that for general purpose registers, register renaming and other hazard-avoiding optimisations means that the register file is significantly larger than the total of (register width * number of registers).

Do the SIMD units have similar register duplications? If so, reducing the duplication count would do pretty much that (Reducing the area at the cost of lower performance).

Even if not, the large general purpose register duplication count likely means that the SIMD registers are actually a lower proportion of the register file on chip than the register width would imply, making it less of a saving.

But generally I agree, I'm much more interested in the extra instruction vocabulary and things like masking lanes than the increased register width. I also wonder at what point the cut off of when a use case would be worth pushing to a more dedicated accelerator (like a dsp or gpu).

> probably due to the huge increase in power consumption.

Alder Lake more or less fixed this according to Anandtech, with AVX512 using less than the rated turbo power of the CPU and running at the same frequency as non AVX code: https://www.anandtech.com/show/17047/the-intel-12th-gen-core...

Unfortunately, AVX-512 isnt officially supported on Alder Lake, so it might be another generation before its widely available.

This huge increase in power consumption was mainly with the earliest CPUs to feature it, unless I'm mistaken.

Does anybody know why AMD is picking Italian city names for the EPYC line?

They are beautiful places. Plus, great food.

I’d imagine you’d need an extended executive fact-finding trip to decide whether it’s a place you want to associate your company with.

I feel there is a niche for a startup in there somewhere. ;-)

Let's do it so that the executives don't have to.

Because they're giving Intel the boot.

I imagine it's about as exciting as most codenames: "we needed to decide some naming scheme, and someone suggested those place names because they like the places".

"What's red that we could name a CPU after?"

"Blood?"

"Too gross, and not enough variations."

"Rubies?"

"People would find a way to confuse the CPUs with the programming language, and besides, if Twitter digs up those tech demos of ours we're totally gonna get cancelled."

"Romans?"

"Sure, Romans are cool, and they conquer things, like we're going to conquer Intel. I like it."

"How about emperors?"

"Fine in principle, but they each did at least a few scandalous things... besides, we probably don't want the "history class" vibe, or the energy of the weird uncle who always wants to talk about Roman battle tactics at dinner."

"Yeah, fair enough. Cities, then? I visited Milan the other year..."

(30 minutes later)

"Cities it is!"

someone else already took most of the world's lakes.

AMD has been using place names for their CPUs for several years, particularly since the K8/Athlon 64 era. They just seem to be using Italian cities this time around.

https://en.wikipedia.org/wiki/Table_of_AMD_processors

Place names avoids trademark conflicts.

not necessarily:

https://www.champagne.fr/en/comite-champagne/bureaus/bureaus...

I'm not aware of any cases of code names that run afoul of trademarks, are you?

I for one can't take "EPYC Bergamo" seriously.

Come on, Bergamo? For real? I guess it could sound "cool" to non-Italian speakers, but here in Italy I think that Bergamo is one of the most forgettable cities ever. Which is sad, because its historical city centre is very beautiful, but the rest of the city is kind of dull and boring.

I wonder how many people in charge or purchasing actually consider the name, unconsciously or not. It could be called Thready McThreadface for all I care.

Outside of Italy, Bergamo is probably most famous for being the place you end up if you book a cheap flight to "Milano".

Of course, once this hits the market it won't actually be sold as the EPYC Bergamo, but rather the EPYC 9873 or whatever

> "Well", he said, "cities are OK, but not little cities that nobody's ever heard of. They ought to be WORLD CLASS cities!"

https://www.folklore.org/StoryView.py?story=World_Class_Citi...

All of Intel's codenames are real place names as well, and have been that way for a long time.

For example: https://en.wikipedia.org/wiki/Alder_Lake

Apple does the same thing with recent macOS releases, which are all places in California.

Same reason Intel did mountains and then lakes. They needed a theme that had enough names for it to last a good long while. Better choice than Apple's to go with big cats. They ran out too quickly.

My first custom PC back in 2004 was an Athlon 64 3000+ "Venice" 1.8GHz single core with 512kb L2 cache. The "San Diego" was better because it had 1MB cache. I managed to overclock it to 2.8GHz. What a time to be alive.

So it's something they've been doing to some extent for almost 20 years.

Have they said anything about new Threadrippers?

The Threadripper Pro is usually an EPYC with different warranty and a higher clock. Last time I think they were announced one day after their server counterparts.

Now, with Zen 4 and Zen 4c they'll have two different single-thread performance versions to play with.

No, the Zen 3 Threadripper was never announced. We’re now seeing announcements for the next Epyc generation with no TR Pro for the previous one.

The silicon is the same, sure. However the socket, motherboard, and related are sadly unique. Doubly confusing is there are single socket specific Epyc chips as well. Chips like the 7313p (zen3/milan for a single socket) fit the future TR product segment perfectly, but it's shipping today and fits Epyc boards instead of the rare/expensive TR pro motherboards.

Seems silly, does AMD really need two different/incompatible sockets for a 16-64 core CPU with 8 channels of DDR4-3200?

It just divides the market, decreases volume per product, and makes everything more expensive. The TR (and TR pro) motherboards and CPUs are low volume speciality items, priced a a premium, and seem to have no advantages over the epyc flavor.

Moore's Law is Dead (a very accurate leaker) said zen 3 threadripper was cancelled except maybe a limited launch of TR Pro, IIRC. Which makes sense since there are severe EPYC shortages and those are more important and profitable products. Intel doesn't have any workstation competition at the moment anyway.

i suspect supply chain issues are at the heart of no threadripper news.

This will put Zen 4c head to head with ARM Server. I am wondering if this is a request from Google and Microsoft Azure.

Hopefully we get much cheaper cloud computing because of it.

Finally every svchost.exe instance on Win 10 gets a core.

I bet it's a DRM-on-chip again. Better stock up on older blade racks.

Reply on news.ycombinator.com