Intel's Future Chips: News, Rumours & Reviews

Page 145 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Status
Not open for further replies.
Just going to point out something ironic: The Itanium architecture is immune to all variants of Spectre/Meltdown, due to being an in-order architecture that doesn't include all those wonderful x86 speedhacks that are now being taken advantage of.

Seriously, if Intel designed a new CPU architecture that was both secure and massively parallel today, it would essentially look like the Itanium architecture.

That is a pretty ironic thing. It makes me wish we moved to IA64 instead of x86-64 but not much we can do now.

Unless Intel could write a new 64bit uArch that can work with current 64bit OSes but still ditch x86-64.

Interestingly enough, Sunny Cove is making a change to x86-64 by extending its useful bits. Although We can run 64bit now it was limited to 48bits addressable while Sunny Cove will have 57 bits addressable. Maybe that will mitigate a lot of these attack methods.


Its a pretty interesting read.
 
Interestingly enough, Sunny Cove is making a change to x86-64 by extending its useful bits. Although We can run 64bit now it was limited to 48bits addressable while Sunny Cove will have 57 bits addressable. Maybe that will mitigate a lot of these attack methods.

Not really; the only thing Intel is doing is wiring up the addresses that weren't before; aside from the increased usable address space there's nothing that's fundamentally changing architecturally.

Itanium was 5 years too early as an architecture; it's exactly what everyone wants now, a massively parallel & secure architecture that does away with all the attack factors inherent in current x86-64 implementations. AMD kneecapped the architecture when it introduced x86-64 as an x86 extension.
 
Not really; the only thing Intel is doing is wiring up the addresses that weren't before; aside from the increased usable address space there's nothing that's fundamentally changing architecturally.

Itanium was 5 years too early as an architecture; it's exactly what everyone wants now, a massively parallel & secure architecture that does away with all the attack factors inherent in current x86-64 implementations. AMD kneecapped the architecture when it introduced x86-64 as an x86 extension.

Yea and Intel is finally killing it off too.

Oh well. Guess we will just have to wait and see if Intel has made any sort of change to help secure it.

AMD really did doom us to be stuck with it forever. At least until Quantum computing maybe.
 
Yea and Intel is finally killing it off too.

Oh well. Guess we will just have to wait and see if Intel has made any sort of change to help secure it.

AMD really did doom us to be stuck with it forever. At least until Quantum computing maybe.

I don't see a way to really secure modern CPUs without getting rid of all the performance boosts we've enjoyed for years on end. At this point, the best bet is for Quantum Computing to take off and basically reset everything. I'm pessimistic though, both due to accuracy concerns (being 99.999999% correct on a modern OS would result in a BSOD every few seconds), and, speaking as a Software Engineer here, the fact that no ones told me how to actually program for these things yet.
 
I don't see a way to really secure modern CPUs without getting rid of all the performance boosts we've enjoyed for years on end. At this point, the best bet is for Quantum Computing to take off and basically reset everything. I'm pessimistic though, both due to accuracy concerns (being 99.999999% correct on a modern OS would result in a BSOD every few seconds), and, speaking as a Software Engineer here, the fact that no ones told me how to actually program for these things yet.

Nah you wont have to program. AI will program.

Jokes aside it is a conundrum really. Unless we can magically push to something new we are screwed. AMDs x86-64 was both a blessing and a curse it seems.
 
I'm just talking out my earhole here, because I in don't know squat about programming, but I was thinking about this the other day. Isn't there a way that branch prediction could be run in a sandboxed environment that protects it from vulnerabilities WHILE the bulk of the work is done directly, in parallel? Sure, there would be some overhead and you'd lose some of the benefits of branch prediction, but it seems you'd still have better performance than straight non-predictive processing? IDK, maybe that's not even possible.
 
I’m sorry . I just have to give amd props. I haven’t seen this kind of competitive ness since the athlon days . They deserve a serious soft clap. Afik, their a much smaller company with way less resources. I get a vibe intel has been nefarious . Through out the years . Maybe stealing engineers , who knows . But when your number one. Your number one.

