Live data from Hacker News

Intel's make-or-break 18A process node debuts for data center with 288-core Xeon

tomshardware.com

21–30 of 303 posts

Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon

#21

I’ve not kept up with Intel in a while, but one thing that stood out to me is these are all E cores— meaning no hyperthreading. Is something like this competitive, or preferred, in certain applications? Also does anyone know if there have been any benchmarks against AMDs 192 core Epyc CPU?

"Is something like this competitive, or preferred, in certain applications?"

They cite a very specific use case in the linked story: Virtualized RAN. This is using COTS hardware and software for the control plane for a 5G+ cell network operation. A large number of fast, low power cores would indeed suit such a application, where large numbers of network nodes are coordinated in near real time.

It's entirely possible that this is the key use case for this device: 5G networks are huge money makers and integrators will pay full retail for bulk quantities of such devices fresh out of the foundry.

Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon

#25

One day I hope to be rich enough to put a CPU like this (with proportional RAM and storage) in my proxmox cluster.

Wait long enough and these will be cheap on eBay.

By that point we'll be desiring the new 1000 core count CPUs though.

Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon

#27
With packages like this (lots of cores, multi-chip packaging, lots of memory channels), the architecture is increasingly a small cluster on a package rather than a monolithic CPU.

I wonder whether the next bottleneck becomes software scheduling rather than silicon - OS/runtimes weren’t really designed with hundreds of cores and complex interconnect topologies in mind.

Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon

#30

Earlier quoted context omitted.

That’s definitely the right call in some cases. But as soon as there’s any high-interconnect-rate system that has to be in cloud (appliances with locked in cloud billing contracts, compute that does need to elastically scale and talks to your DB’s pizza box, edge/CDN/cache services with lots of fallthrough to sources of truth on-prem), the cloud bandwidth costs start to kill you. I’ve had success with this approach b…

Yep, 100%, but that's why identifying compatible workloads first is key. A lot of orgs skip right to the savings pitch, ignorant of how their applications communicate with one another - and you hit the nail on the head that applications doing even some processing in a cloud provider will murder you on egress fees by trying to hybrid your app across them. Folks wanting one or the other miss savings had by effectively…

Any experience with the mid-to-small cloud providers that provide un-metered network ports and/or free interconnect with partner providers?

(For various reasons, I just care about VPS/bare metal, and S3-compatiblity.)

I'm looking at those because I'm having difficulty forecasting bandwidth usage, and the pessimistic scenarios seem to have me inside the acceptable use policies of the small providers while still predicting AWS would cost 5-10x more for the same workload.

Post reply on HN