6 ms·

It's finally happening! The increase in competition in both the foundry and architectural spaces is exactly what we need to push us past this stagnation of Moor

by lend000 10y ago

It's finally happening! The increase in competition in both the foundry and architectural spaces is exactly what we need to push us past this stagnation of Moore's Law. Intel needs to sacrifice Microsoft and make x86 a legacy architecture. There are huge parts of their processor designs that no one at the company modifies (or even understands) from one generation to the next, but which they cannot remove for backwards compatibility purposes. It's time to start fresh with a new architecture if they want to maintain their reputation of having the most powerful technology.

Analemma_ 10y ago
> It's time to start fresh with a new architecture if they want to maintain their reputation of having the most powerful technology. They tried that, though. It was called Itanium and it went nowhere. Now, Itanium had all kinds of other problems and I wouldn't call its failure incontrovertible evidence against "Intel should make a new architecture", but I can understand why the company isn't eager to try that again. Backwards compatibility exerts an powerful gravitational pull that is extremely difficult to break away from if you're not started a new platform ex nihilo (which Apple did for the iPhone).
- lend000 10y ago
  > It was called Itanium and it went nowhere. It was popular in its intended niche (HPC) for a while, but the value proposition was not sufficient. It dropped some x86 baggage but it didn't add anything fundamentally superior on top of it -- the ILP could easily be attained by having more cores on x86. To be honest I actually really like what they did with Itanium, but it wasn't a good enough innovation to break off the family line of backwards compatibility.
  - scholia 10y ago
    It wasn't intended to be a niche product. That was just how it ended up....
- pcwalton 10y ago
  Look at what ARM did with AArch64 though: it's backwards compatible via mode switching but is otherwise a fairly clean break at the ISA level. AMD probably could have done something similar. They just didn't, likely out of risk aversion.
- brandonmenc 10y ago
  > They tried that, though. It was called Itanium And the i860, and i960, and i432...
- bluedino 10y ago
  Was the Itanium fiasco more HP or Intel's fault? Either way, it's been 20+ years they could try again.
  - fnord123 10y ago
    I thought they learned that exposing the complexity was a big problem. So now the chips are internally complex but hide it behind the instruction set interface while the chip does its own stuff in the microcode.
wmf 10y ago
Intel needs to sacrifice Microsoft and make x86 a legacy architecture. The last time Intel did this it was called Itanium and it was horrible. Historically, almost all attempts to replace an enormously successful product line with something incompatible have failed.
- pcwalton 10y ago
  > Historically, almost all attempts to replace an enormously successful product line with something incompatible have failed. Except AArch64, which has a legacy 32 bit mode for compatibility but is otherwise a totally separate ISA, unlike x86-64 and i386.
  - StillBored 10y ago
    Aarch64 looks at first glance to be pretty dissimilar, but if you consider that its really a follow-on to THUMB2 it doesn't look as foreign. Also a lot of things appear different at first glance but aren't because they have basically been renamed. one example CPUID->MIDR http://infocenter.arm.com/help/topic/com.arm.doc.ddi0432c/Bhccjgga.html http://infocenter.arm.com/help/topic/com.arm.doc.ddi0432c/Bh... https://developer.arm.com/docs/ddi0500/f/4-system-control/45-aarch32-register-descriptions/451-main-id-register https://developer.arm.com/docs/ddi0500/f/4-system-control/45... The memory model is the same.. etc, etc, etc.
- Tanegashima 10y ago
  6502 - 68000
- pjmlp 10y ago
  If AMD hadn't come up with x64, they would have succeeded it.
facepalm 10y ago
Why can't they keep doing x86 stuff and start something else at the same time?
- scholia 10y ago
  They could,. Unfortunately, it requires a huge investment and needs a lot of highly skilled staff, who are currently working on its mainstream product. Also, when you've done your new chip design, you still have no hardware devices and no software to run on them. It's taken roughly 40 years to get x86 to its current position, and almost as long to get ARM to its current position. For how many years would you have to invest in a new architecture (ie lose money) before you could compete with them? AMD has just done a new chip design (Zen) but it's x86-compatible because that's where the software is....
foobiekr 10y ago
Why does intel need to do this? x86 decode is a tiny, tiny part of the overhead of modern x86 CPUs. Architecture for the most part at this point doesn't matter unless you are talking about truly novel approaches like the Mill. Arm certainly is not a significant improvement.
- wbl 10y ago
  It's more then just decode. Segmentation, x87 emulation, and the interaction with other features are all pain points.
  - dbancajas 10y ago
    That's still part of the ISA right? And the 99% of silicon is not spent on those pain points you talk about. Architectural techniques are largely the same for high performance processors, be it ARM/PPC/x86. If you want high performance, you gotta put in the HW required. LSU, prediction, SMT hardware, branch prediction etc... The single thread speed has already been solved a long time ago. There's no point throwing away x86 in favor of a new ISA that has no guarantee of succeeding. In fact, having a new ISA that is incompatible with x86 will just be detrimental to intel/amd.
  - StillBored 10y ago
    None of that is 1/10th as complex as the virt extensions, IOMMU/ATS, etc, etc, etc, Stuff that is common on high end processors these days. If you think x86 is complex, I suggest that you look at aarch64, the smmu, gicv3, etc docs. Plus, x86-64 basically disables both the things you list. Not that it matters because what is a flat fs/gs/etc register when there is another whole level of page tables for the hypervisor. AKA, you do the translation and store it in a TLB. If you really want to compare this, time how long a modern x86 takes on TLB misses, or for that matter how fast its TLBs are. I think you fill find that they are industry leading... Same basic thing for the x87, its likely mostly powered down, and when active is probably feeding micro-ops through a SSE functional unit.... So the original posters comment is likely correct, and that has been known for a decade+. X86 if anything has a few accidental advantages, and the idea that its somehow "worse" than the alternatives are provably wrong.

