Intel's 14th Gen Core K-Series CPU Specs Break Cover with Speeds Up to 6GHz
hothardware.com
hothardware.com
The ghost of NetBurst appears.[1]
[1] https://en.wikipedia.org/wiki/NetBurst#Scaling-up_issues
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.
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.
We really need a new language that self-parallelises with zero effort from developers.
It was my understanding that golang supports multi-core?
[0] https://pkg.go.dev/github.com/jeffdecola/my-go-examples/goro...
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.
What is the single-threaded workload that is sluggish? Is it something like encoding or compression?
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...
Lots of competition and lots of innovation.
Your laptop’s a month old? That’s great… for a nice, heavy paperweight!
It’s all about the Pentiums, baby.
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).
And I find multi core CPUs just as cool as the olden days.
$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.
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.
it's not exactly unexpected
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.
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.
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.
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.
To each their own, but I just want to browse Lemmy and play RimWorld. My PC is from 2016 and it works great.