I really think intel might be hitting a ceiling. They can only push the current architecture so high.

Imo , I believe the winner will be the one most widely adopted by developers. Optimization I think, will be the true winner in the next for years . Imo x86 is at its limits but I don’t know much. So that’s pulled out of my rear. Or not . I would love to look at a chart of the last 5 years of CPU’s from intel performance wise. I think we can all agree it’s never ever ever been this slow. There has to be a physical limitation. Silicone as a conductor.

I’m really routing for amd. I’m not a console gamer but they manage to deliver optimized gaming with minimal hardware . I love their idea of making a brand new api... I know developers are really clamoring for a universal , easily optimized cross platform api , and I think amd is in the position to do that .

While I’m on this rant can we please get rid of windows as a go to os.

I think steam was really onto something. I think of gaming could have a bright future if manufactures can get together and come up with a great way to have that kind of software hardware optimization that apple pulls off.
 
I'm just talking out my earhole here, because I in don't know squat about programming, but I was thinking about this the other day. Isn't there a way that branch prediction could be run in a sandboxed environment that protects it from vulnerabilities WHILE the bulk of the work is done directly, in parallel? Sure, there would be some overhead and you'd lose some of the benefits of branch prediction, but it seems you'd still have better performance than straight non-predictive processing? IDK, maybe that's not even possible.

First off, sandboxing hurts performance, without exception. Let's not forget the bulk of the security holes being found are being found in the bits that add extra performance.

Secondly, CPUs really aren't designed for parallel operations. Slapping more serial processors together works up to a point, but is an architectural dead-end; it simply doesn't scale beyond more then a handful of cores before you start running into other bottlenecks within the system (typically, the memory bus or inter-core communication).

Besides, we already have massively parallel processors anyways; they're called GPUs.

universal , easily optimized cross platform api

That's an oxymoron if I ever heard one. In order to make such an API, you need to abstract it so much you end up killing performance and making it near impossible to work with (see: OpenGL).
 
Thanks Jimmy for that link! Fascinating what Intel is doing with Sunny Cove.

Man though Intel is going thru with ANOTHER 14nm refresh? Commet lake. Sheesh.

Strange as I don't remember them on the roadmap and there is nothing to them except the Linux drivers. Strange to not even have an actual roadmap showing it. But I can see why Intel might launch something like this, to help fight back Zen 2 since it might have more than 8 cores as well.

I would think of it as a stop gap until they can start pushing 10nm desktop parts. I just hope they push their Forevos sooner rather than later. I think that will be an interesting design.

I’m sorry . I just have to give amd props. I haven’t seen this kind of competitive ness since the athlon days . They deserve a serious soft clap. Afik, their a much smaller company with way less resources. I get a vibe intel has been nefarious . Through out the years . Maybe stealing engineers , who knows . But when your number one. Your number one.

I really think intel might be hitting a ceiling. They can only push the current architecture so high.

Imo , I believe the winner will be the one most widely adopted by developers. Optimization I think, will be the true winner in the next for years . Imo x86 is at its limits but I don’t know much. So that’s pulled out of my rear. Or not . I would love to look at a chart of the last 5 years of CPU’s from intel performance wise. I think we can all agree it’s never ever ever been this slow. There has to be a physical limitation. Silicone as a conductor.

I’m really routing for amd. I’m not a console gamer but they manage to deliver optimized gaming with minimal hardware . I love their idea of making a brand new api... I know developers are really clamoring for a universal , easily optimized cross platform api , and I think amd is in the position to do that .

While I’m on this rant can we please get rid of windows as a go to os.

I think steam was really onto something. I think of gaming could have a bright future if manufactures can get together and come up with a great way to have that kind of software hardware optimization that apple pulls off.

x86 is hitting its limits and has been for a while. Thats why most performance comes from other methids. However we really have AMD to thank for x86 still being the primary CPU uArch for desktops. If Intel had their way we would have been on IA-64 instead starting back in the late 90s/early 2000s.
 
