phubarNew SIMD vector FPU's have nothing to do with the changes to the existing x86 or x86-64 ISA per se.

Oh, but they do. That is a level of freaky-neaky detail I'm not going to get into here. Just know that "yes they are".

What a mess.
The idea of cleaning up the x86 architecture by removing old and useless technologies is a very good one. I think it would reduce the time and cost of designing new CPUs.
I hope Intel and AMD are developing a "version 2.0" of X86S right now.

NhonhoThe idea of cleaning up the x86 architecture by removing old and useless technologies is a very good one.

No, it isn't.

NhonhoI think it would reduce the time and cost of designing new CPUs.

And you're welcome to your opinion. Doesn't make it a good one.

NhonhoI hope Intel and AMD are developing a "version 2.0" of X86S right now.

They aren't and are unlikely to as many of the 8 & 16 bit functions and instructions are still in common use to say nothing of the 32bit range.

As I stated above, compatibility is important! You don't just screw over an entire world of software just to make something a little bit more efficient.

Dr. DroSaving the world is a giant stretch. The reason Itanium did not achieve any significant market penetration was due to a combination of factors, namely the processors' very high cost, IA-64's binary incompatibility with the established industry standard that was x86 (and woefully slow emulation, to the tune of basically performing between a 486 and P5 Pentium CPU) - notice the media back in 2001 was already calling it the Itanic - once AMD brought 64 bit extensions with most of the 64 bit computing benefits while retaining full x86 compatibility at native performance to the Opteron, Intel followed suit by doing the same thing to Xeon, and ultimately, it was Xeon that killed Itanium. x86 compatibility was simply deemed too important at the time to let go. Nowadays the same scenario would not really repeat itself, if say, an ARM-based monster that performed like a high-end EPYC became widely available, that chip would see significant market adoption simply because software is available for it.

Did you do Any Programming for IA-64 processor?

I'm confident for 100% that you Did Not. I Did.

>>...basically performing between a 486 and P5 Pentium CPU...

How could you make so Resolute Statements about a topic Without Any Practical Experience?

Compare a Peak Processing Power of a 1st Gen Intel Itanium 9010 processor ( 12.80 GFLOPs ) vs. Intel Pentium 4 processor ( 2.1655 GFLOPs ).

Intel Itanium Processors - Processing Powers:

www.intel.com/content/dam/support/us/en/documents/processors/APP-for-Intel-Itanium-Processors.pdf

9010 12.80 GFLOPs
9015 11.20 GFLOPs
9020 11.36 GFLOPs
9030 12.80 GFLOPs
9040 12.80 GFLOPs
9050 12.80 GFLOPs
9110N 12.80 GFLOPs
9120N 11.36 GFLOPs
9130M 13.28 GFLOPs
9140M 13.28 GFLOPs
9140N 12.80 GFLOPs
9150M 13.28 GFLOPs
9150N 12.80 GFLOPs
9152M 13.28 GFLOPs
9310 12.80 GFLOPs
9320 21.33 GFLOPs
9330 23.36 GFLOPs
9340 25.60 GFLOPs
9350 27.68 GFLOPs
9520 27.68 GFLOPs
9540 68.16 GFLOPs
9550 38.40 GFLOPs
9560 80.96 GFLOPs
9720 27.68 GFLOPs
9740 68.16 GFLOPs
9750 40.48 GFLOPs
9760 85.12 GFLOPs

Here is a Linpack processing report for Intel Pentium 4 processor:

Intel(R) Optimized LINPACK Benchmark data

Current date/time: Thu Dec 14 13:57:28 2017

CPU frequency: 3.185 GHz
Number of CPUs: 1
Number of cores: 1
Number of threads: 1

Parameters are set to:

Number of tests: 8
Number of equations to solve (problem size) : 3000 4000 5000 6000 7000 8000 9000 10000
Leading dimension of array : 3008 4008 5008 6008 7008 8008 9008 10008
Number of trials to run : 8 8 6 6 4 4 2 2
Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4

