6 ms·

Intel/x86 seems to have missed pretty much every major trend but somehow manages to keep up. At the time, Intel seemed to have pinned the 64-bit future on Itan

Intel/x86 seems to have missed pretty much every major trend but somehow manages to keep up. At the time, Intel seemed to have pinned the 64-bit future on Itanium. Which, on paper, is a much better architecture. Of course instruction parallelism should be in the hands of the compiler -- it has so much richer information from the source-code so it can do a better job. The MMU design was very clever (self-mapped linear page tables, protection keys, TLB sharing, etc). Lots of cache, minimal core. Exposing register rotation and really interesting tracing tools. But AMD released x86/64, Intel had to copy it, and the death warrant on Itanium was signed so we never got to really explore those cool features. Just now we're getting things like more levels of page-tables and protection-key type things on x86. Intel missed virtualisation not only in x86 (understandable given legacy) but on Itanium too, where arguably they should have thought about it during green-field development (it was closer but still had a few instructions that didn't trap properly for a hypervisor to work). The first versions of vmware -- doing binary translation of x86 code the fly, was really quite amazing at the time. Virtualisation happened despite x86, not in any way because of it. And you can pretty much trace the entire "cloud" back to that. VMX eventually got bolted on. UEFI is ... interesting. It's better than a BIOS, but would anyone hold that up as a paragon of innovation? I'm not so familiar with the SIMD bits of the chips, but I wouldn't be surprised if there's similar stories in that area of development. Low power seems lost to ARM and friends. Now, with the "cloud", low power is as much a problem in the data centre as your phone. So it will be interesting to see how that plays out (and it's starting to). x86's persistence is certainly remarkable, that's for sure

jackyinger 9y ago
WRT Itanium and all VLIW processors for that mater, you have to compile for the microarchitecture of the processor to fully take advantage of it. Which sinks the x86 binary portability that we've all come to know and love. Which leads to the fundamental ease that ubiquity brings to working with x86 as an end user or any software dev that doesn't really care about processor internals. It sure would be interesting to see something else challenge x86, but since ARM/Power/RISC-V are all within the same architectural tradition I doubt they will provide it. SIMD as used by GPUs is useful only when you have very structured parallelism like arithmetic on large data sets. I think if we're going to see a challenger worth noting they'll look like they're crazy with the hard uphill battle and novel tech they will have to produce.
- delsarto 9y ago
  > WRT Itanium and all VLIW processors for that mater, you have to compile for the microarchitecture of the processor to fully take advantage of it True of course, but Itanium did think of this and had an "abstracted" VLIW where you worked with generic instruction bundles which the hardware was then more free to pull apart in different ways underneath. I do wonder, if we'd all taken a different path, if we'd be in more of a JIT-compiled type world. who knows?
  - gumby 9y ago
    We are in a JIT world, it's just that the code is running on the IVM ("Intel Virtual machine) being interpreted by intel's microcode.
- jacobr1 9y ago
  Does the Mill architecture count as looking crazy enough?
  - microcolonel 9y ago
    Mill isn't too crazy from what I've seen, they seem acutely aware of the pitfalls of poor cache utilization and other things which were the bane of VLIW (outside of DSP). The future holds the truth on just how much that awareness translates into performance, but at least they're thinking a bit. The thing which concerns me about the Mill is the software-managed binary incompatibility between every model. They say this is manageable but I have some doubts about it, especially about how it plays with JITs. They say that JITs will have to link to their proprietary system library in order to work, which seems like it could be devastating for uptake.
- microcolonel 9y ago
  If you're looking for innovation on vector operations (i.e. not packed SIMD or GPU-style SPMD), then RISC-V's vector extension (especially if you consider extensions to it for graphics or scientific compute or machine learning) should seem very promising. It's not technically groundbreaking (Cray did it first), but I think it has more potential than the endless treadmill of wider packed SIMD instructions (which dissipate an immense amount of power on intel's hardware), and it is amenable to more general tasks than SPMD is.
microcolonel 9y ago
Itanium failed because writing compilers which make VLIW efficient is probably not surmountable for human minds. Donald Knuth himself said that compilers which would make it perform even sufficiently were nearly impossible to write. With it being borderline impossible to write good VLIW compilers, most of the instruction word was full of NOPs, which meant terrible code density, which meant I$ full of NOPs. A recipe for hot, slow computers which are depressing to program for.
- bogomipz 9y ago
  >"Itanium failed because writing compilers which make VLIW efficient is probably not surmountable for human minds. Donald Knuth himself said that compilers which would make it perform even sufficiently were nearly impossible to write." Wow, might you have any links regarding Knuth commenting on VLIW optimized compilers? I would love to read more about this. What was Intel's view on the viability of it? It seems like quite a shortcoming.
  - nickpsecurity 9y ago
    http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856
    - mirimir 9y ago
      Only two apps that I use regularly use multiple cores: Excel and VirtualBox.
      - baq 9y ago
        and your browser :)
        nickpsecurity 9y ago
        Especially when Mozilla's Quantum hits.
