Speculation: Future Iterations of Compute Technology

eek2121

Platinum Member
Aug 2, 2005
2,930
4,026
136
I am curious as to what direction everyone thinks Processors, Motherboards, RAM, Storage, etc. will go in the future. IMO, despite everyone's opinion, there is still plenty of room left on the performance table. Here are my thoughts:

Not on the table:
  1. Monolithic CPUs - I think the age of monolithic CPUs is dead. As process nodes shrink, it becomes harder to control heat/leakage. Intel is finding this out with 10nm. Breaking things up on the package is the way to go, even if it's just the memory controller and IO like AMD is doing.
  2. HBM on the CPU package - While it is a novel idea, I think HBM will remain solely in the data center and on enterprise/high end (think: super computer) configs. The price/benefits just aren't there.
  3. Spinning Drives - I think that hard drives are gradually going to go away for casual users, and will be limited to datacenters in high capacity fashion.
On the Table:
  1. Chiplet design - I think a separate IO die for both AMD and Intel is the way to go for future CPU designs. Whether using monolithic cores in a single chiplet with an IO die or multiple chiplets with groups of cores, this is clearly going to be the superior strategy moving forward. The benefits outweigh the minor increase in costs.
  2. "Spacers" between CPU cores and other components within a die - As CPU dies shrink, frequencies go down due to leakage. I expect we will reach a point where a 5nm CPU core will be embedded in a much larger package to help limit leakage and control heat. Note that AMD did this with Zen+ to an extent.
  3. A MASSIVE increase in core counts - #1 and #2 gradually lead to more cores. As long as Intel/AMD can control leakage, individual CPUs can shrink to their limit, while maintaining a high clock speed.
  4. Cache Improvements - Expect further cache refinements on both AMD and Intel chips, including both increased cache sizes, and eventually an L4 cache. This is the single 'easiest' way to boost performance, but it's also the most expensive.
  5. Increased APU performance - I suspect Intel is going to drive this one home eventually. We will eventually see APU performance at 4k. It sounds a bit out there, but Intel has been pushing hard to increase performance and catch up to AMD every generation.
  6. DDR Continued improvements, QDR possible. DDR4-5133 was recently demonststrated. That's 2.56 GHz. There will be a ceiling to DDR improvements without any type of active cooling, but I predict further speed improvements, a quad pumped data rate, tighter timings, and shorter traces to drastically help with memory access latencies. Eventually RAM will reach parity akin to L4 or even L3 cache I suspect.
  7. Larger SSDs displacing hard drives - I already see this happening. In my own system I have a 3 TB of SSD storage (1 TB NVME and 2 TB SATA) and plan to replace that with 6 TB NVME later this year. The prices are still a bit high, but they are falling, and have already fallen below forecasted levels, the average user only needs around 500 GB, and 500 GB drivers are super cheap. Nowadays you can get a 500 GB SSD for pennies. The only thing slowing this down in the OEM sector are possible kickbacks from hard drive vendors. However, these vendors are slowly moving to solid state, so eventually hard drives will be replaced. In addition, SSD speeds are rapidly reaching the point of DDR4 speeds. It wouldn't surprise me if one day, the two merge and become one, though I'm not a fan of this.
  8. This one is a bit more out there - CPU instruction sets to supplement GPUs - As APUs become more ubiquitous, I expect CPUs to take over more of the workload. We may even see a gradual merge of performance parts on the AMD and Intel side. While this sounds a bit outlandish, Nvidia holds a sizeable marketshare and Intel and AMD would love to steal that marketshare away by using x86 extensions to make discrete graphics obsolete.
  9. This one is way out there - ARM gradual compatibility. ARM technology is rapidly catching up to x86. I predict that eventually we'll see a socketed ATX ARM design and a number of vendors competing for business. Windows for ARM will become a thing, and build systems for game engines like Unity will auto target those systems. Intel/AMD will respond by adding ARM instruction sets to their own CPU designs.
What are your thoughts? Do you think I'm wrong? Did I miss anything?
 

VirtualLarry

No Lifer
Aug 25, 2001
56,343
10,046
126
This one is way out there - ARM gradual compatibility. ARM technology is rapidly catching up to x86. I predict that eventually we'll see a socketed ATX ARM design and a number of vendors competing for business. Windows for ARM will become a thing, and build systems for game engines like Unity will auto target those systems. Intel/AMD will respond by adding ARM instruction sets to their own CPU designs.
That would be ... kind of weird, and slightly uncomfortable to me, personally, but probably not outside the realm of possibility that we might see some ARM-based designs that conform to ATX mobo specifications and power delivery. I could see those parts, in turn, used by some future Apple product, using their own ARM CPU designs. (Such boards might not be socketed, they might be BGA / soldered for the CPU, etc.)
 

soresu

Platinum Member
Dec 19, 2014
2,662
1,862
136
This one is way out there - ARM gradual compatibility. ARM technology is rapidly catching up to x86. I predict that eventually we'll see a socketed ATX ARM design and a number of vendors competing for business. Windows for ARM will become a thing, and build systems for game engines like Unity will auto target those systems. Intel/AMD will respond by adding ARM instruction sets to their own CPU designs.
AMD has a high end ARM v8-A uArch called K12.

Unfortunately, unless it has been kept tightly under wraps it has probably been put on ice in favor of emphasizing Zen development effort.

At this point though, the high end ARM Cortex-A cores have plenty IPC, and simply need more software to run on them - preferably not emulated ala Windows on ARM.
 

NTMBK