by lend000 10y ago

Analemma_ 10y ago

> It's time to start fresh with a new architecture if they want to maintain their reputation of having the most powerful technology. They tried that, though. It was called Itanium and it went nowhere. Now, Itanium had all kinds of other problems and I wouldn't call its failure incontrovertible evidence against "Intel should make a new architecture", but I can understand why the company isn't eager to try that again. Backwards compatibility exerts an powerful gravitational pull that is extremely difficult to break away from if you're not started a new platform ex nihilo (which Apple did for the iPhone).

lend000 10y ago
> It was called Itanium and it went nowhere. It was popular in its intended niche (HPC) for a while, but the value proposition was not sufficient. It dropped some x86 baggage but it didn't add anything fundamentally superior on top of it -- the ILP could easily be attained by having more cores on x86. To be honest I actually really like what they did with Itanium, but it wasn't a good enough innovation to break off the family line of backwards compatibility.
- scholia 10y ago
  It wasn't intended to be a niche product. That was just how it ended up....
pcwalton 10y ago
Look at what ARM did with AArch64 though: it's backwards compatible via mode switching but is otherwise a fairly clean break at the ISA level. AMD probably could have done something similar. They just didn't, likely out of risk aversion.
brandonmenc 10y ago
> They tried that, though. It was called Itanium And the i860, and i960, and i432...
bluedino 10y ago
Was the Itanium fiasco more HP or Intel's fault? Either way, it's been 20+ years they could try again.
- fnord123 10y ago
  I thought they learned that exposing the complexity was a big problem. So now the chips are internally complex but hide it behind the instruction set interface while the chip does its own stuff in the microcode.

wmf 10y ago

Intel needs to sacrifice Microsoft and make x86 a legacy architecture. The last time Intel did this it was called Itanium and it was horrible. Historically, almost all attempts to replace an enormously successful product line with something incompatible have failed.

pcwalton 10y ago
> Historically, almost all attempts to replace an enormously successful product line with something incompatible have failed. Except AArch64, which has a legacy 32 bit mode for compatibility but is otherwise a totally separate ISA, unlike x86-64 and i386.
- StillBored 10y ago
  Aarch64 looks at first glance to be pretty dissimilar, but if you consider that its really a follow-on to THUMB2 it doesn't look as foreign. Also a lot of things appear different at first glance but aren't because they have basically been renamed. one example CPUID->MIDR http://infocenter.arm.com/help/topic/com.arm.doc.ddi0432c/Bhccjgga.html http://infocenter.arm.com/help/topic/com.arm.doc.ddi0432c/Bh... https://developer.arm.com/docs/ddi0500/f/4-system-control/45-aarch32-register-descriptions/451-main-id-register https://developer.arm.com/docs/ddi0500/f/4-system-control/45... The memory model is the same.. etc, etc, etc.
Tanegashima 10y ago
6502 - 68000
pjmlp 10y ago
If AMD hadn't come up with x64, they would have succeeded it.

facepalm 10y ago

Why can't they keep doing x86 stuff and start something else at the same time?

scholia 10y ago
They could,. Unfortunately, it requires a huge investment and needs a lot of highly skilled staff, who are currently working on its mainstream product. Also, when you've done your new chip design, you still have no hardware devices and no software to run on them. It's taken roughly 40 years to get x86 to its current position, and almost as long to get ARM to its current position. For how many years would you have to invest in a new architecture (ie lose money) before you could compete with them? AMD has just done a new chip design (Zen) but it's x86-compatible because that's where the software is....

foobiekr 10y ago

Why does intel need to do this? x86 decode is a tiny, tiny part of the overhead of modern x86 CPUs. Architecture for the most part at this point doesn't matter unless you are talking about truly novel approaches like the Mill. Arm certainly is not a significant improvement.

wbl 10y ago
It's more then just decode. Segmentation, x87 emulation, and the interaction with other features are all pain points.
- dbancajas 10y ago
  That's still part of the ISA right? And the 99% of silicon is not spent on those pain points you talk about. Architectural techniques are largely the same for high performance processors, be it ARM/PPC/x86. If you want high performance, you gotta put in the HW required. LSU, prediction, SMT hardware, branch prediction etc... The single thread speed has already been solved a long time ago. There's no point throwing away x86 in favor of a new ISA that has no guarantee of succeeding. In fact, having a new ISA that is incompatible with x86 will just be detrimental to intel/amd.
- StillBored 10y ago
  None of that is 1/10th as complex as the virt extensions, IOMMU/ATS, etc, etc, etc, Stuff that is common on high end processors these days. If you think x86 is complex, I suggest that you look at aarch64, the smmu, gicv3, etc docs. Plus, x86-64 basically disables both the things you list. Not that it matters because what is a flat fs/gs/etc register when there is another whole level of page tables for the hypervisor. AKA, you do the translation and store it in a TLB. If you really want to compare this, time how long a modern x86 takes on TLB misses, or for that matter how fast its TLBs are. I think you fill find that they are industry leading... Same basic thing for the x87, its likely mostly powered down, and when active is probably feeding micro-ops through a SSE functional unit.... So the original posters comment is likely correct, and that has been known for a decade+. X86 if anything has a few accidental advantages, and the idea that its somehow "worse" than the alternatives are provably wrong.