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

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

tomshardware.com

Post reply on HN
Print view View original

131–140 of 303 posts

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

#131

Post by Figs »

Aurornis wrote: post #114
tgrowazay wrote: post #107

Earlier quoted context omitted.

Self-hosted 8xH100 is ~$250k, depreciated across three years => $80k/year, with power and cooling => $90k/year (~$10/hour total). AWS charges $55/hour for EC2 p5.48xlarge instance, which goes down with 1 or 3 year commitments. With 1 year commitment, it costs ~$30/hour => $262k per year. 3-year commitment brings price down to $24/hour => $210k per year. This price does NOT include egress, and other fees. So, yeah, th…

$120K isn't going to cover the fully loaded costs of an SRE who can set up and run that. Hiring 1 person to run the infrastructure means that 1 person is on-call 24/7 forever. If there's an issue with the server while they're sick or on vacation, you just stop and wait. If they take a new job, you need to find someone to take over or very quickly hire a replacement. There's a second bus factor: What happens when that…

> $120K isn't going to cover the fully loaded costs of an SRE who can set up and run that.

> Hiring 1 person to run the infrastructure means that 1 person is on-call 24/7 forever.

> If there's an issue with the server while they're sick or on vacation, you just stop and wait.

Very much depends on what you're doing, of course, but "you just stop and wait" for sickness/vacation sometimes is actually good enough uptime -- especially if it keeps costs down. I've had that role before... That said, it's usually better to have two or three people who know the systems though (even if they're not full time dedicated to them) to reduce the bus factor.

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

#132

Post by user5994461 »

01HNNWZ0MV43FF wrote: post #110
user5994461 wrote: post #83

Earlier quoted context omitted.

> I wonder whether the next bottleneck becomes software scheduling rather than silicon Yep, the scheduling has been a problem for a while. There was an amazing article few years ago about how the Linux kernel was accidentally hardcoded to 8 cores, you can probably google and find it. IMO the most interesting problem right now is the cache, you get a cache miss every time a task is moving core. Problem, with thousands…

I searched for "Linux kernel limited to 8 cores" and found this https://news.ycombinator.com/item?id=38260935 > This article is clickbait and in no way has the kernel been hardcoded to a maximum of 8 cores.

That's the one. Funny thing, it's not actually clickbait.

The bug made it to the kernel mailing list where some Intel people looked into it and confirmed there is a bug. There is a problem where is the kernel allocation logic was capped to 8 cores, which leaves a few percent of performance off the table as the number of cores increase and the allocation is less and less optimal.

It's classic tragedy of the commons. CPU have got so complicated, there may only be a handful of people in the world who could work and comprehend a bug like this.

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

#133

Post by moffkalast »

rubyn00bie wrote: post #6

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?

I guess it competes with the like of Ampere's ARM servers? I'm sure there are use cases for lots and lots of weak cores, in telecom especially.

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

#134

Post by umvi »

stego-tech wrote: post #8

These sorts of core-density increases are how I win cloud debates in an org. * Identify the workloads that haven't scaled in a year. Your ERPs, your HRIS, your dev/stage/test environments, DBs, Microsoft estate, core infrastructure, etc. (EDIT, from zbentley: also identify any cross-system processing where data will transfer from the cloud back to your private estate to be excluded, so you don't get murdered with egr…

Is using virtualization the only good way of taking a 288-core box and splitting it up into multiple parallel workloads? One time I rented a 384-core AMD EPYC baremetal VM in GCP and I could not for the life of me get parallelized workloads to scale just using baremetal linux. I wanted to run a bunch of CPU inference jobs in parallel (with each one getting 16 cores), but the scaling was atrocious - the more parallel jobs you tried to add, the slower all of them ran. When I checked htop the CPU was very underutilized, so my theory was that there was a memory bottleneck somewhere happening with ONNX/torch (something to do with NUMA nodes?) Anyway, I wasn't able to test using proxmox or vmware on there to split up cpu/memory resources; we decided instead to just buy a bunch of smaller-core-count AMD Ryzen 1Us instead, which scaled way better with my naive approach.

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

#135

Post by jeffbee »

rishabhaiover wrote: post #117
jeffbee wrote: post #60

Earlier quoted context omitted.

There definitely are bottlenecks. The one I always think of is the kernel's networking stack. There's no sense in using the kernel TCP stack when you have hundreds of independent workloads. That doesn't make any more sense than it would have made 20 years ago to have an external TCP appliance at the top of your rack. Userspace protocol stacks win.

io_uring?

If anything, uring makes the problem much worse by reducing the cost of one process flooding kernel internals in a single syscall.

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

#136

Post by [deleted] »

matja wrote: post #102
user5994461 wrote: post #50

Earlier quoted context omitted.

> These sorts of core-density increases are how I win cloud debates in an org. The core density is bullshit when each core is so slow that it can't do any meaningful work. The reality is that Intel is 3 times behind AMD/TSMC on performance vs power consumption ratio. People would be better off having a look at the high frequency models (9xx5F models like the 9575F), that was the first generation of CPU server to reac…

Intel seem to be deliberately hiding the clock frequency of this thing, the xeon-6-plus-product-deck.pdf has no mention of clock frequency or how LLC is shared.

[deleted]

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

#137

Post by Figs »

citrin_ru wrote: post #128
carefree-bob wrote: post #58

Earlier quoted context omitted.

The main cost with on-prem is not the price of the gear but the price of acquiring talent to manage the gear. Most companies simply don't have the skillset internally to properly manage these servers, or even the internal talent to know whether they are hiring a good infrastructure engineer or not during the interview process. For those that do, your scaling example works against you. If today you can merge three ser…

> price of acquiring talent to manage the gear Is it still a problem in 2026 when unemployment in IT is rising? Reasons can be argued (the end of ZIRP or AI) but hiring should be easier than it was at any time during the last 10 years.

Hiring people is still fucked in 2026 in my experience. HR processes are extremely dysfunctional at many organizations...

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

#138

Post by wmf »

brcmthrowaway wrote: post #101
Agingcoder wrote: post #96

Earlier quoted context omitted.

Yes there are scheduling issues, Numa problems , etc caused by the cluster in a box form factor. We had a massive performance issue a few years ago that we fixed by mapping our processes to the numa zones topology . The default design of our software would otherwise effectively route all memory accesses to the same numa zone and performance went down the drain.

Intel contributes to Linux, how is this a problem?

Often the Linux scheduling improvements come a year or two after the chip. Also, Linux makes moment-by-moment scheduling and allocation decisions that are unaware of the big picture of workload requirements.

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

#140

Post by ocdtrekkie »

LunaSea wrote: post #91
ozgrakkurt wrote: post #85

Earlier quoted context omitted.

This factually did not play out like this in my experience. The company did need the same exact people to manage AWS anyway. And the cost difference was so high that it was possible to hire 5 more people which wasn't needed anyway. Not only the cost but not needing to worry about going over the bandwidth limit and having soo much extra compute power made a very big difference. Imo the cloud stuff is just too full of…

> The company did need the same exact people to manage AWS anyway. That is incorrect. On AWS you need a couple DevOps that will Tring together the already existing services. With on premise, you need someone that will install racks, change disks, setup high availability block storage or object storage, etc. Those are not DevOps people.

People will install racks and swap drives for significantly less money than DevOps, lol. People who can build LEGO sets are cheaper than software developers.
Post reply on HN