Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD EPYC “Rome” Server Processors to Feature 8 to 64 Cores

techquila.co.in

Post reply on HN
Print view View original

61–70 of 115 posts

Re: AMD EPYC “Rome” Server Processors to Feature 8 to 64 Cores

#61

Post by floatboth »

astrodust wrote: post #50
33degrees wrote: post #22

Earlier quoted context omitted.

At this point, I think it's a lot more likely for Apple to switch to using their own chips, at least at the low end.

Given the JavaScript performance of the shipping units intended for mobile use, which is eclipsing the best of Intel's offerings, it might be possible that the A14 or A15 iteration actually surpasses Intel's chips at x86-64 code as well when run through a Rosetta-like compatibility layer. What if the high-end chip was ARM? It's not just about raw speed, it's about how much performance you can squeeze out of a particu…

What would be awesome if instead of a Rosetta-like (or qemu-user-like) compatibility layer, the chip supported multiple ISAs natively.

The only company that has the rights to do both ARMv8 and amd64 is.. AMD :)

Re: AMD EPYC “Rome” Server Processors to Feature 8 to 64 Cores

#62

Post by rbanffy »

astrodust wrote: post #53
dpedu wrote: post #9

Earlier quoted context omitted.

It's probably not just the chip, Intel provides financial incentives for manufacturers who build products around their chips.

That usually involves advertising, but Apple has turned down those offers. Not even an "Intel inside" sticker. Apple's relationship with Intel is pretty rocky now. Intel fumbled the i9, their Xeon chips aren't keeping up with AMD's workstation offerings, and their efforts to build a cellular modem chip utterly failed, leaving Apple at the mercy of Qualcomm for that part. I'm sure Apple will cut loose on Intel as soon…

The financial incentives can cover other chip lines. Apple sells a ton of laptop CPUs and has some preferred partner status with Intel.

Re: AMD EPYC “Rome” Server Processors to Feature 8 to 64 Cores

#63

Post by jtl999 »

astrodust wrote: post #51
Rebelgecko wrote: post #47

Earlier quoted context omitted.

I think they're pointing out that many of the bottlenecks that make computers feel slow can't be fixed by throwing more cores at them—multithreading can be tricky

You could have 128 cores, 4TB of memory, multiple top-end NVMe drives and Windows will still lock up when accessing an offline network share. Good job Microsoft.

I had that issue with OS X 10.11 and disconnecting my Thunderbolt NIC without umounting cleanly.

Argh

Re: AMD EPYC “Rome” Server Processors to Feature 8 to 64 Cores

#64

Post by juergbi »

leeter wrote: post #58

So at a 225w TDP I'd guess that part is going to be clocked in the 1.2 -1.5GHz range. Definitely a specialist part IMO because with only 8 channels of memory that's 1 channel per eight cores which is not a ton of bandwidth. So for workloads that largely stay in the (I assume) ample L3/L2 caches that part will rock. But for anything that needs a lot of bandwidth spread across cores (databases come to mind) it will pro…

It seems like the 64 core part will be able to run at 2.35 GHz, see https://www.anandtech.com/show/13598/amd-64-core-rome-deploy...

Re: AMD EPYC “Rome” Server Processors to Feature 8 to 64 Cores

#65

Post by ip26 »

paulmd wrote: post #56
ip26 wrote: post #55

Earlier quoted context omitted.

They exhibit NUMA because if chiplet0 wants a line of memory that is held by chiplet4, it has to go get it from chiplet4. So the degree of NUMA is improved from the previous generation, but it is still not UMA.

No memory is held by any chiplet, it's all held by the IO die and chiplets ask the IO die to access memory for it. So there is no longer "near" and "far". In a sense, it's all "far" now (but hopefully not too far). But it is all uniform now.

The chiplets have cache, which holds copies of memory. If a process has the line open in an exclusive state, e.g. locked, other chiplets cannot just get the line from memory, because it might be out of date. So they must go ask whoever holds the lock to flush & release.

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

