Discussion in 'Article Discussion' started by bit-tech, 12 Jun 2018.
I get the distinct impression Intel are using smoke and mirrors when it comes the 8086 and that 28c HEDT part, the 8086 only hits 5Ghz on a single core and as mentioned in the article the 28c HEDT was nothing more than a Xeon SKU on steroids.
I think AMD really caught them on the hop with ZEN and their reaction seems to indicate their in a bit of a fluster, for a long time Intel have been focusing on clock speed over core counts, *arguably to our detriment, I'm hoping we'll see all these extra cores being put to good use now as there's not really been much in the way of innovation in terms of how the software on our system runs for over a decade, we've been stuck with four cores slowly getting faster.
*Depending on your usage.
On the other hand, Intel have demonstrated actually achieved all-core clocks with the 28-core XCC die (albeit with HPC cooling) while the Threadripper 32-core remains a paper chip (though likely based on the Epyc 7601) with unknown actual performance.
For consumer workloads, the core-count race is worryingly akin to the Megapixel race. Consumer workloads are Amdahl's Law scalers, not Gustafson's. Returns drop off rapidly, and even a decade of quad-core CPUs has not resulted in widespread threaded workloads. This isn't just 'developer lazyness', just that parallelism is not always even possible.
We've already seen this in the mobile SoC market in accelerated time, with a race to OCTA COOOOOORE resulting in no real performance gain but an increase in power demand, followed by core counts dropping far back down and a handful of faster cores (usually two fast cores with 2/4 low power cores) being the preferred route e.g. the Apple A series.
For HPC and the small number of workloads that DO scale well, Moar Cores = better. But those are often embarrassingly-parallel workloads anyway, where GPUs eat the lunch of high core count CPUs anyway.
Eh? AMD showed threadripper 32 core running aircooled, how is that more of a paper chip than Intels effort?
Intel may as well have got de8aur in and said we're launching a 7Ghz i7 it would be as legit.
One is going to be out in a couple of months dropping into a consumer tr4 socket, the other only exists in server land, and is significantly slower than 5Ghz.
Not sure where AMDs 4Ghz comes from everything I have seen and read say 3Ghz base 3.4 all core boost but they do have WIP next to the 3.4, no mention of anything higher although you might expect it to be with XFR2 and Pb2
Call me cynical, mention Intel and I think Brian Krzanich, corruption and years of ****ing price gouging.
32 core (and the almost certainly going to happen as well 24 core) Ripper is not going to be an entirely new product category, instead it is designed to be the Annihilator of the 7980XE.
The 28 core from Intel however is in effect creating a completely new Ultra HEDT XTX PE category with a rebranded server socket and so on separate from the regular peasant HEDT.
Ultra HEDT XTX PE was made up on the spot, Intel hasn't actually announced the marketing name yet.
Luckily for CPUs a lot of what could be moved to GPUs hasn't done so.
But yeah, there are definitely limits to the core wars, plus what you said about mobile CPUs will eventually happen in Desktop CPUs as well, next big thing will be not all cores being created equally any more.
True, but in my eyes all Intel achieved was showing us how they can overclock a Skylake Xeon part that they release almost a year ago, there's no information of when, or even if, they'll release a 28c 5Ghz parts (i highly doubt they will btw)
No and i wasn't implying that they are, their probably under time and financial constraints but their not lazy, however i question if the lack of widespread threaded workloads is due to there being only four cores to play with so it's consider not worth investing in or is it truly because parallelism is not always even possible.
Can Intel even scale much further core wise with a single die approach?
Yes and no.
There are physical limits to how big a die can be, but die shrinks keep them away from that limit.
However there is another aspect to consider, is it worth it?
If you push manufacturing too far the yield will inevitably hit a wall from where it drops exponentially, at which point you can save tons of money by backing off a step and going the multi die glue route.
Adding more cores gives severely diminishing returns. If your workload is parallelism, then just going from single to dual core (way back in 2005) would give you a doubling of performance. 'Just' 4 cores would give a further doubling (quadrupling). If your workload is not easily parallelisable, then adding more cores is not an incentive no matter if it's 8 or 32.
Up to at least 28 cores, clearly yes as those are shipping. Whether they can just keep growing XCC depends on how close to reticle size they want to push.
It may be a moot point anyway with EMIB. Bandwidth of a monolithic Silicon interposer, but without the cost, assembly (one failed bond kills the assembly), or manufacturing (no TSVs) issues.
I know that's how it works, what i was questioning was if there could be some way around that, theoretically a sequential job can be broken down into smaller parts and worked on individually, hence the mention about innovation.
Leaving aside the recent security issues surrounding branch prediction isn't that in essence breaking down what should be a sequential job and working on what it predicts the outcome will be before the sequential job has finished.
Intel will allegedly launch a 22 core chip for socket 2066:
Of course given the source it should be taken with a huge grain of salt but that would shrink the gap between the 18 and 28 cores significantly (so Ripper 2 might actually have some serious competition rather than just the joke price 28 core with a comedy tdp that needs a new platform).
Software needs to be built with parallelism in the first place, the problem we have now is the problem we will have going forward and that is that people rarely build new engines, building one that works takes time in the first place whether its games or workplace, often new features are kludged into old frameworks when there are clear reasons why more cores would work, with routines updated here and there but the overall effect does not always get you where you need to be, as there is more often than not, part of the pipeline fundamental to the software framework than can't be split up, as it was never designed to be, multicore support is often just a band aid, in the same way that giving your granny a new hip doesn't turn her into an athlete as there still the rest of her to contend with.
It's not even a problem of 'old engines': in the years since multi-core CPUs become popular we've gone through 3 versions of Unreal Engine and the entire development of Unity. Most consumer workloads are as parallel as they're going to get.
The thing is that even if you can parallelise (is that even a word?) workloads, the whole thing is generally only as fast as the slowest part, and if that can't be parallelised then you're boned. Some stuff just can't be split up across threads/cores.
Separate names with a comma.