Intel's 14th Gen Core K-Series CPU Specs Break Cover with Speeds Up to 6GHz(hothardware.com)
hothardware.com
Intel's 14th Gen Core K-Series CPU Specs Break Cover with Speeds Up to 6GHz
https://hothardware.com/news/intel-14thgen-core-k-cpu-spec-leak
43 comments
I am glad to see Intel still pushing faster single-threaded performance. Many (most?) important workloads are not meaningfully improved by adding cores.
> not meaningfully improved by adding cores.
This is true and I hate it, because it doesn't have to be this way. Almost all existing workloads are theoretically parallelizable to at least some significant degree, developers just don't do it because it's so difficult. (I'm talking about large scale systems, not individual algorithms)
I think more research needs to go into designing new programming languages and paradigms to make multithreading easy and automatic. There's been some improvement here in the last few years, e.g. coroutines, move semantics, but there's still a long way to go. It's silly that people are buying 32-core CPUs that basically only get used for video rendering.
This is true and I hate it, because it doesn't have to be this way. Almost all existing workloads are theoretically parallelizable to at least some significant degree, developers just don't do it because it's so difficult. (I'm talking about large scale systems, not individual algorithms)
I think more research needs to go into designing new programming languages and paradigms to make multithreading easy and automatic. There's been some improvement here in the last few years, e.g. coroutines, move semantics, but there's still a long way to go. It's silly that people are buying 32-core CPUs that basically only get used for video rendering.
> (...) developers just don't do it because it's so difficult.
I don't think this is true, or at least generalizable.
I've been involved in a few tickets to turn problematic sync calls to async calls or background tasks. In all of them, the root cause was the same:
* Let's add a handler that does nothing of note, such as setting a flag or logging something or emitting a metric.
* We have another feature, and it requires something being triggered by the handler. Let's add it next to the logger/metric call. Let's also clean this up and extract a function out of this code.
* We need to tweak that feature to do one more thing. Calling that function from the handler under rare cases can add a bit of lag and block stuff. We can live with it, so let's keep it like that.
* Oh it turns out that member function can render the app unusable. We can't live with it anymore, and we need to refactor it.
I don't think this is true, or at least generalizable.
I've been involved in a few tickets to turn problematic sync calls to async calls or background tasks. In all of them, the root cause was the same:
* Let's add a handler that does nothing of note, such as setting a flag or logging something or emitting a metric.
* We have another feature, and it requires something being triggered by the handler. Let's add it next to the logger/metric call. Let's also clean this up and extract a function out of this code.
* We need to tweak that feature to do one more thing. Calling that function from the handler under rare cases can add a bit of lag and block stuff. We can live with it, so let's keep it like that.
* Oh it turns out that member function can render the app unusable. We can't live with it anymore, and we need to refactor it.
I was gonna say, the issue is definitely that conscious thought and planning has to be put into it, and even then issues still crop up.
We really need a new language that self-parallelises with zero effort from developers.
We really need a new language that self-parallelises with zero effort from developers.
How we program multicores - Joe Armstrong
https://www.youtube.com/watch?v=bo5WL5IQAd0
https://www.youtube.com/watch?v=bo5WL5IQAd0
>I think more research needs to go into designing new programming languages
It was my understanding that golang supports multi-core?
[0] https://pkg.go.dev/github.com/jeffdecola/my-go-examples/goro...
It was my understanding that golang supports multi-core?
[0] https://pkg.go.dev/github.com/jeffdecola/my-go-examples/goro...
I have probably too many cores on my music production Mac, and I definitely would rather have faster single-threaded performance, even if it meant half the cores I currently have available.
I mean, I'm pretty happy with it. But the workload is only marginally faster/smoother than it would be with half the cores, and still sometimes feels sluggish. Law of diminishing returns, for sure. It never hangs on a hard load though, but I feel that would be the same with fewer but faster cores anyway.
I mean, I'm pretty happy with it. But the workload is only marginally faster/smoother than it would be with half the cores, and still sometimes feels sluggish. Law of diminishing returns, for sure. It never hangs on a hard load though, but I feel that would be the same with fewer but faster cores anyway.
Music production seems like a great "embarassingly parallel" application since instrument voices tend to be independent and effects chains are readily pipelined. Multicore should provide direct benefit in terms of more tracks, more instrument voices, and deeper effects chains.
What is the single-threaded workload that is sluggish? Is it something like encoding or compression?
What is the single-threaded workload that is sluggish? Is it something like encoding or compression?
[deleted]
>Many (most?) important workloads are not meaningfully improved by adding cores.
Absolutely. No browser can use more than a single core. And in any case, who in their right mind uses more than a single thread at a given time anyway? I certainly never open more than a single appliation at a time.
In all honesty, this is one of the more delusional comments I have seen on here...
Absolutely. No browser can use more than a single core. And in any case, who in their right mind uses more than a single thread at a given time anyway? I certainly never open more than a single appliation at a time.
In all honesty, this is one of the more delusional comments I have seen on here...
And this is one of the least charitable readings of a comment I have seen before.
Is it? Literally every single workload is improved by adding more cores. Even single threaded applications benefit, as they can have more time on their core, without having loosing their cache.
I just got a 13900K on Monday. Naturally something bigger and badder is right around the corner. I cry evrytim.
Haha yes that’s me every time I upgrade, every new thing you buy is bound to be outshined by the next iteration. The best cpu you can buy is always the next gen going to come soon I guess.
That's why I always buy old shit for a fraction of the price. Always a step behind but it's a constant step.
It’s a great time to buy a CPU.
Lots of competition and lots of innovation.
Lots of competition and lots of innovation.
No. A great time to buy a CPU was a few decades ago, when each new CPU made your computer go 10x faster. Moore's Law was a fun ride.
My desktop’s got the clocks, it rocks! But it was obsolete before I opened the box.
Your laptop’s a month old? That’s great… for a nice, heavy paperweight!
It’s all about the Pentiums, baby.
Your laptop’s a month old? That’s great… for a nice, heavy paperweight!
It’s all about the Pentiums, baby.
>. A great time to buy a CPU was a few decades ago, when each new CPU made your computer go 10x faster. Moore's Law was a fun ride.
Which makes it the worst possible time to buy a CPU as the value is low (economies of scale, market saturation) and declines fast (new models).
Which makes it the worst possible time to buy a CPU as the value is low (economies of scale, market saturation) and declines fast (new models).
Moores law is still going.
And I find multi core CPUs just as cool as the olden days.
And I find multi core CPUs just as cool as the olden days.
It's not though... it has been dead for over a decade. It was about price for silicon density. Prices have gone up significantly for the newer nodes without the density increase necessary to offset.
$250 today buys you a Intel 13600, a 14 core chip.
$250 ten years ago bought you a Intel 4670K, a 4 core chip (with significantly slower cores, less cache, etc). A 14 core processor was available only as a server CPU and cost $3000.
I'm not sure that is evidence of price going up faster than density over the last 10 years.
$250 ten years ago bought you a Intel 4670K, a 4 core chip (with significantly slower cores, less cache, etc). A 14 core processor was available only as a server CPU and cost $3000.
I'm not sure that is evidence of price going up faster than density over the last 10 years.
I'll clarify Tostino's comment. For most of Moore's Law, price per mm of silicon was constant. A state-of-the-art 10 micron, 5 micron, 2 micron, 1 micron, and 500nm node, at introduction, was basically the same price per square millimetre.
This meant you had exponentially-growing numbers of transistors for the same price.
Density is going up now, but so is price. A billion transistors a 4nm will cost less than a billion at 40nm, but it's a different ride since you don't ave a 100x reduction in cost. There is a reduction, but it's not the same wild ride.
At the same time, NREs are exploding.
This meant you had exponentially-growing numbers of transistors for the same price.
Density is going up now, but so is price. A billion transistors a 4nm will cost less than a billion at 40nm, but it's a different ride since you don't ave a 100x reduction in cost. There is a reduction, but it's not the same wild ride.
At the same time, NREs are exploding.
If you look at this another way, each new CPU made your computer 10x slower, relatively speaking.
Or terrible time, because whatever you're getting might become obsolete in just a few years
that chip has been out for about 6 months and intel release a new generation every 9 months or so
it's not exactly unexpected
it's not exactly unexpected
Do you actually need the extra performance?
Not that having a ton of E-cores isn't cool but is there the memory bandwidth to keep all of the P- and E-cores fed and if there isn't, then what's the point? There are probably two memory channels like all of Intel's past consumer products and, IIRC, DDR5 crams two channels of half width into each physical channel but I haven't seen an explanation of whether that's really the equivalent of 4 DDR4 memory channels.
> Not that having a ton of E-cores isn't cool
Personally, I don’t find that cool, and I think I will stay with AMD CPU for my next desktop. I want all cores to be fast, and I have enough parallelizable work for them. Also I’d like to get AVX-512: Intel doesn’t support that in their reasonably-priced consumer targeted CPUs.
> I haven't seen an explanation of whether that's really the equivalent of 4 DDR4 memory channels.
For throughput, it could be the case. DDR4-3200 has theoretical peak 25 GB/sec/channel, for DDR5-8000 62.5 GB/sec/channel.
Personally, I don’t find that cool, and I think I will stay with AMD CPU for my next desktop. I want all cores to be fast, and I have enough parallelizable work for them. Also I’d like to get AVX-512: Intel doesn’t support that in their reasonably-priced consumer targeted CPUs.
> I haven't seen an explanation of whether that's really the equivalent of 4 DDR4 memory channels.
For throughput, it could be the case. DDR4-3200 has theoretical peak 25 GB/sec/channel, for DDR5-8000 62.5 GB/sec/channel.
> I want all cores to be fast
E-cores aren't slow just because they're not called "performance" cores, they're just more efficient at lower clock speeds and more in numbers, optimized specifically for multi-threaded tasks you said you need.
P-cores are great mostly for single thread tasks that bank on high clock speeds, that's why the CPU has so few of them, as it seeks to cram in as many E-cores as possible.
AMD is also going the big.LITTLE route with the next Ryzen generation.
E-cores aren't slow just because they're not called "performance" cores, they're just more efficient at lower clock speeds and more in numbers, optimized specifically for multi-threaded tasks you said you need.
P-cores are great mostly for single thread tasks that bank on high clock speeds, that's why the CPU has so few of them, as it seeks to cram in as many E-cores as possible.
AMD is also going the big.LITTLE route with the next Ryzen generation.
I don’t think any of these efficiency claims are true. https://www.uops.info/ has data for Alder Lake from 2021. For example, some performance-critical code I have bottlenecks on FMA instructions like vfmadd132pd.
Fast cores: 4 cycles latency, 0.5 cycles throughput, 1 μop
Slow cores: 6-10 cycles latency, 1 cycle throughput, 2 μops.
Roughly speaking, these numbers mean their fast cores are about 2 times faster for single-threaded arithmetic-heavy code.
The numbers for some other arithmetic instructions are even worse for their slow cores. For FP division or square root instructions the gap widens to 4x and 5x the throughput, respectively.
As for the AMD, I hope they will do what they recently did in their Zen4c microarchitecture in the newly launched server chips: reduce clocks speeds, reduce L3 cache, but don’t cripple the actual cores.
Fast cores: 4 cycles latency, 0.5 cycles throughput, 1 μop
Slow cores: 6-10 cycles latency, 1 cycle throughput, 2 μops.
Roughly speaking, these numbers mean their fast cores are about 2 times faster for single-threaded arithmetic-heavy code.
The numbers for some other arithmetic instructions are even worse for their slow cores. For FP division or square root instructions the gap widens to 4x and 5x the throughput, respectively.
As for the AMD, I hope they will do what they recently did in their Zen4c microarchitecture in the newly launched server chips: reduce clocks speeds, reduce L3 cache, but don’t cripple the actual cores.
It's a common misconception, they are die area efficient.
I'm pretty sure Lisa Su just said recently that AMD is not going big.LITTLE
Leaked roadmaps of AMD say otherwise, at least for consumer parts. Zen 5 is rumored be go big.LITTLE.
Looks like it wasn't Lisa Su's comments I was remembering:
https://www.techpowerup.com/review/amd-ryzen-interview-ai-ze...
TL;DR: They have been experimenting with big.LITTLE internally and likely aren't targeting desktop first, if at all. The AMD VP seems more concerned with power constrained environments such as mobile/laptop for a big.LITTLE product.
https://www.techpowerup.com/review/amd-ryzen-interview-ai-ze...
TL;DR: They have been experimenting with big.LITTLE internally and likely aren't targeting desktop first, if at all. The AMD VP seems more concerned with power constrained environments such as mobile/laptop for a big.LITTLE product.
>I want all cores to be fast, and I have enough parallelizable work for them.
To each their own, but I just want to browse Lemmy and play RimWorld. My PC is from 2016 and it works great.
To each their own, but I just want to browse Lemmy and play RimWorld. My PC is from 2016 and it works great.
AFAIK the point of having tons of E-cores is to crunch the hell out of multithreaded workloads, that is, a bunch of cores collaborating on the same task (therefore running the same code). This is, notably, one of the best ways to score highly on multithreaded benchmarks, something I'm very sure hasn't impacted their core counts at all, with "high-performance" desktop CPUs being mostly the low-power E-cores
I thought ddr4 and ddr5 were in the same ballpark for performance, with the latter using less power and needing more on the fly error correction. Which basically makes ddr5 seem worse than ddr4, so hopefully I'm missing something. Pretty sure there isn't a 2x in bandwidth gain.
DDR5 isn’t a mature technology yet. It’s not worse than DDR4, but not better by more than a few % either in real-world usage at the moment.
Gotta be careful when comparing to AMD….. not all cores are alike.
Hopefully the power draw will be reasonable
Does it void warranty?
The ghost of NetBurst appears.[1]
[1] https://en.wikipedia.org/wiki/NetBurst#Scaling-up_issues