Maximum memory requested that can be used=800844256, at the size=10000

============= Timing linear equation system solver =================

Size LDA Align. Time(s) GFlops Residual Residual(norm)
3000 3008 4 8.936 2.0163 9.694523e-012 3.733128e-002
3000 3008 4 8.933 2.0169 9.694523e-012 3.733128e-002
3000 3008 4 8.926 2.0186 9.694523e-012 3.733128e-002
3000 3008 4 8.924 2.0191 9.694523e-012 3.733128e-002
3000 3008 4 8.925 2.0188 9.694523e-012 3.733128e-002
3000 3008 4 8.925 2.0189 9.694523e-012 3.733128e-002
3000 3008 4 8.923 2.0192 9.694523e-012 3.733128e-002
3000 3008 4 8.923 2.0192 9.694523e-012 3.733128e-002
4000 4008 4 21.324 2.0024 1.492001e-011 3.251957e-002
4000 4008 4 21.574 1.9792 1.492001e-011 3.251957e-002
4000 4008 4 21.563 1.9802 1.492001e-011 3.251957e-002
4000 4008 4 21.571 1.9794 1.492001e-011 3.251957e-002
4000 4008 4 21.577 1.9789 1.492001e-011 3.251957e-002
4000 4008 4 21.576 1.9790 1.492001e-011 3.251957e-002
4000 4008 4 21.571 1.9794 1.492001e-011 3.251957e-002
4000 4008 4 21.583 1.9784 1.492001e-011 3.251957e-002
5000 5008 4 40.665 2.0505 2.612743e-011 3.643260e-002
5000 5008 4 40.732 2.0471 2.612743e-011 3.643260e-002
5000 5008 4 40.719 2.0478 2.612743e-011 3.643260e-002
5000 5008 4 40.732 2.0471 2.612743e-011 3.643260e-002
5000 5008 4 40.739 2.0468 2.612743e-011 3.643260e-002
5000 5008 4 40.736 2.0469 2.612743e-011 3.643260e-002
6000 6008 4 67.792 2.1252 3.570994e-011 3.463098e-002
6000 6008 4 67.778 2.1256 3.570994e-011 3.463098e-002
6000 6008 4 67.814 2.1245 3.570994e-011 3.463098e-002
6000 6008 4 67.762 2.1262 3.570994e-011 3.463098e-002
6000 6008 4 67.798 2.1250 3.570994e-011 3.463098e-002
6000 6008 4 67.812 2.1246 3.570994e-011 3.463098e-002
7000 7008 4 111.721 2.0476 4.979297e-011 3.572962e-002
7000 7008 4 111.679 2.0484 4.979297e-011 3.572962e-002
7000 7008 4 111.675 2.0485 4.979297e-011 3.572962e-002
7000 7008 4 111.699 2.0480 4.979297e-011 3.572962e-002
8000 8008 4 166.042 2.0565 6.930695e-011 3.812483e-002
8000 8008 4 166.014 2.0568 6.930695e-011 3.812483e-002
8000 8008 4 165.963 2.0575 6.930695e-011 3.812483e-002
8000 8008 4 166.009 2.0569 6.930695e-011 3.812483e-002
9000 9008 4 224.556 2.1650 8.150675e-011 3.549514e-002
9000 9008 4 224.500 2.1655 8.150675e-011 3.549514e-002
10000 10008 4 316.305 2.1083 9.446022e-011 3.330763e-002
10000 10008 4 316.321 2.1082 9.446022e-011 3.330763e-002

Performance Summary (GFlops)

Size LDA Align. Average Maximal
3000 3008 4 2.0184 2.0192
4000 4008 4 1.9821 2.0024
5000 5008 4 2.0477 2.0505
6000 6008 4 2.1252 2.1262
7000 7008 4 2.0482 2.0485
8000 8008 4 2.0569 2.0575
9000 9008 4 2.1653 2.1655
10000 10008 4 2.1082 2.1083

End of tests

14/12/2017
02:56 PM