x86 is hitting its limits and has been for a while. Thats why most performance comes from other methids. However we really have AMD to thank for x86 still being the primary CPU uArch for desktops. If Intel had their way we would have been on IA-64 instead starting back in the late 90s/early 2000s.

More like late 2000's; there's a reason why Intel went to servers first, as they would benefit the most from an implicitly parallel architecture. Intel would then ramp clockspeed, get MSFT's server OS's to work out the architectural kinks, then eventually release to general consumers, probably around the time Windows 7 would have come around.

x86 and it's descendant architectures have been tapped out for a very long time, why do you think Intel keeps coming up with dedicated instructions to do specific operations faster? And now that die shrinks are basically coming to an end, there really aren't any more ways to squeeze performance out of it. And adding more cores is only efficient up to a point; nevermind you're still limited by how fast an individual core is capable of going.

Of course, now that x86-64 is entrenched and has legacy SW support behind it, we're stuck with it until some other architecture can emulate x86 and x86-64 in hardware, which is going to be damn impossible. We're stuck with it now, probably for a few decades to come.
 
More like late 2000's; there's a reason why Intel went to servers first, as they would benefit the most from an implicitly parallel architecture. Intel would then ramp clockspeed, get MSFT's server OS's to work out the architectural kinks, then eventually release to general consumers, probably around the time Windows 7 would have come around.

x86 and it's descendant architectures have been tapped out for a very long time, why do you think Intel keeps coming up with dedicated instructions to do specific operations faster? And now that die shrinks are basically coming to an end, there really aren't any more ways to squeeze performance out of it. And adding more cores is only efficient up to a point; nevermind you're still limited by how fast an individual core is capable of going.

Of course, now that x86-64 is entrenched and has legacy SW support behind it, we're stuck with it until some other architecture can emulate x86 and x86-64 in hardware, which is going to be damn impossible. We're stuck with it now, probably for a few decades to come.

Thats why AMDs assault with cores to me is strange. If Zen 2 pushes 16 to mainstream I am not sure I feel the point of it. I doubt they will be able to clock much higher than Intel nor get higher IPC either.

I doubt we will ever see perfect core scaling either. Writing software for that seems near impossible and the benefits might not outweigh the downsides.
 
Thats why AMDs assault with cores to me is strange.
Nothing strange there: writing efficient multi-threaded code requires considerable extra effort so programmers only do so when absolutely necessary and the potential gains are substantial. If the majority of PCs out there still has only four cores, then developers will focus on four cores minus typical background overhead and the majority of what comes out ends up limited to 2C4T or equivalent in what it can comfortably use. If the average PC increases to 8C16T though, now programmers have 2-3X as much processing power they can tap into to justify the effort.

It is a typical chicken-and-egg affair: few programmers want to target their software for hardware that doesn't exist in meaningful quantities and hardware makers don't want to make hardware for software that doesn't exist. One side has to break the stalemate eventually.

I doubt we will ever see perfect core scaling either. Writing software for that seems near impossible and the benefits might not outweigh the downsides.
Supercomputers with 100 000+ cores beg to disagree: you need to design your algorithms with near-perfect scaling to make use of that many cores in a single system running a single simulation. Near-perfect scaling is possible but only for embarrassingly parallel problems like 3D rendering, finite-element analysis, deep-learning, etc.
 
Last edited:
Nothing strange there: writing efficient multi-threaded code requires considerable extra effort so programmers only do so when absolutely necessary and the potential gains are substantial. If the majority of PCs out there still has only four cores, then developers will focus on four cores minus typical background overhead and the majority of what comes out ends up limited to 2C4T or equivalent in what it can comfortably use. If the average PC increases to 8C16T though, now programmers have 2-3X as much processing power they can tap into to justify the effort.

It is a typical chicken-and-egg affair: few programmers want to target their software for hardware that doesn't exist in meaningful quantities and hardware makers don't want to make hardware for software that doesn't exist. One side has to break the stalemate eventually.