Re: AMD EPYC “Rome” Server Processors to Feature 8 to 64 Cores

#66

Post by juergbi »

kllrnohj wrote: post #26
rubyn00bie wrote: post #5

The real question for me with all these AMD releases, what's Intel gonna release? It's surprising to me that Apple didn't announce an AMD based Mac Pro-- the chip Intel gave them must really be something. Too bad though because there could be a lot more of them (eventual Mac Pros) out there I'm guessing if they were using these Rome chips.

I think it'd really only be surprising if the Mac Pro ignored these chips when they were already available. At this point, though, the Mac Pro is shipping before Rome is available. The timing is just off. Current Xeons are faster than current Epyc's on average, so the choice today makes sense. Particularly if Apple wants to avoid NUMA in these machines. It wouldn't be unreasonable for a Mac Pro refresh in 2 years to…

No, Rome is expected to officially launch in early Q3 (it's already shipping to hyperscalers) and the Mac Pro is expected to ship in September.

However, Zen 2 Threadripper would likely be a better fit for a workstation such as Mac Pro as it will (most likely) have higher clock speeds. The current Threadripper lineup doesn't support more than 256 GB RAM, though. I don't know whether the new Threadripper will support RDIMM/LRDIMM to compete with Xeon-W on memory capacity.

Re: AMD EPYC “Rome” Server Processors to Feature 8 to 64 Cores

#67

Post by juergbi »

rbanffy wrote: post #60
kllrnohj wrote: post #26

Earlier quoted context omitted.

I think it'd really only be surprising if the Mac Pro ignored these chips when they were already available. At this point, though, the Mac Pro is shipping before Rome is available. The timing is just off. Current Xeons are faster than current Epyc's on average, so the choice today makes sense. Particularly if Apple wants to avoid NUMA in these machines. It wouldn't be unreasonable for a Mac Pro refresh in 2 years to…

The Mac Pro uses the LGA3647 socket, which I assume will give it some headroom for incremental upgrades in the next few years before a major overhaul is due. Intel already offers 112-thread part for that socket.

No, the 56C/112T Intel Xeon Platinum 9282 is a BGA part, it's not socketed. You can buy this niche product only as part of a server with liquid cooling.

And the successors to Cascade Lake seem to switch to the LGA4189 socket to support 8 memory channels (Cooper Lake and Ice Lake), so I wouldn't expect any upgrades on LGA3647.

Re: AMD EPYC “Rome” Server Processors to Feature 8 to 64 Cores

#68

Post by leeter »

juergbi wrote: post #64
leeter wrote: post #58

So at a 225w TDP I'd guess that part is going to be clocked in the 1.2 -1.5GHz range. Definitely a specialist part IMO because with only 8 channels of memory that's 1 channel per eight cores which is not a ton of bandwidth. So for workloads that largely stay in the (I assume) ample L3/L2 caches that part will rock. But for anything that needs a lot of bandwidth spread across cores (databases come to mind) it will pro…

It seems like the 64 core part will be able to run at 2.35 GHz, see https://www.anandtech.com/show/13598/amd-64-core-rome-deploy...

Good to know I was assuming they'd run a bit hotter. That will actually make the memory situation worse though in many regards.

Re: AMD EPYC “Rome” Server Processors to Feature 8 to 64 Cores

#70

Post by wmf »

ip26 wrote: post #65
paulmd wrote: post #56

Earlier quoted context omitted.

No memory is held by any chiplet, it's all held by the IO die and chiplets ask the IO die to access memory for it. So there is no longer "near" and "far". In a sense, it's all "far" now (but hopefully not too far). But it is all uniform now.

The chiplets have cache, which holds copies of memory. If a process has the line open in an exclusive state, e.g. locked, other chiplets cannot just get the line from memory, because it might be out of date. So they must go ask whoever holds the lock to flush & release. https://en.wikipedia.org/wiki/MESIF_protocol

When you're talking about cache it's NUCA, not NUMA.
Post reply on HN