lexluthermiesterAs I stated above, compatibility is important! You don't just screw over an entire world of software just to make something a little bit more efficient.

X86s wouldn't change anything compatibility wise (assuming you're already running a modern OS).

lexluthermiesteras many of the 8 & 16 bit functions and instructions are still in common use to say nothing of the 32bit range.

This would not change whatsoever.

igormpX86s wouldn't change anything compatibility wise (assuming you're already running a modern OS).

This would not change whatsoever.

When Intel informed the IT world about x86S my first reaction was "...Please, please, Do Not do it!..."

ScaLibBDPWhen Intel informed the IT world about x86S my first reaction was "...Please, please, Do Not do it!..."

Have you read the actual specification?
The only thing that would change is that you wouldn't be able to boot DOS or Windows 98 on your brand new i9/Ryzen CPU.

ScaLibBDPDid you do Any Programming for IA-64 processor?

I'm confident for 100% that you Did Not. I Did.

>>...basically performing between a 486 and P5 Pentium CPU...

How could you make so Resolute Statements about a topic Without Any Practical Experience?

Compare a Peak Processing Power of a 1st Gen Intel Itanium 9010 processor ( 12.80 GFLOPs ) vs. Intel Pentium 4 processor ( 2.1655 GFLOPs ).

Intel Itanium Processors - Processing Powers:

www.intel.com/content/dam/support/us/en/documents/processors/APP-for-Intel-Itanium-Processors.pdf

9010 12.80 GFLOPs
9015 11.20 GFLOPs
9020 11.36 GFLOPs
9030 12.80 GFLOPs
9040 12.80 GFLOPs
9050 12.80 GFLOPs
9110N 12.80 GFLOPs
9120N 11.36 GFLOPs
9130M 13.28 GFLOPs
9140M 13.28 GFLOPs
9140N 12.80 GFLOPs
9150M 13.28 GFLOPs
9150N 12.80 GFLOPs
9152M 13.28 GFLOPs
9310 12.80 GFLOPs
9320 21.33 GFLOPs
9330 23.36 GFLOPs
9340 25.60 GFLOPs
9350 27.68 GFLOPs
9520 27.68 GFLOPs
9540 68.16 GFLOPs
9550 38.40 GFLOPs
9560 80.96 GFLOPs
9720 27.68 GFLOPs
9740 68.16 GFLOPs
9750 40.48 GFLOPs
9760 85.12 GFLOPs

Here is a Linpack processing report for Intel Pentium 4 processor:

Intel(R) Optimized LINPACK Benchmark data

Current date/time: Thu Dec 14 13:57:28 2017

CPU frequency: 3.185 GHz
Number of CPUs: 1
Number of cores: 1
Number of threads: 1

Parameters are set to:

Number of tests: 8
Number of equations to solve (problem size) : 3000 4000 5000 6000 7000 8000 9000 10000
Leading dimension of array : 3008 4008 5008 6008 7008 8008 9008 10008
Number of trials to run : 8 8 6 6 4 4 2 2
Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4

Maximum memory requested that can be used=800844256, at the size=10000

============= Timing linear equation system solver =================