yuhong 9y ago
What is fun is that x86-64 ended up having CPU vendor dependent things like SYSENTER vs SYSCALL (and even SYSCALL ended up having a bunch of vendor dependent things about it too). Win10 had to add INT 2E to the 64-bit kernel for 32-bit system calls.
frankpf 9y ago
> Of course instruction parallelism should be in the hands of the compiler -- it has so much richer information from the source-code so it can do a better job. This is not true. Yes, the compiler has a lot of useful information, but it does not have access to runtime information, which the CPU does. A modern superscalar CPU with out-of-order execution can execute instructions speculatively hundreds of cycles before they are even used. Instructions after conditional branches can be executed speculatively using branch prediction and loads can be executed before stores (even though they might access the same address!). If the processor later detects that the load was dependent on the store, it can "undo" that operation, without any of these effects ever being visible to the running program.
- Laaas 9y ago
  While you are right, the compiler should still definitely do most of the job. There's simply no reason to keep track of dependencies, etc. at run-time, instead of doing this compile-time.
  - striking 9y ago
    Some of that information doesn't exist at compile time...
    - jonhohle 9y ago
      Do you have any examples of when this beats a C program compiles with `-march -O2`? I've read about this promise of JIT optimization being able to generate optimal code on hot paths, but in practice I've never seen it work out that way. Good AOT compilers exist today and consistently generate optimized machine code.
      - ksk 9y ago
        Your C code is already executed by the CPU in a JIT optimized way because of the way the x86 architecture is implemented on the CPU. What more proof do you want?! :)
      - 9y ago
nickpsecurity 9y ago
"so we never got to really explore those cool features" The security stuff was explored pretty well by Secure64. I've always given them credit for at least trying to build bottom-up on it with above-average results in pentesting. https://www-ssl.intel.com/content/dam/www/public/us/en/documents/white-papers/intel-itanium-secure-white-paper.pdf https://www-ssl.intel.com/content/dam/www/public/us/en/docum...
pjmlp 9y ago
I still believe if AMD hadn't come up with x64 extensions, I would be typing this on an Itanium laptop now. So it failed, because Intel wasn't the only one doing x86 processors, otherwise they would have been able to push it down our throats one way or the other.
GuB-42 9y ago
I never really got UEFI. That's a bootloader, the only thing it has to do is : - initialize the RAM and other essential subsystems - initialize whatever is needed to access mass storage devices - copy X bytes from a specific location on a specified mass storage device into RAM - set the instruction pointer on the copied data Everything else is the OS job. Even the BIOS does too much.
- dingo_bat 9y ago
  Who's gonna block you from booting Linux on your Surface Book then?
b0rsuk 9y ago
You make it sound like uranium nuclear reactors vs thorium nuclear reactors. Because of the arms race, uranium ones were developed first even though they are merely a (as one HN commenter put it) local optimum. And I remember I was one of the happy guys, rooting for AMD and enjoying cheaper processors. Was I foolish ?

jackyinger 9y ago

WRT Itanium and all VLIW processors for that mater, you have to compile for the microarchitecture of the processor to fully take advantage of it. Which sinks the x86 binary portability that we've all come to know and love. Which leads to the fundamental ease that ubiquity brings to working with x86 as an end user or any software dev that doesn't really care about processor internals. It sure would be interesting to see something else challenge x86, but since ARM/Power/RISC-V are all within the same architectural tradition I doubt they will provide it. SIMD as used by GPUs is useful only when you have very structured parallelism like arithmetic on large data sets. I think if we're going to see a challenger worth noting they'll look like they're crazy with the hard uphill battle and novel tech they will have to produce.

delsarto 9y ago
> WRT Itanium and all VLIW processors for that mater, you have to compile for the microarchitecture of the processor to fully take advantage of it True of course, but Itanium did think of this and had an "abstracted" VLIW where you worked with generic instruction bundles which the hardware was then more free to pull apart in different ways underneath. I do wonder, if we'd all taken a different path, if we'd be in more of a JIT-compiled type world. who knows?
- gumby 9y ago
  We are in a JIT world, it's just that the code is running on the IVM ("Intel Virtual machine) being interpreted by intel's microcode.
jacobr1 9y ago
Does the Mill architecture count as looking crazy enough?
- microcolonel 9y ago
  Mill isn't too crazy from what I've seen, they seem acutely aware of the pitfalls of poor cache utilization and other things which were the bane of VLIW (outside of DSP). The future holds the truth on just how much that awareness translates into performance, but at least they're thinking a bit. The thing which concerns me about the Mill is the software-managed binary incompatibility between every model. They say this is manageable but I have some doubts about it, especially about how it plays with JITs. They say that JITs will have to link to their proprietary system library in order to work, which seems like it could be devastating for uptake.
