Guru3D Rig of the Month - January 2020
Palit GeForce RTX 2070 SUPER GamingPro review
Team Group T-Force DarkZα 3600 MHz DDR4 review
Corsair Scimitar Elite RGB gaming mouse review
Cougar 700K Evo keyboard review
Aorus Liquid Cooler 360 review
AMD Ryzen Threadripper 3990X review
Corsair A500 CPU air cooler review
Palit GeForce RTX 2080 SUPER GamingPRO review
Lamptron SM436 PCI fan/RGB controller review
Intel Core i9 10980XE processor review
Posted by: on: 11/25/2019 09:00 AM [
120 comment(s) ]
In this article, we'll review the all-new 18-core Core i9 10980XE from Intel. Despite many announcements, this is the most versatile (in cores) HEDT processor for the consumer market from intel, the $979 Core i9 10980XE that sits as the flagship processor in the new Cascade lake line of processors.
Read article
Advertisement
Tagged as:
intel,
review Core i9 10980XE
pages 1 2 3 4 5
XS621
Junior Member
Posts: 3
Junior Member
Posts: 3
Posted on: 11/27/2019 10:24 AM
Their tech reviews are sourced from this guy https://twitter.com/antonyleather
Also, how hard can you shill for AyMD? Because you dont like their Truthful results you hate them? Facts are facts, deal with it.
Intel CAN be overclocked, everyone knows it, 4.7Ghz is enough to lead the pack.
Personally i think ill got with 3960x, the platform has future and I dont know how many years it will take for Intel to release a CPU that outright beats 3960x without overclocking.
The only thing that scares me personally is value, AMD CPU lose value like old prostitute, the 1350$ I Paid for the CPU will turn into 700$ next year, I hope this new generation keeps value But unlike Intel, AMD wants their old CPUs to lose value, so people buy new ones.
I really want to give AyMD a try, the CPU is out of stock, if by the time it comes in-stock Intel wont have it for sale for their employees ill keep the 24c AyMD
If not then, 500$ for the 18 core + 500$ for one oft he best mobos = 1K for CPU/Mobo set
My only problem is that right now i have 64GB of AMD GSKILL RAM, Neo something, when i got it 2 months ago, their QVL said its compatible iwth my z370 Gamer 7 and it works full speed, and im sure it will work with TR3 too, but x299 is unknown...
Then dont try AMD processors, they are not worth your time.
Their tech reviews are sourced from this guy https://twitter.com/antonyleather
Also, how hard can you shill for AyMD? Because you dont like their Truthful results you hate them? Facts are facts, deal with it.
Intel CAN be overclocked, everyone knows it, 4.7Ghz is enough to lead the pack.
Personally i think ill got with 3960x, the platform has future and I dont know how many years it will take for Intel to release a CPU that outright beats 3960x without overclocking.
The only thing that scares me personally is value, AMD CPU lose value like old prostitute, the 1350$ I Paid for the CPU will turn into 700$ next year, I hope this new generation keeps value But unlike Intel, AMD wants their old CPUs to lose value, so people buy new ones.
I really want to give AyMD a try, the CPU is out of stock, if by the time it comes in-stock Intel wont have it for sale for their employees ill keep the 24c AyMD
If not then, 500$ for the 18 core + 500$ for one oft he best mobos = 1K for CPU/Mobo set
My only problem is that right now i have 64GB of AMD GSKILL RAM, Neo something, when i got it 2 months ago, their QVL said its compatible iwth my z370 Gamer 7 and it works full speed, and im sure it will work with TR3 too, but x299 is unknown...
Then dont try AMD processors, they are not worth your time.
mackintosh
Senior Member
Posts: 245
Senior Member
Posts: 245
Posted on: 11/27/2019 01:11 PM
There is absolutely no doubt Intel will come back from this, just like they have before with C2D and then X58 (which was probably their best platform to date). They have the R&D budget and are flush with cash to sustain themselves over several years of AMD domination. That said, there's no doubt AMD have completely blindsided them, and no one in their right mind can possibly defend their current lineup given all the independent benchmarks we have been presented with.
There is absolutely no doubt Intel will come back from this, just like they have before with C2D and then X58 (which was probably their best platform to date). They have the R&D budget and are flush with cash to sustain themselves over several years of AMD domination. That said, there's no doubt AMD have completely blindsided them, and no one in their right mind can possibly defend their current lineup given all the independent benchmarks we have been presented with.
schmidtbag
Senior Member
Posts: 4699
Senior Member
Posts: 4699
Posted on: 11/27/2019 03:03 PM
I agree Intel will come back from this, but I don't at all think this is going to be C2D all over again.
For one thing, Intel's progress with 10nm has been delayed by several years, and they already seem to be giving up on that and moving smaller since by the time they complete 10nm, it'll be already be obsolete. To my understanding, architectures need to be optimized per-node, so, every month Intel delays something <=10nm, the more time they're buying AMD to release something better.
But here's the more important issue we have to accept: x86 as we know it is at a dead end. We're practically at the limits of silicon transistors, and despite how vastly different Intel and AMD have their architectures, they both have roughly the same IPC; the real-world performance differences are actually quite minimal, and can be narrowed down to things like cache. We can keep adding more cores, but most applications don't benefit from that and never will. Whatever Intel supersedes their Core i# series with, the architecture is going to have a very minimal per-core IPC improvement. I'm sure it'll have a vastly superior HT and it'll have more cores for a lower price, but otherwise I don't see how it can handily outperform Zen without making compromises.
In theory, there's quite a lot that could be done to x86 to improve it, either in terms of efficiency or raw performance. But the problem is backward compatibility. Pretty much the reason x86 is the most used architecture is because of binary compatibility. And it goes deeper than that: software runs better depending on the design of the pipelines. Bulldozer wasn't anywhere near as bad of an architecture as people made it out to be, but the problem is you had to write something for that architecture in order to tap into its true potential. Nobody was going to do that for AMD. So, even though Intel has the money and resources to create the best architecture x86 could ever be, they won't do that because that means current software is likely to take a performance hit, and that is not how you sell a product. Regressions for the sake of a better future is never acceptable to consumer products.
There is absolutely no doubt Intel will come back from this, just like they have before with C2D and then X58 (which was probably their best platform to date). They have the R&D budget and are flush with cash to sustain themselves over several years of AMD domination. That said, there's no doubt AMD have completely blindsided them, and no one in their right mind can possibly defend their current lineup given all the independent benchmarks we have been presented with.
I agree Intel will come back from this, but I don't at all think this is going to be C2D all over again.
For one thing, Intel's progress with 10nm has been delayed by several years, and they already seem to be giving up on that and moving smaller since by the time they complete 10nm, it'll be already be obsolete. To my understanding, architectures need to be optimized per-node, so, every month Intel delays something <=10nm, the more time they're buying AMD to release something better.
But here's the more important issue we have to accept: x86 as we know it is at a dead end. We're practically at the limits of silicon transistors, and despite how vastly different Intel and AMD have their architectures, they both have roughly the same IPC; the real-world performance differences are actually quite minimal, and can be narrowed down to things like cache. We can keep adding more cores, but most applications don't benefit from that and never will. Whatever Intel supersedes their Core i# series with, the architecture is going to have a very minimal per-core IPC improvement. I'm sure it'll have a vastly superior HT and it'll have more cores for a lower price, but otherwise I don't see how it can handily outperform Zen without making compromises.
In theory, there's quite a lot that could be done to x86 to improve it, either in terms of efficiency or raw performance. But the problem is backward compatibility. Pretty much the reason x86 is the most used architecture is because of binary compatibility. And it goes deeper than that: software runs better depending on the design of the pipelines. Bulldozer wasn't anywhere near as bad of an architecture as people made it out to be, but the problem is you had to write something for that architecture in order to tap into its true potential. Nobody was going to do that for AMD. So, even though Intel has the money and resources to create the best architecture x86 could ever be, they won't do that because that means current software is likely to take a performance hit, and that is not how you sell a product. Regressions for the sake of a better future is never acceptable to consumer products.
wavetrex
Senior Member
Posts: 768
Senior Member
Posts: 768
Posted on: 11/27/2019 04:11 PM
Yet AMD is capable of cramming 64 cores with SMT in one single CPU, and also make each one of them faster than equivalent Intel cores.
No x86/x64 is not dead.
Monolithic chips are. And until Intel finally gets that, they will fall more and more behind.
x86 as we know it is at a dead end
Yet AMD is capable of cramming 64 cores with SMT in one single CPU, and also make each one of them faster than equivalent Intel cores.
No x86/x64 is not dead.
Monolithic chips are. And until Intel finally gets that, they will fall more and more behind.
schmidtbag
Senior Member
Posts: 4699
Senior Member
Posts: 4699
Posted on: 11/27/2019 04:28 PM
None of that disproves anything I just said.
I didn't say x86 is dead, I said it's at a dead end. I basically hinted before that x86 isn't going anywhere. Intel is capable of outdoing AMD, but not by much. I think we all know Intel's next major architecture isn't going to be monolithic, because it just isn't cost effective when trying to pump out a lot of cores. But all that's going to do is just get them more cores at more affordable prices. It isn't going to give them a per-core IPC advantage, just as it didn't do for AMD.
So my point remains:
Individual x86 cores don't have much room to improve. Silicon transistors are almost as small as they can get. Adding more cores isn't going to make everything run faster and it is unrealistic to expect everything to adapt. x86 isn't going to die off in the foreseeable future, but its progress will stagnate very soon (which is what I meant by "dead end"). AMD's chiplet approach breathed new life into x86, but only for high-end applications. It didn't really do anything for the average person other than lower prices.
But, perhaps it doesn't need to get any better. More and more workloads are being pushed to GPUs, and quantum computers will soon be handling the heavy tasks that traditional binary processors just aren't fit for. I see x86 to be like the internal combustion engine: decently well refined and pretty much as good as it's ever going to get, but still found everywhere and not effectively obsoleted for the majority of people.
Yet AMD is capable of cramming 64 cores with SMT in one single CPU, and also make each one of them faster than equivalent Intel cores.
None of that disproves anything I just said.
No x86/x64 is not dead.
Monolithic chips are. And until Intel finally gets that, they will fall more and more behind.
Monolithic chips are. And until Intel finally gets that, they will fall more and more behind.
I didn't say x86 is dead, I said it's at a dead end. I basically hinted before that x86 isn't going anywhere. Intel is capable of outdoing AMD, but not by much. I think we all know Intel's next major architecture isn't going to be monolithic, because it just isn't cost effective when trying to pump out a lot of cores. But all that's going to do is just get them more cores at more affordable prices. It isn't going to give them a per-core IPC advantage, just as it didn't do for AMD.
So my point remains:
Individual x86 cores don't have much room to improve. Silicon transistors are almost as small as they can get. Adding more cores isn't going to make everything run faster and it is unrealistic to expect everything to adapt. x86 isn't going to die off in the foreseeable future, but its progress will stagnate very soon (which is what I meant by "dead end"). AMD's chiplet approach breathed new life into x86, but only for high-end applications. It didn't really do anything for the average person other than lower prices.
But, perhaps it doesn't need to get any better. More and more workloads are being pushed to GPUs, and quantum computers will soon be handling the heavy tasks that traditional binary processors just aren't fit for. I see x86 to be like the internal combustion engine: decently well refined and pretty much as good as it's ever going to get, but still found everywhere and not effectively obsoleted for the majority of people.
TLD LARS
Senior Member
Posts: 130
Senior Member
Posts: 130
Posted on: 11/27/2019 10:25 PM
None of that disproves anything I just said.
I didn't say x86 is dead, I said it's at a dead end. I basically hinted before that x86 isn't going anywhere. Intel is capable of outdoing AMD, but not by much. I think we all know Intel's next major architecture isn't going to be monolithic, because it just isn't cost effective when trying to pump out a lot of cores. But all that's going to do is just get them more cores at more affordable prices. It isn't going to give them a per-core IPC advantage, just as it didn't do for AMD.
So my point remains:
Individual x86 cores don't have much room to improve. Silicon transistors are almost as small as they can get. Adding more cores isn't going to make everything run faster and it is unrealistic to expect everything to adapt. x86 isn't going to die off in the foreseeable future, but its progress will stagnate very soon (which is what I meant by "dead end"). AMD's chiplet approach breathed new life into x86, but only for high-end applications. It didn't really do anything for the average person other than lower prices.
But, perhaps it doesn't need to get any better. More and more workloads are being pushed to GPUs, and quantum computers will soon be handling the heavy tasks that traditional binary processors just aren't fit for. I see x86 to be like the internal combustion engine: decently well refined and pretty much as good as it's ever going to get, but still found everywhere and not effectively obsoleted for the majority of people.
------------------------------------------------------------------------------------------------------------------------------------------------------------------
A lot can still be done with more cache, better instructions like AVX at full speed, SMT boost, better threaded software, something like asynchronous compute, build in HBM, build in GPU, more memory speed, more bus speed, lower price....
Everything is a dead end if you look long enough into the future and so will the silicon replacement be when it arrives, but until that happens we can enjoy it until the next big thing arrives.
None of that disproves anything I just said.
I didn't say x86 is dead, I said it's at a dead end. I basically hinted before that x86 isn't going anywhere. Intel is capable of outdoing AMD, but not by much. I think we all know Intel's next major architecture isn't going to be monolithic, because it just isn't cost effective when trying to pump out a lot of cores. But all that's going to do is just get them more cores at more affordable prices. It isn't going to give them a per-core IPC advantage, just as it didn't do for AMD.
So my point remains:
Individual x86 cores don't have much room to improve. Silicon transistors are almost as small as they can get. Adding more cores isn't going to make everything run faster and it is unrealistic to expect everything to adapt. x86 isn't going to die off in the foreseeable future, but its progress will stagnate very soon (which is what I meant by "dead end"). AMD's chiplet approach breathed new life into x86, but only for high-end applications. It didn't really do anything for the average person other than lower prices.
But, perhaps it doesn't need to get any better. More and more workloads are being pushed to GPUs, and quantum computers will soon be handling the heavy tasks that traditional binary processors just aren't fit for. I see x86 to be like the internal combustion engine: decently well refined and pretty much as good as it's ever going to get, but still found everywhere and not effectively obsoleted for the majority of people.
------------------------------------------------------------------------------------------------------------------------------------------------------------------
A lot can still be done with more cache, better instructions like AVX at full speed, SMT boost, better threaded software, something like asynchronous compute, build in HBM, build in GPU, more memory speed, more bus speed, lower price....
Everything is a dead end if you look long enough into the future and so will the silicon replacement be when it arrives, but until that happens we can enjoy it until the next big thing arrives.
schmidtbag
Senior Member
Posts: 4699
Senior Member
Posts: 4699
Posted on: 11/28/2019 12:10 AM
A lot can still be done with more cache, better instructions like AVX at full speed, SMT boost, better threaded software, something like asynchronous compute, build in HBM, build in GPU, more memory speed, more bus speed, lower price....
Everything is a dead end if you look long enough into the future and so will the silicon replacement be when it arrives, but until that happens we can enjoy it until the next big thing arrives.
What you said only applies to a relatively small group of people. Catering to the minority doesn't make a company money. Most of the things you mentioned will not yield an all around improvement in most software. Of the ones that will, you either have to compromise performance elsewhere or are already being pushed to the limits of physics. Remember, the products need to be mass producible so even if they could in theory be improved, it doesn't mean it'll be cost effective to do so. That's why monolithic dies with 18+ cores are so expensive, even though it's overall a better approach than chiplets.
Most of the things you mentioned require devs to actually implement them. Take a hard look at all programs you run and notice how little of them actually take advantage of modern instructions or subsystems. Clear Linux is a perfect example of the immense potential software has if devs bothered to use the very things you said would help.
So yes, there's plenty of ways you could improve x86 but none of it matters if you want to retain good performance with old software and if devs don't adapt (and most of them won't). Both Intel and AMD have tried to improve x86 and it takes years until anyone decides to take advantage of what they offer. Why do you think AMD has been so slow with AVX for example? They know nobody is going to use it, even though it offers tremendous power.
A lot can still be done with more cache, better instructions like AVX at full speed, SMT boost, better threaded software, something like asynchronous compute, build in HBM, build in GPU, more memory speed, more bus speed, lower price....
Everything is a dead end if you look long enough into the future and so will the silicon replacement be when it arrives, but until that happens we can enjoy it until the next big thing arrives.
What you said only applies to a relatively small group of people. Catering to the minority doesn't make a company money. Most of the things you mentioned will not yield an all around improvement in most software. Of the ones that will, you either have to compromise performance elsewhere or are already being pushed to the limits of physics. Remember, the products need to be mass producible so even if they could in theory be improved, it doesn't mean it'll be cost effective to do so. That's why monolithic dies with 18+ cores are so expensive, even though it's overall a better approach than chiplets.
Most of the things you mentioned require devs to actually implement them. Take a hard look at all programs you run and notice how little of them actually take advantage of modern instructions or subsystems. Clear Linux is a perfect example of the immense potential software has if devs bothered to use the very things you said would help.
So yes, there's plenty of ways you could improve x86 but none of it matters if you want to retain good performance with old software and if devs don't adapt (and most of them won't). Both Intel and AMD have tried to improve x86 and it takes years until anyone decides to take advantage of what they offer. Why do you think AMD has been so slow with AVX for example? They know nobody is going to use it, even though it offers tremendous power.
fry178
Senior Member
Posts: 1365
Senior Member
Posts: 1365
Posted on: 11/28/2019 02:02 AM
@TLD LARS
doesnt even always have to be faster clocks.
e.g. if "efficiency" goes up, you can gain enough not to have to deal with higher speeds to see perf increase.
one reason why you dont always have to increase vram bandwidth vs previous gens.
@TLD LARS
doesnt even always have to be faster clocks.
e.g. if "efficiency" goes up, you can gain enough not to have to deal with higher speeds to see perf increase.
one reason why you dont always have to increase vram bandwidth vs previous gens.
user1
Senior Member
Posts: 1465
Senior Member
Posts: 1465
Posted on: 11/28/2019 02:19 AM
There hasn't been a "true" cisc x86 cpu for a very long time, all modern x86 cpus use a decoder to break most instructions up into uops and combine some instructions into macro-ops , there is plenty of room for innovation on x86, The instruction set is not really a limiting factor.
Its the patent hell thats the problem.
I didn't say x86 is dead, I said it's at a dead end. I basically hinted before that x86 isn't going anywhere
There hasn't been a "true" cisc x86 cpu for a very long time, all modern x86 cpus use a decoder to break most instructions up into uops and combine some instructions into macro-ops , there is plenty of room for innovation on x86, The instruction set is not really a limiting factor.
Its the patent hell thats the problem.
Carfax
Senior Member
Posts: 2678
Senior Member
Posts: 2678
Posted on: 11/28/2019 12:40 PM
I agree Intel will come back from this, but I don't at all think this is going to be C2D all over again.
For one thing, Intel's progress with 10nm has been delayed by several years, and they already seem to be giving up on that and moving smaller since by the time they complete 10nm, it'll be already be obsolete. To my understanding, architectures need to be optimized per-node, so, every month Intel delays something <=10nm, the more time they're buying AMD to release something better.
Funny you should mention this, because last month Intel has finally begun ramping up its 10nm production to high volume for the first time.
They've already been shipping mobile parts for several months, but now they will be producing server grade CPUs and GPUs on their 10nm+ process.
But here's the more important issue we have to accept: x86 as we know it is at a dead end.
This has been the case for several decades already. As user1 said, there are no true x86 CPUs in production. Today's variants are all hybrids.
We're practically at the limits of silicon transistors, and despite how vastly different Intel and AMD have their architectures, they both have roughly the same IPC; the real-world performance differences are actually quite minimal, and can be narrowed down to things like cache. We can keep adding more cores, but most applications don't benefit from that and never will. Whatever Intel supersedes their Core i# series with, the architecture is going to have a very minimal per-core IPC improvement. I'm sure it'll have a vastly superior HT and it'll have more cores for a lower price, but otherwise I don't see how it can handily outperform Zen without making compromises.
Sunnycove core aka Ice Lake has a 18% average increase in IPC over Skylake, and even more for FP/SIMD. Zen 3 is also rumored to have a significant IPC increase over Zen 2.
Point is, there is plenty of performance to be had on the table and it won't be stopping anytime soon.
Bulldozer wasn't anywhere near as bad of an architecture as people made it out to be, but the problem is you had to write something for that architecture in order to tap into its true potential. Nobody was going to do that for AMD.
Bulldozer was God awful. They sacrificed far too much single thread performance to make it viable against Intel's Core series.
So, even though Intel has the money and resources to create the best architecture x86 could ever be, they won't do that because that means current software is likely to take a performance hit, and that is not how you sell a product. Regressions for the sake of a better future is never acceptable to consumer products.
This is exactly what Sapphire Rapids is supposed to offer. Supposedly it will be more of a clean break from the restraints of contemporary x86-64 designs.
I agree Intel will come back from this, but I don't at all think this is going to be C2D all over again.
For one thing, Intel's progress with 10nm has been delayed by several years, and they already seem to be giving up on that and moving smaller since by the time they complete 10nm, it'll be already be obsolete. To my understanding, architectures need to be optimized per-node, so, every month Intel delays something <=10nm, the more time they're buying AMD to release something better.
Funny you should mention this, because last month Intel has finally begun ramping up its 10nm production to high volume for the first time.
They've already been shipping mobile parts for several months, but now they will be producing server grade CPUs and GPUs on their 10nm+ process.
But here's the more important issue we have to accept: x86 as we know it is at a dead end.
This has been the case for several decades already. As user1 said, there are no true x86 CPUs in production. Today's variants are all hybrids.
We're practically at the limits of silicon transistors, and despite how vastly different Intel and AMD have their architectures, they both have roughly the same IPC; the real-world performance differences are actually quite minimal, and can be narrowed down to things like cache. We can keep adding more cores, but most applications don't benefit from that and never will. Whatever Intel supersedes their Core i# series with, the architecture is going to have a very minimal per-core IPC improvement. I'm sure it'll have a vastly superior HT and it'll have more cores for a lower price, but otherwise I don't see how it can handily outperform Zen without making compromises.
Sunnycove core aka Ice Lake has a 18% average increase in IPC over Skylake, and even more for FP/SIMD. Zen 3 is also rumored to have a significant IPC increase over Zen 2.
Point is, there is plenty of performance to be had on the table and it won't be stopping anytime soon.
Bulldozer wasn't anywhere near as bad of an architecture as people made it out to be, but the problem is you had to write something for that architecture in order to tap into its true potential. Nobody was going to do that for AMD.
Bulldozer was God awful. They sacrificed far too much single thread performance to make it viable against Intel's Core series.
So, even though Intel has the money and resources to create the best architecture x86 could ever be, they won't do that because that means current software is likely to take a performance hit, and that is not how you sell a product. Regressions for the sake of a better future is never acceptable to consumer products.
This is exactly what Sapphire Rapids is supposed to offer. Supposedly it will be more of a clean break from the restraints of contemporary x86-64 designs.
JethroTu11
Member
Posts: 26
Member
Posts: 26
Posted on: 11/28/2019 04:39 PM
$979 ?...
https://www.amazon.co.uk/dp/B07ZQN3QRR more like £1215.98, or $1568.49
And it's Amazon itself, not some scammer trying to make a quick buck.
But of course, it might drop a bit as they become available everywhere.
I'm glad somebody mentioned this. I've been skeptical that people could find these cpus for the price Intel has quoted.
How long will it take before people can actually buy this cpu for $979? It took many weeks if not months before I could buy a 3900X if I wanted one. If I wanted a new Threadripper or 3950X, I can't buy one at the moment. Now I wonder, could I get a 9900K for $500 if I wanted one? I never checked their availability or price.
$979 ?...
https://www.amazon.co.uk/dp/B07ZQN3QRR more like £1215.98, or $1568.49
And it's Amazon itself, not some scammer trying to make a quick buck.
But of course, it might drop a bit as they become available everywhere.
I'm glad somebody mentioned this. I've been skeptical that people could find these cpus for the price Intel has quoted.
How long will it take before people can actually buy this cpu for $979? It took many weeks if not months before I could buy a 3900X if I wanted one. If I wanted a new Threadripper or 3950X, I can't buy one at the moment. Now I wonder, could I get a 9900K for $500 if I wanted one? I never checked their availability or price.
TLD LARS
Senior Member
Posts: 130
Senior Member
Posts: 130
Posted on: 11/28/2019 08:26 PM
If someone invents the next new silicon replacement, it will still take years before it will find its way to the rest of the pc, Just like Intel went back to a older generation fabrication for the chipset, because of cost and machine time.
So the CPU or GPU will just run away in frequency to give better singlecore or more speed in sloppy 4-8 core programs, the silicon memory, chipset, storage will still limit the pc for years after the CPU changes to a new material.
The AMD AVX problem is not 100% AMDs fault, stuff like Matlab does not even support AMD AVX it reverts to a 10 years old protocol, either because of laziness or on purpose.
HBM on chip cache and faster PCI storage could remove the need for DDR memory completely.
SLI and Crossfire could be reinvented and fixed for a lot more performance.
If the next chip material is invented and gives us 10ghz, developers will still be lazy about it and not able to feed the CPU.
So yes, there's plenty of ways you could improve x86 but none of it matters if you want to retain good performance with old software and if devs don't adapt (and most of them won't)
If someone invents the next new silicon replacement, it will still take years before it will find its way to the rest of the pc, Just like Intel went back to a older generation fabrication for the chipset, because of cost and machine time.
So the CPU or GPU will just run away in frequency to give better singlecore or more speed in sloppy 4-8 core programs, the silicon memory, chipset, storage will still limit the pc for years after the CPU changes to a new material.
The AMD AVX problem is not 100% AMDs fault, stuff like Matlab does not even support AMD AVX it reverts to a 10 years old protocol, either because of laziness or on purpose.
HBM on chip cache and faster PCI storage could remove the need for DDR memory completely.
SLI and Crossfire could be reinvented and fixed for a lot more performance.
If the next chip material is invented and gives us 10ghz, developers will still be lazy about it and not able to feed the CPU.
sykozis
Senior Member
Posts: 21230
Senior Member
Posts: 21230
Posted on: 11/28/2019 08:45 PM
Go repeat that in an AMD GPU thread....where power draw is attacked constantly. Seems that power consumption only matters when it's an AMD product.
I wonder where are you from? In the developed world electricity been non issues for the last 50 years
Go repeat that in an AMD GPU thread....where power draw is attacked constantly. Seems that power consumption only matters when it's an AMD product.
schmidtbag
Senior Member
Posts: 4699
Senior Member
Posts: 4699
Posted on: 11/29/2019 12:20 AM
If someone invents the next new silicon replacement, it will still take years before it will find its way to the rest of the pc, Just like Intel went back to a older generation fabrication for the chipset, because of cost and machine time.
So the CPU or GPU will just run away in frequency to give better singlecore or more speed in sloppy 4-8 core programs, the silicon memory, chipset, storage will still limit the pc for years after the CPU changes to a new material.
Right, hence my point: there's not much that can be done about x86 that will satisfy a wide audience. Intel can probably one-up AMD, but not by a substantial margin in everyday tasks.
HBM on chip cache and faster PCI storage could remove the need for DDR memory completely.
It could, but I don't think there will be too many people agreeable with the idea of an expensive socketed CPU with a fixed amount of memory.
On the note of faster PCIe though: stuff like ReRAM (keyword here is like) could obsolete the need of RAM entirely. If storage can be made as fast as modern SDRAM, there's no point in loading anything into memory, you could just load the software directly from the disk. Keep in mind the whole reason RAM exists is to quickly feed the CPU data. So, if your storage is as fast as RAM, you don't need it anymore.
However, none of that is really an evolution of x86, just an evolution in computing. Keep in mind, binary computers have a tremendous amount of new potential, but as far as I'm concerned, x86 is realistically almost as good as it's ever going to get.
SLI and Crossfire could be reinvented and fixed for a lot more performance.
Absolutely, but again, that's not something x86 is responsible for.
If the next chip material is invented and gives us 10ghz, developers will still be lazy about it and not able to feed the CPU.
Yes, I very much agree. However, I don't necessarily see that as a bad thing. To me, CPUs should be used for highly complex serial/linear computations. I don't care for applications becoming more multi-threaded, I think they need to be ported to OpenCL or CUDA instead. GPUs offer so much compute power and they're not that hard to program for.
There hasn't been a "true" cisc x86 cpu for a very long time, all modern x86 cpus use a decoder to break most instructions up into uops and combine some instructions into macro-ops , there is plenty of room for innovation on x86, The instruction set is not really a limiting factor.
What difference does any of that make? They're still backward compatible with software from the 90s, and that's kinda the point of everything I've been saying: what will cause x86 to stagnate is an attempt to retain that backward compatibility (which also means preventing performance regressions).
Also, I've said several times already that of course there is room to innovate and improve x86, but devs need to actually implement them. There are dozens of instruction sets available that nobody uses. Many of these instructions have actually been abandoned because nobody used them and it's too costly to maintain the hardware that operates them. rdrand is a good example of an instruction that hardly anyone uses, and has been around for years. Apparently, only Destiny 2 and systemd used it, and we only discovered that because of how the instruction broke in Zen2.
I feel like a broken record player here. I really don't know how to emphasize that theoretical performance improvements does absolutely nothing to improve most software out there, especially software that has already been released.
If someone invents the next new silicon replacement, it will still take years before it will find its way to the rest of the pc, Just like Intel went back to a older generation fabrication for the chipset, because of cost and machine time.
So the CPU or GPU will just run away in frequency to give better singlecore or more speed in sloppy 4-8 core programs, the silicon memory, chipset, storage will still limit the pc for years after the CPU changes to a new material.
Right, hence my point: there's not much that can be done about x86 that will satisfy a wide audience. Intel can probably one-up AMD, but not by a substantial margin in everyday tasks.
HBM on chip cache and faster PCI storage could remove the need for DDR memory completely.
It could, but I don't think there will be too many people agreeable with the idea of an expensive socketed CPU with a fixed amount of memory.
On the note of faster PCIe though: stuff like ReRAM (keyword here is like) could obsolete the need of RAM entirely. If storage can be made as fast as modern SDRAM, there's no point in loading anything into memory, you could just load the software directly from the disk. Keep in mind the whole reason RAM exists is to quickly feed the CPU data. So, if your storage is as fast as RAM, you don't need it anymore.
However, none of that is really an evolution of x86, just an evolution in computing. Keep in mind, binary computers have a tremendous amount of new potential, but as far as I'm concerned, x86 is realistically almost as good as it's ever going to get.
SLI and Crossfire could be reinvented and fixed for a lot more performance.
Absolutely, but again, that's not something x86 is responsible for.
If the next chip material is invented and gives us 10ghz, developers will still be lazy about it and not able to feed the CPU.
Yes, I very much agree. However, I don't necessarily see that as a bad thing. To me, CPUs should be used for highly complex serial/linear computations. I don't care for applications becoming more multi-threaded, I think they need to be ported to OpenCL or CUDA instead. GPUs offer so much compute power and they're not that hard to program for.
There hasn't been a "true" cisc x86 cpu for a very long time, all modern x86 cpus use a decoder to break most instructions up into uops and combine some instructions into macro-ops , there is plenty of room for innovation on x86, The instruction set is not really a limiting factor.
What difference does any of that make? They're still backward compatible with software from the 90s, and that's kinda the point of everything I've been saying: what will cause x86 to stagnate is an attempt to retain that backward compatibility (which also means preventing performance regressions).
Also, I've said several times already that of course there is room to innovate and improve x86, but devs need to actually implement them. There are dozens of instruction sets available that nobody uses. Many of these instructions have actually been abandoned because nobody used them and it's too costly to maintain the hardware that operates them. rdrand is a good example of an instruction that hardly anyone uses, and has been around for years. Apparently, only Destiny 2 and systemd used it, and we only discovered that because of how the instruction broke in Zen2.
I feel like a broken record player here. I really don't know how to emphasize that theoretical performance improvements does absolutely nothing to improve most software out there, especially software that has already been released.
schmidtbag
Senior Member
Posts: 4699
Senior Member
Posts: 4699
Posted on: 11/29/2019 12:42 AM
Funny you should mention this, because last month Intel has finally begun ramping up its 10nm production to high volume for the first time.
They've already been shipping mobile parts for several months, but now they will be producing server grade CPUs and GPUs on their 10nm+ process.
I'm aware... that doesn't change my point. Intel has already started looking beyond 10nm.
This has been the case for several decades already. As user1 said, there are no true x86 CPUs in production. Today's variants are all hybrids.
I'm talking about binary compatibility here, not the literal 80386 architecture. That being said, x86 was steadily improving up until Skylake. That's pretty much when it peaked in terms of per-core IPC.
Sunnycove core aka Ice Lake has a 18% average increase in IPC over Skylake, and even more for FP/SIMD. Zen 3 is also rumored to have a significant IPC increase over Zen 2.
Considering everything else I've been saying, an 18% improvement doesn't mean very much by itself. Like I said before, we're at a point where that kind of performance means something else must be sacrificed, such as lower clocks, higher latency, higher TDP, requires developer implementation, higher price tag, and so on. No, I'm not saying all of those things will happen, they're just a list of some possibilities. If Intel accomplishes an overall 18% IPC improvement in a wide range of tests, feel free to come back here and rub in my face that I'm wrong.
As for Zen3, that's a little different. Seems to me Zen is suffering some bottleneck and latency issues, so any IPC improvements it gets will be caused by reducing those issues. In other words, I don't think Zen3 is necessarily going to get a whole lot "faster", it's just going to be closer to reaching its true potential.
Bulldozer was God awful. They sacrificed far too much single thread performance to make it viable against Intel's Core series.
Seems you completely ignored the reason why I brought up Bulldozer...
This is exactly what Sapphire Rapids is supposed to offer. Supposedly it will be more of a clean break from the restraints of contemporary x86-64 designs.
Supposed to offer what? Being a clean break doesn't change my point. Zen was a clean break and today, its IPC is barely better than Intel's. I have no doubt Sapphire Rapids will offer substantial improvements, but like I said for the bajillionth time: some of those improvements will involve compromises, and some of them will need developers to actually use them. In most software, I'm sure Sapphire Rapids won't yield impressively better results.
Funny you should mention this, because last month Intel has finally begun ramping up its 10nm production to high volume for the first time.
They've already been shipping mobile parts for several months, but now they will be producing server grade CPUs and GPUs on their 10nm+ process.
I'm aware... that doesn't change my point. Intel has already started looking beyond 10nm.
This has been the case for several decades already. As user1 said, there are no true x86 CPUs in production. Today's variants are all hybrids.
I'm talking about binary compatibility here, not the literal 80386 architecture. That being said, x86 was steadily improving up until Skylake. That's pretty much when it peaked in terms of per-core IPC.
Sunnycove core aka Ice Lake has a 18% average increase in IPC over Skylake, and even more for FP/SIMD. Zen 3 is also rumored to have a significant IPC increase over Zen 2.
Considering everything else I've been saying, an 18% improvement doesn't mean very much by itself. Like I said before, we're at a point where that kind of performance means something else must be sacrificed, such as lower clocks, higher latency, higher TDP, requires developer implementation, higher price tag, and so on. No, I'm not saying all of those things will happen, they're just a list of some possibilities. If Intel accomplishes an overall 18% IPC improvement in a wide range of tests, feel free to come back here and rub in my face that I'm wrong.
As for Zen3, that's a little different. Seems to me Zen is suffering some bottleneck and latency issues, so any IPC improvements it gets will be caused by reducing those issues. In other words, I don't think Zen3 is necessarily going to get a whole lot "faster", it's just going to be closer to reaching its true potential.
Bulldozer was God awful. They sacrificed far too much single thread performance to make it viable against Intel's Core series.
Seems you completely ignored the reason why I brought up Bulldozer...
This is exactly what Sapphire Rapids is supposed to offer. Supposedly it will be more of a clean break from the restraints of contemporary x86-64 designs.
Supposed to offer what? Being a clean break doesn't change my point. Zen was a clean break and today, its IPC is barely better than Intel's. I have no doubt Sapphire Rapids will offer substantial improvements, but like I said for the bajillionth time: some of those improvements will involve compromises, and some of them will need developers to actually use them. In most software, I'm sure Sapphire Rapids won't yield impressively better results.
user1
Senior Member
Posts: 1465
Senior Member
Posts: 1465
Posted on: 11/29/2019 01:00 AM
What difference does any of that make? They're still backward compatible with software from the 90s, and that's kinda the point of everything I've been saying: what will cause x86 to stagnate is an attempt to retain that backward compatibility (which also means preventing performance regressions).
Also, I've said several times already that of course there is room to innovate and improve x86, but devs need to actually implement them. There are dozens of instruction sets available that nobody uses. Many of these instructions have actually been abandoned because nobody used them and it's too costly to maintain the hardware that operates them. rdrand is a good example of an instruction that hardly anyone uses, and has been around for years. Apparently, only Destiny 2 and systemd used it, and we only discovered that because of how the instruction broke in Zen2.
I feel like a broken record player here. I really don't know how to emphasize that theoretical performance improvements does absolutely nothing to improve most software out there, especially software that has already been released.
my point is that the cost of "legacy" instruction support is not as important as you think, because the instructions are essentially translated to a risc-like anyway, the decoder doesn't necessarily need to change all that much, even if the core is mostly redesigned.
Intel has even done a pure emulation implementation of x86 on some of its ill-fated itanium cpus, that worked okish.
and you are mistaken about the rdrand, its a Newer instruction , chips older than ivy bridge lack it all together, it just so happens that it was broken zen2 , later patched in the agesa. I should also mention it is by no means a very important instruction, its just an optimization really, depending on it is silly to begin with.
old instructions breaking can be a problem, but a very minor one, since if the instruction being used is super old, it can be emulated quite easily on modern cpus, and you probably wouldn't notice the difference performance wise.
trust me if there is anything stifling performance in x86 land, its the patents, not the technology.
What difference does any of that make? They're still backward compatible with software from the 90s, and that's kinda the point of everything I've been saying: what will cause x86 to stagnate is an attempt to retain that backward compatibility (which also means preventing performance regressions).
Also, I've said several times already that of course there is room to innovate and improve x86, but devs need to actually implement them. There are dozens of instruction sets available that nobody uses. Many of these instructions have actually been abandoned because nobody used them and it's too costly to maintain the hardware that operates them. rdrand is a good example of an instruction that hardly anyone uses, and has been around for years. Apparently, only Destiny 2 and systemd used it, and we only discovered that because of how the instruction broke in Zen2.
I feel like a broken record player here. I really don't know how to emphasize that theoretical performance improvements does absolutely nothing to improve most software out there, especially software that has already been released.
my point is that the cost of "legacy" instruction support is not as important as you think, because the instructions are essentially translated to a risc-like anyway, the decoder doesn't necessarily need to change all that much, even if the core is mostly redesigned.
Intel has even done a pure emulation implementation of x86 on some of its ill-fated itanium cpus, that worked okish.
and you are mistaken about the rdrand, its a Newer instruction , chips older than ivy bridge lack it all together, it just so happens that it was broken zen2 , later patched in the agesa. I should also mention it is by no means a very important instruction, its just an optimization really, depending on it is silly to begin with.
old instructions breaking can be a problem, but a very minor one, since if the instruction being used is super old, it can be emulated quite easily on modern cpus, and you probably wouldn't notice the difference performance wise.
trust me if there is anything stifling performance in x86 land, its the patents, not the technology.
D3M1G0D
Senior Member
Posts: 2071
Senior Member
Posts: 2071
Posted on: 11/29/2019 03:41 AM
@schmidtbag A toaster would be enough for the average person - smartphone, tablet or low-end laptop. The average Joe isn't going to benefit from a 5 GHz or 16-core CPU - that's for gamers, enthusiasts and professionals. This is what the whole "post-PC" thing was all about - the typical person doesn't need a PC anymore. If there is a benefit to improvements in x86 going forward for the average user, it would be in power efficiency - more efficient / longer-lasting laptops. Otherwise, advancements will be solely for power users and businesses.
@schmidtbag A toaster would be enough for the average person - smartphone, tablet or low-end laptop. The average Joe isn't going to benefit from a 5 GHz or 16-core CPU - that's for gamers, enthusiasts and professionals. This is what the whole "post-PC" thing was all about - the typical person doesn't need a PC anymore. If there is a benefit to improvements in x86 going forward for the average user, it would be in power efficiency - more efficient / longer-lasting laptops. Otherwise, advancements will be solely for power users and businesses.
sykozis
Senior Member
Posts: 21230
Senior Member
Posts: 21230
Posted on: 11/29/2019 04:26 AM
If the average user still wants a PC, they can easily get by on a Chromebook.....
@schmidtbag A toaster would be enough for the average person - smartphone, tablet or low-end laptop. The average Joe isn't going to benefit from a 5 GHz or 16-core CPU - that's for gamers, enthusiasts and professionals. This is what the whole "post-PC" thing was all about - the typical person doesn't need a PC anymore. If there is a benefit to improvements in x86 going forward for the average user, it would be in power efficiency - more efficient / longer-lasting laptops. Otherwise, advancements will be solely for power users and businesses.
If the average user still wants a PC, they can easily get by on a Chromebook.....
schmidtbag
Senior Member
Posts: 4699
Senior Member
Posts: 4699
Posted on: 11/29/2019 04:44 PM
my point is that the cost of "legacy" instruction support is not as important as you think, because the instructions are essentially translated to a risc-like anyway, the decoder doesn't necessarily need to change all that much, even if the core is mostly redesigned.
Intel has even done a pure emulation implementation of x86 on some of its ill-fated itanium cpus, that worked okish.
I don't get it... how do you not see the issue revolving around binary compatibility? It is everything to the vast majority of consumers out there, and even a substantial amount of servers. Vista, Windows RT, Windows CE, and all 64-bit versions of Windows prior to 7 were all unpopular because of broken software compatibility. Of those things I mentioned, only Vista caused breakages strictly due to software. Even the ARM support for Windows 10 isn't so great, because the x86 compatibility layer is very CPU-taxing on an architecture not known for high performance.
Y'know why Apple was able to get away with their transition from PPC to Intel? Because they had a competent compatibility layer that allowed people to run their old software smoothly.
As a Linux enthusiast, pretty much the #1 reason why Windows users don't switch is because of binary compatibility. A Linux experience is actually pretty great regardless of which CPU architecture you use, and it has compatibility layers for just about any architecture too. But Linux's cross-compatibility doesn't mean anything to Windows users, because their software isn't so "graceful".
The takeaway from all of this is whether or not modern AMD and Intel CPUs are "true" x86 is completely irrelevant. What matters is software compatibility, and the vast majority of userland software that people actually care about is for x86. Intel and AMD are not in a position to break that compatibility with their CPUs, and there's very little they can do to improve the performance for x86 software in a way that developers will actually use.
and you are mistaken about the rdrand, its a Newer instruction , chips older than ivy bridge lack it all together, it just so happens that it was broken zen2 , later patched in the agesa. I should also mention it is by no means a very important instruction, its just an optimization really, depending on it is silly to begin with.
Uh... how am I mistaken? Ivy Bridge has been around for several years... But you just proved my point anyway: the fact AMD didn't even notice it was broken when they released their product shows how unused it was. You also said yourself it wasn't an important optimization. That's literally the synopsis of everything I've been trying to say: Intel and AMD has plenty of room to improve their architectures but hardly anybody is ever going to bother to use such things. Literally just 2 pieces of software were known to use rdrand after all these years. That's a pathetically small number for an architectural improvement. rdrand is not hard to use, so it's far more unrealistic to expect devs to use something more complex.
So to reiterate:
Adding instructions is futile to improve a CPU if devs don't use them, and 99% of software out there proves they won't.
Also last I checked, the AGESA update just simply disabled the instruction entirely, which brings software that depend on it to use a software-based alternative.
trust me if there is anything stifling performance in x86 land, its the patents, not the technology.
Patents of what? I don't see anything Intel has that AMD doesn't or vise versa that would offer either of them a substantial performance gain.
@schmidtbag A toaster would be enough for the average person - smartphone, tablet or low-end laptop. The average Joe isn't going to benefit from a 5 GHz or 16-core CPU - that's for gamers, enthusiasts and professionals. This is what the whole "post-PC" thing was all about - the typical person doesn't need a PC anymore. If there is a benefit to improvements in x86 going forward for the average user, it would be in power efficiency - more efficient / longer-lasting laptops. Otherwise, advancements will be solely for power users and businesses.
I agree with pretty much all of that. But that doesn't change the fact that x86 doesn't have much room to grow in real-world applications. Most performance enhancements for future software will most likely be done in a GPU.
my point is that the cost of "legacy" instruction support is not as important as you think, because the instructions are essentially translated to a risc-like anyway, the decoder doesn't necessarily need to change all that much, even if the core is mostly redesigned.
Intel has even done a pure emulation implementation of x86 on some of its ill-fated itanium cpus, that worked okish.
I don't get it... how do you not see the issue revolving around binary compatibility? It is everything to the vast majority of consumers out there, and even a substantial amount of servers. Vista, Windows RT, Windows CE, and all 64-bit versions of Windows prior to 7 were all unpopular because of broken software compatibility. Of those things I mentioned, only Vista caused breakages strictly due to software. Even the ARM support for Windows 10 isn't so great, because the x86 compatibility layer is very CPU-taxing on an architecture not known for high performance.
Y'know why Apple was able to get away with their transition from PPC to Intel? Because they had a competent compatibility layer that allowed people to run their old software smoothly.
As a Linux enthusiast, pretty much the #1 reason why Windows users don't switch is because of binary compatibility. A Linux experience is actually pretty great regardless of which CPU architecture you use, and it has compatibility layers for just about any architecture too. But Linux's cross-compatibility doesn't mean anything to Windows users, because their software isn't so "graceful".
The takeaway from all of this is whether or not modern AMD and Intel CPUs are "true" x86 is completely irrelevant. What matters is software compatibility, and the vast majority of userland software that people actually care about is for x86. Intel and AMD are not in a position to break that compatibility with their CPUs, and there's very little they can do to improve the performance for x86 software in a way that developers will actually use.
and you are mistaken about the rdrand, its a Newer instruction , chips older than ivy bridge lack it all together, it just so happens that it was broken zen2 , later patched in the agesa. I should also mention it is by no means a very important instruction, its just an optimization really, depending on it is silly to begin with.
Uh... how am I mistaken? Ivy Bridge has been around for several years... But you just proved my point anyway: the fact AMD didn't even notice it was broken when they released their product shows how unused it was. You also said yourself it wasn't an important optimization. That's literally the synopsis of everything I've been trying to say: Intel and AMD has plenty of room to improve their architectures but hardly anybody is ever going to bother to use such things. Literally just 2 pieces of software were known to use rdrand after all these years. That's a pathetically small number for an architectural improvement. rdrand is not hard to use, so it's far more unrealistic to expect devs to use something more complex.
So to reiterate:
Adding instructions is futile to improve a CPU if devs don't use them, and 99% of software out there proves they won't.
Also last I checked, the AGESA update just simply disabled the instruction entirely, which brings software that depend on it to use a software-based alternative.
trust me if there is anything stifling performance in x86 land, its the patents, not the technology.
Patents of what? I don't see anything Intel has that AMD doesn't or vise versa that would offer either of them a substantial performance gain.
@schmidtbag A toaster would be enough for the average person - smartphone, tablet or low-end laptop. The average Joe isn't going to benefit from a 5 GHz or 16-core CPU - that's for gamers, enthusiasts and professionals. This is what the whole "post-PC" thing was all about - the typical person doesn't need a PC anymore. If there is a benefit to improvements in x86 going forward for the average user, it would be in power efficiency - more efficient / longer-lasting laptops. Otherwise, advancements will be solely for power users and businesses.
I agree with pretty much all of that. But that doesn't change the fact that x86 doesn't have much room to grow in real-world applications. Most performance enhancements for future software will most likely be done in a GPU.
MegaFalloutFan
Senior Member
Posts: 707
Senior Member
Posts: 707
Posted on: 11/29/2019 06:39 PM
We are talking about CPUs here, not GPU
Go repeat that in an AMD GPU thread....where power draw is attacked constantly. Seems that power consumption only matters when it's an AMD product.
We are talking about CPUs here, not GPU
sykozis
Senior Member
Posts: 21230
Senior Member
Posts: 21230
Posted on: 11/30/2019 01:16 AM
If power consumption doesn't matter on a CPU, it shouldn't matter on a GPU either.
We are talking about CPUs here, not GPU
If power consumption doesn't matter on a CPU, it shouldn't matter on a GPU either.
user1
Senior Member
Posts: 1465
Senior Member
Posts: 1465
Posted on: 11/30/2019 01:19 AM
I don't get it... how do you not see the issue revolving around binary compatibility? It is everything to the vast majority of consumers out there, and even a substantial amount of servers. Vista, Windows RT, Windows CE, and all 64-bit versions of Windows prior to 7 were all unpopular because of broken software compatibility. Of those things I mentioned, only Vista caused breakages strictly due to software. Even the ARM support for Windows 10 isn't so great, because the x86 compatibility layer is very CPU-taxing on an architecture not known for high performance.
Y'know why Apple was able to get away with their transition from PPC to Intel? Because they had a competent compatibility layer that allowed people to run their old software smoothly.....
......The takeaway from all of this is whether or not modern AMD and Intel CPUs are "true" x86 is completely irrelevant. What matters is software compatibility, and the vast majority of userland software that people actually care about is for x86. Intel and AMD are not in a position to break that compatibility with their CPUs, and there's very little they can do to improve the performance for x86 software in a way that developers will actually use.
Uh... how am I mistaken? Ivy Bridge has been around for several years... But you just proved my point anyway: the fact AMD didn't even notice it was broken when they released their product shows how unused it was. You also said yourself it wasn't an important optimization. That's literally the synopsis of everything I've been trying to say: Intel and AMD has plenty of room to improve their architectures but hardly anybody is ever going to bother to use such things. Literally just 2 pieces of software were known to use rdrand after all these years. That's a pathetically small number for an architectural improvement. rdrand is not hard to use, so it's far more unrealistic to expect devs to use something more complex.
So to reiterate:
Adding instructions is futile to improve a CPU if devs don't use them, and 99% of software out there proves they won't.
Also last I checked, the AGESA update just simply disabled the instruction entirely, which brings software that depend on it to use a software-based alternative.
Patents of what? I don't see anything Intel has that AMD doesn't or vise versa that would offer either of them a substantial performance gain.
first of all, windows Software backwards compatibility has litterally nothing to with x86. That is a completely different game, cpus just generally dont change nearly as much as software can.
emulation has been done, with ok performance, especially now with recompliation techniques its much faster than it used to be, its no longer an order of magnitude slower. infact if you read about the itaniums, you know that intel's original hardware translation of ia32 to ia64 on early itaniums, is actually slower than their software emulation layer.
I dont know what time scale you operate on but rdrand is IMO a newer instruction since instructions are not added that frequently(once every 2 years? maybe less frequent than that for intel lately), and often do not even get compiler support for many years, so it is recent in this sense.
deprecating old instructions like 3dnow, does infact break compatibilty in a significant way, but rdrand is not one of those(at least it shouldn't be), and could be emulated with little issue.
People will use a newinstruction if they need it,the AVX512 instructions are very useful for certain workloads, so more people use it, its that simple.
RDrand can be useful too, but again its the market, frankly anyone that wants that kind of entropy knows that hw generators are security risk, so they dont use it, and im pretty sure the only reason destiny 2 actually used it was because ICC is very aggressive with optimizations.
so what do I mean by it is not that important?, It means that inessence the "silicon/developement burden" of maintaining hardware compatibility with old x86 instructions is not a significant factor or rather, the cost of ditching it is way higher than the cost to keep it, by the time some "real" breakage occurs (like deprecating say SSE2) , it probably wont matter(performance wise), is my point.
Individual x86 cores don't have much room to improve.
To stay on topic, this is main issue, its just not true, because again its not x86 anymore, so you could completely redesign the execution pipeline and maintain x86 compatibility as has been done several times.
AFAIK the new agesa does infact fix the breakage of the rdrand instruction on zen2, but amd did disable rdrand on applicable bulldozer apus.
Patents are relevant because cpus like , arm POWER, sparc, x86, ect have lots of overlap(some arm cpus actually have the an equivalent meltdown bug for instance), and so when amd or intel want to implement a certain feature, they need a team of lawyers to go over the implementation to make sure it doesn't violate somebody else's patent or license it from them , its really a mess frankly.
Depsite intel/amd's crosslicensing deal, there is a tonne of litigation going on all the time of IPs.
No need to splits hairs over the minor details, point is there are bigger problems than the ISA itself holding cpus back.
I don't get it... how do you not see the issue revolving around binary compatibility? It is everything to the vast majority of consumers out there, and even a substantial amount of servers. Vista, Windows RT, Windows CE, and all 64-bit versions of Windows prior to 7 were all unpopular because of broken software compatibility. Of those things I mentioned, only Vista caused breakages strictly due to software. Even the ARM support for Windows 10 isn't so great, because the x86 compatibility layer is very CPU-taxing on an architecture not known for high performance.
Y'know why Apple was able to get away with their transition from PPC to Intel? Because they had a competent compatibility layer that allowed people to run their old software smoothly.....
......The takeaway from all of this is whether or not modern AMD and Intel CPUs are "true" x86 is completely irrelevant. What matters is software compatibility, and the vast majority of userland software that people actually care about is for x86. Intel and AMD are not in a position to break that compatibility with their CPUs, and there's very little they can do to improve the performance for x86 software in a way that developers will actually use.
Uh... how am I mistaken? Ivy Bridge has been around for several years... But you just proved my point anyway: the fact AMD didn't even notice it was broken when they released their product shows how unused it was. You also said yourself it wasn't an important optimization. That's literally the synopsis of everything I've been trying to say: Intel and AMD has plenty of room to improve their architectures but hardly anybody is ever going to bother to use such things. Literally just 2 pieces of software were known to use rdrand after all these years. That's a pathetically small number for an architectural improvement. rdrand is not hard to use, so it's far more unrealistic to expect devs to use something more complex.
So to reiterate:
Adding instructions is futile to improve a CPU if devs don't use them, and 99% of software out there proves they won't.
Also last I checked, the AGESA update just simply disabled the instruction entirely, which brings software that depend on it to use a software-based alternative.
Patents of what? I don't see anything Intel has that AMD doesn't or vise versa that would offer either of them a substantial performance gain.
first of all, windows Software backwards compatibility has litterally nothing to with x86. That is a completely different game, cpus just generally dont change nearly as much as software can.
emulation has been done, with ok performance, especially now with recompliation techniques its much faster than it used to be, its no longer an order of magnitude slower. infact if you read about the itaniums, you know that intel's original hardware translation of ia32 to ia64 on early itaniums, is actually slower than their software emulation layer.
I dont know what time scale you operate on but rdrand is IMO a newer instruction since instructions are not added that frequently(once every 2 years? maybe less frequent than that for intel lately), and often do not even get compiler support for many years, so it is recent in this sense.
deprecating old instructions like 3dnow, does infact break compatibilty in a significant way, but rdrand is not one of those(at least it shouldn't be), and could be emulated with little issue.
People will use a newinstruction if they need it,the AVX512 instructions are very useful for certain workloads, so more people use it, its that simple.
RDrand can be useful too, but again its the market, frankly anyone that wants that kind of entropy knows that hw generators are security risk, so they dont use it, and im pretty sure the only reason destiny 2 actually used it was because ICC is very aggressive with optimizations.
so what do I mean by it is not that important?, It means that inessence the "silicon/developement burden" of maintaining hardware compatibility with old x86 instructions is not a significant factor or rather, the cost of ditching it is way higher than the cost to keep it, by the time some "real" breakage occurs (like deprecating say SSE2) , it probably wont matter(performance wise), is my point.
Individual x86 cores don't have much room to improve.
To stay on topic, this is main issue, its just not true, because again its not x86 anymore, so you could completely redesign the execution pipeline and maintain x86 compatibility as has been done several times.
AFAIK the new agesa does infact fix the breakage of the rdrand instruction on zen2, but amd did disable rdrand on applicable bulldozer apus.
Patents are relevant because cpus like , arm POWER, sparc, x86, ect have lots of overlap(some arm cpus actually have the an equivalent meltdown bug for instance), and so when amd or intel want to implement a certain feature, they need a team of lawyers to go over the implementation to make sure it doesn't violate somebody else's patent or license it from them , its really a mess frankly.
Depsite intel/amd's crosslicensing deal, there is a tonne of litigation going on all the time of IPs.
No need to splits hairs over the minor details, point is there are bigger problems than the ISA itself holding cpus back.
MegaFalloutFan
Senior Member
Posts: 707
Senior Member
Posts: 707
Posted on: 11/30/2019 02:00 AM
The reason people dont like high power consumption on GPU is that GPUs are much hotter then CPUs and heat up the whole case and even the room.
I never heard of CPU heating up the room around me, but GPU, well i had this experience myself, i even enjoyed it during the winter.
Also, this Intel power consumption on Stock is normal, much less then TR2 from last year and on par with TR3, overclocking is optional, but even when overclocked 580W is not bad, especially compared vs last years threadrippers
If power consumption doesn't matter on a CPU, it shouldn't matter on a GPU either.
The reason people dont like high power consumption on GPU is that GPUs are much hotter then CPUs and heat up the whole case and even the room.
I never heard of CPU heating up the room around me, but GPU, well i had this experience myself, i even enjoyed it during the winter.
Also, this Intel power consumption on Stock is normal, much less then TR2 from last year and on par with TR3, overclocking is optional, but even when overclocked 580W is not bad, especially compared vs last years threadrippers
schmidtbag
Senior Member
Posts: 4699
Senior Member
Posts: 4699
Posted on: 11/30/2019 05:39 AM
So... what exactly are you arguing about at this point? Because retaining software compatibility has been my entire argument this whole time.
I'm aware emulation can be done with decent performance. Decent emulation is why I pointed out Rosetta (Apple's method of getting PPC programs to work on Intel Macs). So, what exactly is your point here? Or is it related to rdrand being emulated? Because that doesn't really have much of an impact on CPU load - the point of rdrand was to give "better" random numbers.
Ivy Bridge is from 2012... 7 years is a LONG time for computers, even with Intel slowing R&D thanks to Bulldozer. rdrand in particular was added to compilers since at least December of 2012. So, it's definitely not new anymore. And that goes back to my original point: this is just one of dozens of instructions that nobody bothers to use. You can keep adding all the instructions you want, but performance won't improve until devs use them in their software.
And yet, there are so many applications that could use AVX (just in general, not even 512) or other nice modern instructions like the SSE4 family, but they don't. Take a look at benchmarks of Clear Linux to see how much devs are slacking (that whole distro is optimized to take advantage of various instructions). The amount of untapped performance you can get in a modern Intel or AMD CPU is absolutely insane. But how do you get devs to take this stuff seriously? Until they do, any additional instructions added to CPUs is a wasted effort.
Yes, maintaining it isn't that difficult. Preventing it from regressing without people noticing is. That's why x86 is heading toward a dead-end. There's no clear path to improve it:
* You can't depend on devs to use new instructions
* You can't make people's existing software run slower; modern optimizations can often cause this
* You can't break software compatibility without pissing people off
* We're near the limits of silicon transistors
I don't understand why you keep pointing that out. It doesn't change the underlying point. Despite how drastically different the execution pipeline is between modern Intel and AMD CPUs, they still perform roughly the same. You could also say the same about Athlon II and Core2. Intel could revamp the entire pipeline, but because of trying to retain x86 software compatibility, it isn't going to get a lot faster.
Makes sense.
first of all, windows Software backwards compatibility has litterally nothing to with x86. That is a completely different game, cpus just generally dont change nearly as much as software can.
So... what exactly are you arguing about at this point? Because retaining software compatibility has been my entire argument this whole time.
emulation has been done, with ok performance, especially now with recompliation techniques its much faster than it used to be, its no longer an order of magnitude slower. infact if you read about the itaniums, you know that intel's original hardware translation of ia32 to ia64 on early itaniums, is actually slower than their software emulation layer.
I'm aware emulation can be done with decent performance. Decent emulation is why I pointed out Rosetta (Apple's method of getting PPC programs to work on Intel Macs). So, what exactly is your point here? Or is it related to rdrand being emulated? Because that doesn't really have much of an impact on CPU load - the point of rdrand was to give "better" random numbers.
I dont know what time scale you operate on but rdrand is IMO a newer instruction since instructions are not added that frequently(once every 2 years? maybe less frequent than that for intel lately), and often do not even get compiler support for many years, so it is recent in this sense.
deprecating old instructions like 3dnow, does infact break compatibilty in a significant way, but rdrand is not one of those(at least it shouldn't be), and could be emulated with little issue.
deprecating old instructions like 3dnow, does infact break compatibilty in a significant way, but rdrand is not one of those(at least it shouldn't be), and could be emulated with little issue.
Ivy Bridge is from 2012... 7 years is a LONG time for computers, even with Intel slowing R&D thanks to Bulldozer. rdrand in particular was added to compilers since at least December of 2012. So, it's definitely not new anymore. And that goes back to my original point: this is just one of dozens of instructions that nobody bothers to use. You can keep adding all the instructions you want, but performance won't improve until devs use them in their software.
People will use a newinstruction if they need it,the AVX512 instructions are very useful for certain workloads, so more people use it, its that simple.
And yet, there are so many applications that could use AVX (just in general, not even 512) or other nice modern instructions like the SSE4 family, but they don't. Take a look at benchmarks of Clear Linux to see how much devs are slacking (that whole distro is optimized to take advantage of various instructions). The amount of untapped performance you can get in a modern Intel or AMD CPU is absolutely insane. But how do you get devs to take this stuff seriously? Until they do, any additional instructions added to CPUs is a wasted effort.
so what do I mean by it is not that important?, It means that inessence the "silicon/developement burden" of maintaining hardware compatibility with old x86 instructions is not a significant factor or rather, the cost of ditching it is way higher than the cost to keep it, by the time some "real" breakage occurs (like deprecating say SSE2) , it probably wont matter(performance wise), is my point.
Yes, maintaining it isn't that difficult. Preventing it from regressing without people noticing is. That's why x86 is heading toward a dead-end. There's no clear path to improve it:
* You can't depend on devs to use new instructions
* You can't make people's existing software run slower; modern optimizations can often cause this
* You can't break software compatibility without pissing people off
* We're near the limits of silicon transistors
To stay on topic, this is main issue, its just not true, because again its not x86 anymore, so you could completely redesign the execution pipeline and maintain x86 compatibility as has been done several times.
I don't understand why you keep pointing that out. It doesn't change the underlying point. Despite how drastically different the execution pipeline is between modern Intel and AMD CPUs, they still perform roughly the same. You could also say the same about Athlon II and Core2. Intel could revamp the entire pipeline, but because of trying to retain x86 software compatibility, it isn't going to get a lot faster.
Patents are relevant because cpus like , arm POWER, sparc, x86, ect have lots of overlap(some arm cpus actually have the an equivalent meltdown bug for instance), and so when amd or intel want to implement a certain feature, they need a team of lawyers to go over the implementation to make sure it doesn't violate somebody else's patent or license it from them , its really a mess frankly.
Depsite intel/amd's crosslicensing deal, there is a tonne of litigation going on all the time of IPs.
Depsite intel/amd's crosslicensing deal, there is a tonne of litigation going on all the time of IPs.
Makes sense.
pages 1 2 3 4 5
Click here to post a comment for this article on the message forum.
Senior Member
Posts: 768
Don't forget ARM.
Their CPUs are becoming quite strong, and they are catching up in GPU department as well (at least on lower end).
And the Chinese are progressing quite fast with their CPU/GPU designs...
I think in the next decade we'll have a 4 or even 5-way battle between silicon giants.