Size LDA Align. Time(s) GFlops Residual Residual(norm)
3000 3008 4 8.936 2.0163 9.694523e-012 3.733128e-002
3000 3008 4 8.933 2.0169 9.694523e-012 3.733128e-002
3000 3008 4 8.926 2.0186 9.694523e-012 3.733128e-002
3000 3008 4 8.924 2.0191 9.694523e-012 3.733128e-002
3000 3008 4 8.925 2.0188 9.694523e-012 3.733128e-002
3000 3008 4 8.925 2.0189 9.694523e-012 3.733128e-002
3000 3008 4 8.923 2.0192 9.694523e-012 3.733128e-002
3000 3008 4 8.923 2.0192 9.694523e-012 3.733128e-002
4000 4008 4 21.324 2.0024 1.492001e-011 3.251957e-002
4000 4008 4 21.574 1.9792 1.492001e-011 3.251957e-002
4000 4008 4 21.563 1.9802 1.492001e-011 3.251957e-002
4000 4008 4 21.571 1.9794 1.492001e-011 3.251957e-002
4000 4008 4 21.577 1.9789 1.492001e-011 3.251957e-002
4000 4008 4 21.576 1.9790 1.492001e-011 3.251957e-002
4000 4008 4 21.571 1.9794 1.492001e-011 3.251957e-002
4000 4008 4 21.583 1.9784 1.492001e-011 3.251957e-002
5000 5008 4 40.665 2.0505 2.612743e-011 3.643260e-002
5000 5008 4 40.732 2.0471 2.612743e-011 3.643260e-002
5000 5008 4 40.719 2.0478 2.612743e-011 3.643260e-002
5000 5008 4 40.732 2.0471 2.612743e-011 3.643260e-002
5000 5008 4 40.739 2.0468 2.612743e-011 3.643260e-002
5000 5008 4 40.736 2.0469 2.612743e-011 3.643260e-002
6000 6008 4 67.792 2.1252 3.570994e-011 3.463098e-002
6000 6008 4 67.778 2.1256 3.570994e-011 3.463098e-002
6000 6008 4 67.814 2.1245 3.570994e-011 3.463098e-002
6000 6008 4 67.762 2.1262 3.570994e-011 3.463098e-002
6000 6008 4 67.798 2.1250 3.570994e-011 3.463098e-002
6000 6008 4 67.812 2.1246 3.570994e-011 3.463098e-002
7000 7008 4 111.721 2.0476 4.979297e-011 3.572962e-002
7000 7008 4 111.679 2.0484 4.979297e-011 3.572962e-002
7000 7008 4 111.675 2.0485 4.979297e-011 3.572962e-002
7000 7008 4 111.699 2.0480 4.979297e-011 3.572962e-002
8000 8008 4 166.042 2.0565 6.930695e-011 3.812483e-002
8000 8008 4 166.014 2.0568 6.930695e-011 3.812483e-002
8000 8008 4 165.963 2.0575 6.930695e-011 3.812483e-002
8000 8008 4 166.009 2.0569 6.930695e-011 3.812483e-002
9000 9008 4 224.556 2.1650 8.150675e-011 3.549514e-002
9000 9008 4 224.500 2.1655 8.150675e-011 3.549514e-002
10000 10008 4 316.305 2.1083 9.446022e-011 3.330763e-002
10000 10008 4 316.321 2.1082 9.446022e-011 3.330763e-002

Performance Summary (GFlops)

Size LDA Align. Average Maximal
3000 3008 4 2.0184 2.0192
4000 4008 4 1.9821 2.0024
5000 5008 4 2.0477 2.0505
6000 6008 4 2.1252 2.1262
7000 7008 4 2.0482 2.0485
8000 8008 4 2.0569 2.0575
9000 9008 4 2.1653 2.1655
10000 10008 4 2.1082 2.1083

End of tests

14/12/2017
02:56 PM

Happens to the best of us but, have you taken the time to re-read both my post and the article? It specifically mentions the original 2001 "Merced" Itanium's x86 performance ;)

The 9010 is a Montecito chip, about 5 years newer.

phubarEeeeh its a lil' stretchy but not by much.

If AMD hadn't been around with a ready competitor ISA, which to read some of the press at the time no one thought would be viable or competitive with Intel's EPIC, and a decently performant CPU to sell so programmers had something to work with immediately then its a given that EPIC would've been pushed massively by Intel everywhere. Including the mainstream desktop.

There would've been no competition without AMD so what would've stopped them?

ARM? They're only started to be competitive in a practical sense within the last few years. MIPS and SPARC were on life support already by the late 90's. Same goes for PA-RISC, POWER/PPC, and Alpha. Everyone more or less was running out of development funds by the mid-ish 90's (choked off by x86 eating their share of the server and workstation market), or being sabotaged by their own management (remember what Carly Fiorina did to HP?) by the time EPIC CPU's began to come to market and had largely given up on competing. At best they were trying to just hold onto some market share but even that was clearly becoming a lost cause by the late 90's for some the smaller players.