Lifer
Nov 14, 2011
10,237
5,021
136
  1. This one is a bit more out there - CPU instruction sets to supplement GPUs - As APUs become more ubiquitous, I expect CPUs to take over more of the workload. We may even see a gradual merge of performance parts on the AMD and Intel side. While this sounds a bit outlandish, Nvidia holds a sizeable marketshare and Intel and AMD would love to steal that marketshare away by using x86 extensions to make discrete graphics obsolete
I think you're way off base with this one. These days the limiting factor isn't die area, it's power consumption and heat generated. A jack of all trades CPU is always going to be less efficient than dedicated GPU circuitry, and hence trading the die side for a proper GPU just makes sense.
 
  • Like
Reactions: Pilum and Vattila

soresu

Platinum Member
Dec 19, 2014
2,662
1,862
136
HBM on the CPU package - While it is a novel idea, I think HBM will remain solely in the data center and on enterprise/high end (think: super computer) configs. The price/benefits just aren't there.
HBM for CPU's is more problematic because of the fact that it was designed with GPU use cases in mind, and not that of CPU - which was more the focus of the Hybrid Memory Cube (HMC) initiative.

The main problem is latency from what I have heard - though the recent increase to stack height (12 high) and die density (16 Gbit) in the official HBM2 spec, coupled with a lack of chatter about HBM3 directly makes me think that the crash of HMC may have caused some new features to be added to HBM to make it more suitable for CPU use cases.

It's also worth noting that a 'low cost' HBM initiative was mentioned by Samsung some time ago when HBM2 was announced - something like less TSV's, a 50% higher link bandwidth per pin, and a lower cost interposer design.
If this low cost HBM ever materialises, it would be something to consider for GFX card manufacturers even if the GPU price itself increases - as it simplifies their supply chain and PCB layouts, especially for cooling.
As it is, I'm wondering if AMD or nVidia might integrate the VRM's onto an interposer, and simplify the GFX PCB even further.
 

IntelUser2000

Elite Member
Oct 14, 2003
8,686
3,785
136
Not on the table:
  1. Monolithic CPUs - I think the age of monolithic CPUs is dead.

Monolithic dies will continue to exist. Because the fundamentals haven't changed. Multi-dies just allows the CPU designer more options. Smaller gains with process shrinks will make monolithic dies even more critical in certain segments of the market. It's a trade-off that's all.

Spinning Drives - I think that hard drives are gradually going to go away for casual users,

For casual users it'll continue to be very useful. In desktops HDDs are still quite dominant.

In addition, SSD speeds are rapidly reaching the point of DDR4 speeds.

DDR is 1,000x the speed of SSDs in latency. Even more if you think of it in terms of media only performance. Probably reaches 10,000x to 100,000x then. Latency is what made even SDRAM suitable as system memory, but not even the brand-spanking PCIe 4.0 SSDs with 5GB/s bandwidth can do the same.

Good thread though.
 
Last edited:

Keljian

Member
Jun 16, 2004
85
16
71
This one is a bit more out there - CPU instruction sets to supplement GPUs - As APUs become more ubiquitous, I expect CPUs to take over more of the workload. We may even see a gradual merge of performance parts on the AMD and Intel side.

Ice lake has AI instructions, this isn’t that far out there.

Ram reaching cache speeds? Yep that is far out there. This was hypothesised in the 90s. The reality is with current pcb tech, and near future pcb tech this is impossible. HBM is kind of the closest we will get. But the bit rate (hbm was 16 bit from memory) will limit the maximum bandwidth. There is a limit to how small you can make wires now, and the smaller you make them the more susceptible they are to noise, also the higher the impedance.
 

Atari2600

Golden Member
Nov 22, 2016
1,409
1,655
136
Here is a question - how much of the current x86 instruction set is regularly used?

How much space/power would be saved by having (i) 1 core within a CCX or (ii) 1 CCX within a chiplet or (iii) separate chiplet designs with and without:
(a) full x86 instruction set support
(b) reduced x86 instruction set support to most utilised instructions

Would the savings make it a worthwhile endeavour? Or is the uncore within even a CCX now so large that the instructions themselves (particularly legacy) are relatively trivial to incorporate?
 
  • Like
Reactions: Drazick

moinmoin

Diamond Member
Jun 1, 2017
4,952
7,665
136
Here is a question - how much of the current x86 instruction set is regularly used?

How much space/power would be saved by having (i) 1 core within a CCX or (ii) 1 CCX within a chiplet or (iii) separate chiplet designs with and without:
(a) full x86 instruction set support
(b) reduced x86 instruction set support to most utilised instructions

Would the savings make it a worthwhile endeavour? Or is the uncore within even a CCX now so large that the instructions themselves (particularly legacy) are relatively trivial to incorporate?
What do you want to achieve through that?

Energy efficiency is already achieved through power gating. Space saving is likely very minimal as well since all instructions need to be decoded anyway to know which core to use, and once decoded to the internal RISC representation the amount that can be reduced is likely negligible. A big way to reduce space and newly added complexity due to SIMD instructions is sharing FPU again between cores like the Construction cores did. Considering how that went down not worth the effort I'd say.
 

Atari2600

Golden Member
Nov 22, 2016
1,409
1,655
136
Thats a good point - unless the whole process could be tagged as containing legacy instructions or not - then you'd have to decode the damn thing to know where to assign it anyway.

How high is the fidelity on power gating? Can a CPU power down (or does it ever actually even power up) instructions that are unused whilst running a process?

[traditionally maintaining backward compatibility comes at a cost - that cost could be somewhat mitigated by reducing the number of cores/CCX/chiplets that maintain said compatibility]