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

211–220 of 303 posts

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

#211

Post by tempaccount5050 »

danielheath wrote: post #209
esseph wrote: post #179

Earlier quoted context omitted.

> Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem. Like what?

The biggest one for me is the way AWS security groups & IAM work. In AWS, it's straightforward to say e.g. "permit traffic on port X from instances holding IAM role Y". You can easily e.g. get the firewall rules for all your ec2 instances in a structured format. I really would not look forward to building something even 1/10th as functional as that.

And you think just anyone can set that up? No sys admin/infra guy needed? Seems pretty risky.

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

#212

Post by adrian_b »

jfindley wrote: post #70
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…

Do note though that AIUI these are all E-cores, have poor single-threaded performance and won't support things like AVX512. That is going to skew your performance testing a lot. Some workloads will be fine, but for many users that are actually USING the hardware they buy this is likely to be a problem. If that's you then the GraniteRapids AP platform that launched previously to this can hit similar numbers of threads…

These Intel Darkmont cores are in a different performance class than the (Crestmont) E-cores used in the previous generation of Sierra Forest Xeon CPUs. For certain workloads they may have even a close to double performance per core.

Darkmont is a slightly improved variant of the Skymont cores used in Arrow Lake/Lunar Lake and it has a performance very similar to the Arm Neoverse V3 cores used in Graviton5, the latest generation of custom AWS CPUs.

However, a Clearwater Forest Xeon CPU has much more cores per socket than Graviton5 and it also supports dual-socket motherboards.

Darkmont also has a greater performance than the older big Intel cores, like all Skylake derivatives, inclusive for AVX-using programs, so it is no longer comparable with the Atom series of cores from which it has evolved.

Darkmont is not competitive in absolute performance with AMD Zen 5, but for the programs that do not use AVX-512 it has better performance per watt.

However, since AMD has started to offer AVX-512 for the masses, the number of programs that have been updated to be able to benefit from AVX-512 is increasing steadily, and among them are also applications where it was not obvious that using array operations may enhance performance.

Because of this pressure from AMD, it seems that this Clearwater Forest Xeon is the final product from Intel that does not support AVX-512. Both next 2 Intel CPUs support AVX-512, i.e. the Diamond Rapids Xeon, which might be launched before the end of the year, and the desktop and laptop CPU Nova Lake, whose launch has been delayed to next year (together with the desktop Zen 6, presumably due to the shortage of memories and production allocations at TSMC).

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

#213

Post by _2d30 »

zadikian wrote: post #205
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.

Wait, does a single CPU chip have numa within it now, or are you only talking about multi-socket machines?

Single chips do.

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

#214

Post by skissane »

everforward wrote: post #156
throwup238 wrote: post #75

Earlier quoted context omitted.

> even the internal talent to know whether they are hiring a good infrastructure engineer or not during the interview process. This is really the core problem. Every time I’ve done the math on a sizable cloud vs on-prem deployment, there is so much money left on the table that the orgs can afford to pay FAANG-level salaries for several good SREs but never have we been able to find people to fill the roles or even kno…