Bear in mind too that Intel knew well before launch that EPIC had some rather dramatic performance issues that weren't going to be solved for years at best (remember the "wait for McKinley" sales pitch at launch of Merced in 2001? LOL) and still launched it into the server and HPC markets anyways. And then they kept on trying to push it massively in the server and HPC market too despite knowing it was a stinker. It wasn't until Poulson (in 2012) that they more or less finally threw in the towel and admitted publicly the ISA was a failure and would be cutting it eventually.

That's around 11yr of failure they were willing to try and roll the dice with!!! Intel was extremely serious about trying to push EPIC everywhere at a minimum in the beginning. It was only because there was viable competition in the market that they failed to pull that off.

Maybe back then it was a whole different ballgame, from what I understand nowadays it is much easier to compile code across architectures and operating systems, which makes ARM, RISC-V, etc. much more viable because if the software does not exist, it will exist within days. Performance and price are the first and foremost concerns today.

lexluthermiesterOh, but they do. That is a level of freaky-neaky detail I'm not going to get into here. Just know that "yes they are".

I have 0 doubt there is some degree of low level hanky panky going on in the hardware at low levels but from a ISA standpoint, which is what the programmer and compiler are targeting, a new SIMD FPU isn't really making changes to what the x86-64, or plain jane x86, side is doing.

Dr. DroMaybe back then it was a whole different ballgame, from what I understand nowadays it is much easier to compile code across architectures and operating systems, which makes ARM, RISC-V, etc. much more viable because if the software does not exist, it will exist within days. Performance and price are the first and foremost concerns today.

What its like now doesn't matter to the point I or the other guy were making though.

They didn't have the degree of cross architecture compilation figured out yet and what they did have in comparison back in the early 2000's was relatively buggy and slow. Honestly even today its not all that great IMO. Its just gotten to be OK-ish enough for most purposes that people are willing to look the other way. Personally I hate stuff like Electron though. You can kiss performance goodbye with that garbage.

phubarHonestly even today its not all that great IMO. Its just gotten to be OK-ish enough for most purposes that people are willing to look the other way.

Skill issue :laugh:
But tooling nowadays makes it way better. Just grab a cross-compiler and be done with it, or even use a modern compiler than can do this out of the box with a simple flag. For other interpreted languages that's even less of an issue.

phubarPersonally I hate stuff like Electron though. You can kiss performance goodbye with that garbage.

I mean, I don't like it at all either, but that's not a good example you're making since this is an example tool that makes it seamlessly to support tons of different platforms in a single go.

igormpX86s wouldn't change anything compatibility wise (assuming you're already running a modern OS).

That is not at all true. That statement kinda proves you're not a programmer.

igormpThis would not change whatsoever.

Again, that is not true.

igormpI mean, I don't like it at all either, but that's not a good example you're making since this is an example tool that makes it seamlessly to support tons of different platforms in a single go.

Its kinda the one that 'everyone' points to for cross compiling being 'solved' and uses all over the place now though so yeah its not a perfect example in the real world its what I constantly run into.

You can successfully argue they shouldn't be using it everywhere. And I'd agree with you. But they don't listen to me.

lexluthermiesterThat is not at all true. That statement kinda proves you're not a programmer.


Again, that is not true.

32-Bit applications would still work according to Intel.

TheDeeGee32-Bit applications would still work according to Intel.

If they can get it right. It would seem they couldn't figure out how to make it work 100% which is likely why they dropped the entire effort.

My best guess is that they dropped this effort because it would cause many more problems than it would solve.

I really hope that Intel and AMD are working together to develop a more improved "version 2.0" of the original X86S, focusing on security, performance and lower power consumption, since the x86-X86S cores would not have the (un)necessary transistors of the legacy parts, which are no longer used.

Intel and AMD should come forward to let us know whether or not they are going to develop a new improved version of X86S, and not leave us in the dark.