Supercomputers with 100 000+ cores beg to disagree: you need to design your algorithms with near-perfect scaling to make use of that many cores in a single system running a single simulation. Near-perfect scaling is possible but only for embarrassingly parallel problems like 3D rendering, finite-element analysis, deep-learning, etc.

A very specific market that makes sense. Not on the consumer end though. We don't do that and our software doesn't work like that to take advantage of more and more cores.

It is like Intels Terascale project. It was interesting but the use for consumers would have been near pointless as scaling from (at the time dual cores were the majority with quads just coming out) dual/quad to 80 cores would have been improbable.
Nothing strange there: writing efficient multi-threaded code requires considerable extra effort so programmers only do so when absolutely necessary and the potential gains are substantial. If the majority of PCs out there still has only four cores, then developers will focus on four cores minus typical background overhead and the majority of what comes out ends up limited to 2C4T or equivalent in what it can comfortably use. If the average PC increases to 8C16T though, now programmers have 2-3X as much processing power they can tap into to justify the effort.

It is a typical chicken-and-egg affair: few programmers want to target their software for hardware that doesn't exist in meaningful quantities and hardware makers don't want to make hardware for software that doesn't exist. One side has to break the stalemate eventually.


Supercomputers with 100 000+ cores beg to disagree: you need to design your algorithms with near-perfect scaling to make use of that many cores in a single system running a single simulation. Near-perfect scaling is possible but only for embarrassingly parallel problems like 3D rendering, finite-element analysis, deep-learning, etc.

The only advantage I can see of more cores is being able to offload tasks to other cores while major tasks take on primary cores. Otherwise in the consumer realm I don't see a benefit of having 16 cores and 32 threads, which is what a lot of people expect AMD to do with Ryzen 3.

I especially don't see them doing that for cheap. A new process and tweaked uArch means lower yields overall. Prices would have to be higher unless AMD is trying not to make money.
 
A very specific market that makes sense. Not on the consumer end though. We don't do that and our software doesn't work like that to take advantage of more and more cores.
Really? AI scales well with extra cores, better game AIs will require more cores. Physics scales well with more cores, better game physics will require more cores. More sophisticated visual effects require more scene pre-processing, that pre-processing will require more cores too. If extra cores are broadly available, software developers will find uses for them that they cannot afford to save resources for while mainstream PCs are still mostly 2C4T or 4C4T.
 
Really? AI scales well with extra cores, better game AIs will require more cores. Physics scales well with more cores, better game physics will require more cores. More sophisticated visual effects require more scene pre-processing, that pre-processing will require more cores too. If extra cores are broadly available, software developers will find uses for them that they cannot afford to save resources for while mainstream PCs are still mostly 2C4T or 4C4T.

Most of that can also be offloaded to the GPU which can to, and do it better. It's why even though its more a gimmick, nVidias Physixs is better than using CPU cores. I am not saying that eventually we will use them. Be it offloading certain aspects to other cores, one of the first games I remember doing this was Crysis back in 2007 that offloaded audio processing to the second core on a CPU. It would run without a dual core but audio would not work as the game was programmed that way.

You are most likely correct and hardware pushing might call for the utilization by software but I will not hold my breath. There is plenty of power in PCs these days that in consumer machines go unused.
 
Most of that can also be offloaded to the GPU which can to, and do it better.
If the GPU has that much processing time to spare, which it doesn't at higher resolutions with ray tracing, DLSS and target frame rates in excess of 60FPS. Until GPUs run out of visual gimmicks they can sink their resources into, it makes more sense to delegate AI and improved physics to otherwise unused CPU cores/threads as more become widely available than pile that up on the GPU is already at its limits just doing its primary task. Also, running AI and physics on the GPU would be problematic at the lower-end where it would consume a disproportionate amount of resources.
 
Really? AI scales well with extra cores, better game AIs will require more cores. Physics scales well with more cores, better game physics will require more cores. More sophisticated visual effects require more scene pre-processing, that pre-processing will require more cores too. If extra cores are broadly available, software developers will find uses for them that they cannot afford to save resources for while mainstream PCs are still mostly 2C4T or 4C4T.