microcolonel 9y ago
If you're looking for innovation on vector operations (i.e. not packed SIMD or GPU-style SPMD), then RISC-V's vector extension (especially if you consider extensions to it for graphics or scientific compute or machine learning) should seem very promising. It's not technically groundbreaking (Cray did it first), but I think it has more potential than the endless treadmill of wider packed SIMD instructions (which dissipate an immense amount of power on intel's hardware), and it is amenable to more general tasks than SPMD is.

microcolonel 9y ago

Itanium failed because writing compilers which make VLIW efficient is probably not surmountable for human minds. Donald Knuth himself said that compilers which would make it perform even sufficiently were nearly impossible to write. With it being borderline impossible to write good VLIW compilers, most of the instruction word was full of NOPs, which meant terrible code density, which meant I$ full of NOPs. A recipe for hot, slow computers which are depressing to program for.

bogomipz 9y ago
>"Itanium failed because writing compilers which make VLIW efficient is probably not surmountable for human minds. Donald Knuth himself said that compilers which would make it perform even sufficiently were nearly impossible to write." Wow, might you have any links regarding Knuth commenting on VLIW optimized compilers? I would love to read more about this. What was Intel's view on the viability of it? It seems like quite a shortcoming.
- nickpsecurity 9y ago
  http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856
  - mirimir 9y ago
    Only two apps that I use regularly use multiple cores: Excel and VirtualBox.
    - baq 9y ago
      and your browser :)
      - nickpsecurity 9y ago
        Especially when Mozilla's Quantum hits.

yuhong 9y ago

What is fun is that x86-64 ended up having CPU vendor dependent things like SYSENTER vs SYSCALL (and even SYSCALL ended up having a bunch of vendor dependent things about it too). Win10 had to add INT 2E to the 64-bit kernel for 32-bit system calls.

frankpf 9y ago

> Of course instruction parallelism should be in the hands of the compiler -- it has so much richer information from the source-code so it can do a better job. This is not true. Yes, the compiler has a lot of useful information, but it does not have access to runtime information, which the CPU does. A modern superscalar CPU with out-of-order execution can execute instructions speculatively hundreds of cycles before they are even used. Instructions after conditional branches can be executed speculatively using branch prediction and loads can be executed before stores (even though they might access the same address!). If the processor later detects that the load was dependent on the store, it can "undo" that operation, without any of these effects ever being visible to the running program.

Laaas 9y ago
While you are right, the compiler should still definitely do most of the job. There's simply no reason to keep track of dependencies, etc. at run-time, instead of doing this compile-time.
- striking 9y ago
  Some of that information doesn't exist at compile time...
  - jonhohle 9y ago
    Do you have any examples of when this beats a C program compiles with `-march -O2`? I've read about this promise of JIT optimization being able to generate optimal code on hot paths, but in practice I've never seen it work out that way. Good AOT compilers exist today and consistently generate optimized machine code.
    - ksk 9y ago
      Your C code is already executed by the CPU in a JIT optimized way because of the way the x86 architecture is implemented on the CPU. What more proof do you want?! :)
    - 9y ago

nickpsecurity 9y ago

"so we never got to really explore those cool features" The security stuff was explored pretty well by Secure64. I've always given them credit for at least trying to build bottom-up on it with above-average results in pentesting. https://www-ssl.intel.com/content/dam/www/public/us/en/documents/white-papers/intel-itanium-secure-white-paper.pdf https://www-ssl.intel.com/content/dam/www/public/us/en/docum...

pjmlp 9y ago

I still believe if AMD hadn't come up with x64 extensions, I would be typing this on an Itanium laptop now. So it failed, because Intel wasn't the only one doing x86 processors, otherwise they would have been able to push it down our throats one way or the other.

GuB-42 9y ago

I never really got UEFI. That's a bootloader, the only thing it has to do is : - initialize the RAM and other essential subsystems - initialize whatever is needed to access mass storage devices - copy X bytes from a specific location on a specified mass storage device into RAM - set the instruction pointer on the copied data Everything else is the OS job. Even the BIOS does too much.

dingo_bat 9y ago
Who's gonna block you from booting Linux on your Surface Book then?

b0rsuk 9y ago

You make it sound like uranium nuclear reactors vs thorium nuclear reactors. Because of the arms race, uranium ones were developed first even though they are merely a (as one HN commenter put it) local optimum. And I remember I was one of the happy guys, rooting for AMD and enjoying cheaper processors. Was I foolish ?