lexluthermiesterThat is not at all true. That statement kinda proves you're not a programmer.


Again, that is not true.

Please do enlighten us then if you're so knowledgeable instead of just coming with an ad hominem.
Otherwise, feel free to just read their specification, you don't need to be a programmer (which I believe is not your case given the amount of misunderstandings you spout) do understand a simple table.

phubarIts kinda the one that 'everyone' points to for cross compiling being 'solved' and uses all over the place now though so yeah its not a perfect example in the real world its what I constantly run into.

You can successfully argue they shouldn't be using it everywhere. And I'd agree with you. But they don't listen to me.

Tbh this is an entirely different issue. Electron solely as an UI tool is reasonable (not great, but way better to deal with instead of the likes of QT), in the same way browsers are convenient (albeit bloated, but that does not has direct relationship with performance per se).
Shoving tons of logic client-side however is the main issue, and one that happens quite often and not limited just to electron, but many websites out there as well.

TechBuyingHavocI don't get what the benefit from dropping 16-bit support would be though. Is there a cost to legacy support? Yes probably but the cost is not that high.

It's also completely unused for the most part, and would be trivial to emulate if you DO really need it. Heck, I used to emulate Windows 3.1 on a PowerPC G5 and it was insanely fast, and that thing was very slow vs todays procesors.

lexluthermiesterThat is not at all true. That statement kinda proves you're not a programmer.

It would not load immediately because the boot code currently depends on legacy bits, but updating it would also be insanely trivial and probably, even facilitate a faster boot process. After that from my understanding anything 32-bit or newer would be fine.

I'm indifferent personally. But I can see the benefits of the idea.

lexluthermiesterIf they can get it right. It would seem they couldn't figure out how to make it work 100% which is likely why they dropped the entire effort.

My best guess is that they dropped this effort because it would cause many more problems than it would solve.

Must be the case.

I wouldn't have had a problem with it otherwise.

igormpPlease do enlighten us then if you're so knowledgeable instead of just coming with an ad hominem.

No.

igormpOtherwise, feel free to just read their specification, you don't need to be a programmer (which I believe is not your case given the amount of misunderstandings you spout) do understand a simple table.

Please stop with the personal remarks and reacting with your ego.

R-T-BIt would not load immediately because the boot code currently depends on legacy bits, but updating it would also be insanely trivial and probably, even facilitate a faster boot process. After that from my understanding anything 32-bit or newer would be fine.

I'm indifferent personally. But I can see the benefits of the idea.

That is indeed possible. However, the 8 & 16 bit functionality takes up less than 0.01% of any given x86-64 die, assuming a dual core. More cores equals less percentage die space because all of those instructions being integer based. Everything floating point is/was all 32bit+ from the 486 on up. The 8087/287/387 FPUs were 8 & 16 bit, but those instructions were converted to 32bit and then dropped from the spec.

Additionally, the x86s spec project plans intended to drop 32bit functionality along with the 8 & 16 bit specs. That's the part that is unfeasible. There is just too many 32bit instructions that can not be converted to 64bit and still natively support 32bit functions. This is why they dropped the project. They might revisit the effort in a decade or so, but that's another discussion.

I see this as welcome news, the potential for bugs and what not is just too great, and there would inevitably be some software affected.

lexluthermiesterNo.

Not surprising.

lexluthermiesterPlease stop with the personal remarks and reacting with your ego.

Why? Replying in the same manner you did is now unwelcome?

lexluthermiesterAdditionally, the x86s spec project plans intended to drop 32bit functionality along with the 8 & 16 bit specs. That's the part that is unfeasible. There is just too many 32bit instructions that can not be converted to 64bit and still natively support 32bit functions. This is why they dropped the project. They might revisit the effort in a decade or so, but that's another discussion.

Again, it did not. It was just related to the initialization process. Registers and instructions that you're talking about wouldn't be changed at all.
They'd be removing real mode and and such, support for 32-bit programs wouldn't change, and 8&16-bit is not a thing OS wise anymore.
Really, just put some effort in reading the spec.