The problem is one of scale. Take AI or Physics; one calculation isn't that hard to accomplish. But the problem scales exponentially once you have multiple objects start to interact with eachother. There's a reason why you don't see games allow things like, for example, having debris blown by a grenade be lethal to any character that gets hit by them, because it's too hard to calculate that level of interaction. Likewise, even getting one decent AI is a PITA, now imagine the mess once you get multiple in-game characters trying to work in a coordinated fashion; it's much easier to just have each thing have it's own AI.

Basically, to get any real benefit you'd need hundreds of CPU cores. Otherwise you simply won't have the scale necessary to do these types of problems. These are all fundamentally tasks that should be performed on GPU-like architectures, not on the CPU.
 
These are all fundamentally tasks that should be performed on GPU-like architectures, not on the CPU.
Do you know what happens when a given class of tasks becomes popular? CPU manufacturers add dedicated hardware and associated instructions to do it more efficiently just like GPUs do. The main difference between GPUs and CPUs is that since GPUs are mostly self-contained systems, manufacturers have more freedom to completely re-design the whole architecture or even start from scratch on a whim.

Until we get there though, a 2-3X increase in spare CPU-power for improved AI and physics at little extra cost due to mainstream CPUs finally having 3-4X as many cores as they used to is still a 2-3X improvement.
 
Last edited:
Do you know what happens when a given class of tasks becomes popular? CPU manufacturers add dedicated hardware and associated instructions to do it more efficiently just like GPUs do. The main difference between GPUs and CPUs is that since GPUs are mostly self-contained systems, manufacturers have more freedom to completely re-design the whole architecture or even start from scratch on a whim.

Until we get there though, a 2-3X increase in spare CPU-power for improved AI and physics at little extra cost due to mainstream CPUs finally having 3-4X as many cores as they used to is still a 2-3X improvement.

You are vastly underestimating how complicated multi-object dynamics get. You'd need about 20x the CPU horsepower then we have today to even approximate how complicated that mess gets.

The issue here is that's the next step beyond "go ragdoll", but it's insanely complicated to compute, and there aren't any real ways to cheat the calculations to make them simpler. That's why we see very limited implementations occasionally (NVIDIA Hairworks is basically this, just on one specific object (Hair)), and they all chug performance. Making an entire engine built around this concept will bring everything short of supercomputers to their knees.

This isn't linear progression, it's exponential. This is actually the type of thing quantum computers should be much better at then traditional CPUs, and we're likely waiting for that before we start getting better physics implementations.
 
Oh, I don't know why I missed this...

While you're not wrong, gamerk, what you're talking about won't happen and it doesn't happen anyway. Currently, most engines do not do physics in the classic sense nor use like-for-like math to calculate things. Everything is simplified by several orders of magnitude. Only simulation software runs close-to-real equations and even they're always telling you how accurate their results is compared to doing it with pen and paper. Point is: no matter how complex the real problem is, computers won't get close unless they need to (again: simulations). On the other hand, we do want them to get closer, so the algorithms used by regular software produce life-like experiences (hence why I love the push for RayTracing, no matter how stupidly expensive is still). Particularly, for AI, there are no complicated algorithms, but a HUGE amount of things to take into account that makes a very good case for going wide, but also requires a lot of data input. That sort of calculation makes more sense in the CPU than the GPU. I'd argue the same for Physics engines.

So, I like the idea of "going wide" as long as the baselined per-core performance stays up. More than just "developers" (as in game studios and what not), tool-developers need to play catch up: UE, Unity, Havok, etc... They have a lot of resources on the table they can use for things, but they're not because... Reasons...

Cheers!
 
I wonder if it'll be enough to fend off TR3 though...

You can clearly see those are aimed to entice people from getting Ry3900(X) and Ry3950X parts, but once TR3 arrives, it'll be another ball game as the whole platform gets a proper lift in... Everything.

Cheers!
 
  • Like
Reactions: goldstone77
Status
Not open for further replies.