I work in SRE and the way you describe it would give me pause. The first is that SRE team size primarily scales with the number of applications and level of support. It does scale with hardware but sublinearly, where number of applications usually scales super linearly. It takes a ton less effort to manage 100 instances of a single app than 1 instance of 100 separate apps (presuming SRE has any support responsibiliti…

> The first is that SRE team size primarily scales with the number of applications and level of support. It does scale with hardware but sublinearly, where number of applications usually scales super linearly. It takes a ton less effort to manage 100 instances of a single app than 1 instance of 100 separate apps (presuming SRE has any support responsibilities for the app). Talking purely in terms of hardware would make me concerned that I’m looking at an impossible task.

Never been an SRE but interact with them all the time…

My own personal experience is there is commonly a division between App SREs that look after the app layer and Infra SREs that looks after the infrastructure layer (K8S, storage, network, etc)

The App SRE role absolutely scales with the number of distinct apps. The extent to which the Infra SRE role does depends on how diverse the apps are in terms of their infrastructure demands

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

#215

Post by lazylizard »

stego-tech wrote: post #190
Aurornis wrote: post #114

Earlier quoted context omitted.

$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…

Out of all the comments on numbers, SREs, and scaling, you get the response for meeting numbers with numbers! > $120K isn't going to cover the fully loaded costs of an SRE who can set up and run that. Literally this. I can do SRE on-prem and cloud, and my 50/30/20 budget break-even point (as in, needs and savings but no wants - so 70%) is $170k before taxes . Rent is astonishingly high right now, and the sort of mid-…

i am not sre, merely sysadmin.

and somehow i have this impression that gpus on slurm/pbs could not be simpler.

u can use a vm for the head node, dont even need the clustering really..if u can accept taking 20min to restore a vm.. and the rest of the hardware are homogeneous - you setup 1 right and the rest are identical.

and its a cluster with a job queue.. 1 node going down is not the end of the world..

ok if u have pcie GPUs sometimes u have to re-seat them and its a pain. otherwise if ur h200 or disks fail u just replace them, under warranty or not...

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

#216

Post by SamuelAdams »

esseph wrote: post #179
danielheath wrote: post #158

Earlier quoted context omitted.

I'm one of those people, and I don't agree. Before I drop 5 figures on a single server, I'd like to have some confidence in the performance numbers I'm likely to see. I'd expect folk who are experienced with on-prem have a good intuition about this - after a decade of cloud-only work, I don't. Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem. I've estimated…

> Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem. Like what?

IAM comes to mind, with fine grained control over everything.

S3 has excellent legal and auditory settings for data, as well as automatic data retention policies.

KMS is a very secure and well done service. I dare you to find an equivalent on-prem solution that offers as much security.

And then there's the whole DR idea. Failing over to another AWS region is largely trivial if you set it up correctly - on prem is typically custom to each organization, so you need to train new staff with your organizations workflows. Whereas in AWS, Route53 fail-over routing (for example) is the same across every organization. This reduces cost in training and hiring.

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

#217

Post by Dunedan »

andreadev wrote: post #157

I think everyone's focusing on the core count, but the packaging story is way more interesting here. This thing is 12 separate chiplets on 18A stacked on base dies made on Intel 3, connected to I/O tiles on Intel 7. Three different process nodes in one package, shipping at volume. That's nuts. And it's clearly an IFS play too. Intel Foundry needs a proof point — you can publish PDKs all day, but nothing sells foundry…

> 18A is brand new, yields are probably rough.

That the CPU cores are low frequency cores probably helps with yield as well.

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

#218

Post by vel0city »

PunchyHamster wrote: post #173
LunaSea wrote: post #91

Earlier quoted context omitted.

> 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.

> 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. we have 7 racks and 3 people. The things you mentioned aren't even 5% of the workload. There are things you figure out once, bake into automation, and just use. You install server once and remove it after 5-10 years, depending on how you want to deprecia…

> Biggest disadvantage is "we need a bunch of compute, now"

And depending on the problem set in question, one can also potentially leverage "the cloud" for the big bursty compute needs and have the cheap colo for the day to day stuff.

For instance, in a past life the team I worked on needed to run some big ML jobs while having most things on extremely cheap colo infra. Extract the datasets, upload the extracted and well-formatted data to $cloud_provider, have VPN connectivity for the small amount of other database traffic, and we can burst to have whatever compute needed to get the computations done really quick. Copy the results artifact back down, deploy to cheap boxes back at the datacenter to host for clients stupid-cheap.

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

#220

Post by throwup238 »

stego-tech wrote: post #190
Aurornis wrote: post #114

Earlier quoted context omitted.

$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…

Out of all the comments on numbers, SREs, and scaling, you get the response for meeting numbers with numbers! > $120K isn't going to cover the fully loaded costs of an SRE who can set up and run that. Literally this. I can do SRE on-prem and cloud, and my 50/30/20 budget break-even point (as in, needs and savings but no wants - so 70%) is $170k before taxes . Rent is astonishingly high right now, and the sort of mid-…

> Out of all the comments on numbers, SREs, and scaling, you get the response for meeting numbers with numbers!

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

> Literally this. I can do SRE on-prem and cloud, and my 50/30/20 budget break-even point (as in, needs and savings but no wants - so 70%) is $170k before taxes. Rent is astonishingly high right now, and the sort of mid-career professional you want to handle SRE for your single DC is going to take $150k in this market before fucking off to the first $200k job they get.

That's $120k per pod. Four pods per rack at 50kW.

What universe are we living in that a single SRE can't manage even a single rack for less than half a million in total comp?

Post reply on HN