lexluthermiesterNo.

Please stop with the personal remarks and reacting with your ego.


That is indeed possible. However, the 8 & 16 bit functionality takes up less than 0.01% of any given x86-64 die, assuming a dual core. More cores equals less percentage die space because all of those instructions being integer based. Everything floating point is/was all 32bit+ from the 486 on up. The 8087/287/387 FPUs were 8 & 16 bit, but those instructions were converted to 32bit and then dropped from the spec.

Additionally, the x86s spec project plans intended to drop 32bit functionality along with the 8 & 16 bit specs. That's the part that is unfeasible. There is just too many 32bit instructions that can not be converted to 64bit and still natively support 32bit functions. This is why they dropped the project. They might revisit the effort in a decade or so, but that's another discussion.

Small correction, pretty much on target but every core in modern CPUs has it's own integer unit so it would scale with core count. Still, the percentage is nothing to seriously worry about, probably like you said 0.01%.

igormpWhy? Replying in the same manner you did is now unwelcome?

Let's not issue blame here. We all just need to behave. please. I know discussions can get heated but taking a step back and realizing it's not worth fighting about something that in the end, we are both passionate about.

TheinsanegamerNBesides, there's been repeated evidence that x86 is NOT the problem.

But it is.

www.spiceworks.com/tech/tech-general/articles/risc-vs-cisc/

However, today, the CISC architecture is almost obsolete as its development is becoming increasingly difficult. Since the technology was developed by Intel, the company continued to invest in it to keep its current hardware and software backward compatible with x86 processors.
Today’s advanced ARM devices, PICs microcontrollers, and intelligent devices such as smartphones use the RISC architecture since they are power-efficient, require fewer resources, and are faster. The only CISC devices existent today are Intel’s series of x86 processors.

TheinsanegamerNIntel lunar lake is pushing out ARM levels of battery life.

It is about time the smartphones makers start using Intel LNRL. /joke

TheinsanegamerNThe problem has been, and always will be, it's core design. Arrow lake proved that too, even with TSMC 3, Intel still slurps amps.

The whole project was a waste of time and money and with Pat gone this seems like a great time to eliminate the project from their books.

3valatzyBut it is.

www.spiceworks.com/tech/tech-general/articles/risc-vs-cisc/

This article is way too superficial, and only reflects ideas that were true in the past, but have become way more nuanced since them.

In case you want to dive a bit more into it, here are some nice links:
chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter

In short: a CISC decoder is more complex, sure, but that complexity is just a really minor fraction of the CPU, both performance, space and energy-wise, and decoding instructions is hardly ever the bottleneck in most core designs, thus the ISA itself is of less relevance when other aspects of a CPU are considered.

thank god. backwards compatibility is the main draw of x86 and with x86 using risc like micro ops for close to 30 years, the whole risc vs cisc debate has been useless.
im just tired of the corporate shilling for arm, they do this whole "x86 is dead" thing every 10 years. first it was itanium, then it was "tablets are the future, no one will use a computer in the future" now its just direct corporate shilling for windows on arm laptops like that hasn't failed at least 3 separate times..

websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/080403.pdf
nextgen who was absorbed by amd in the k6 era, pioneered breaking cisc operations down into risc-like micro-ops this has been the standard in x86 designs under the hood. any benefits from removing legacy parts of the isa would only be in die space, which lets be honest is not an issue on such small process nodes

igormpThis article is way too superficial, and only reflects ideas that were true in the past, but have become way more nuanced since them.

In case you want to dive a bit more into it, here are some nice links:
chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter

In short: a CISC decoder is more complex, sure, but that complexity is just a really minor fraction of the CPU, both performance, space and energy-wise, and decoding instructions is hardly ever the bottleneck in most core designs, thus the ISA itself is of less relevance when other aspects of a CPU are considered.

honestly there's probably some esoteric way they can turn off unused portions of the decoder until they are needed. i remember back in the bulldozer days amd had some kind of way of using resonant clock meshing to save power to individual transistors.