5 ms·

The chip designers back then were focussed (micro-)instructions per clock (IPC), and everyone knew that RISC and CISC were going to hit a wall due to the ALU by

The chip designers back then were focussed (micro-)instructions per clock (IPC), and everyone knew that RISC and CISC were going to hit a wall due to the ALU bypass network. A this is pretty true, they did, to this day, with some incremental improvements. Folks hoped that VLIW and advanced compilers would take us to the next level of IPC. What they didn't realize was that Itanium wasn't a true VLIW, and had that same ALU bypass network, hence couldn't scale up width and frequency as promised. But a true VLIW would have been very hard to work with. Perhaps Transmeta's approach could have worked if that technology was pushed by a a larger, more resourced company.

chasil 3y ago
I wonder how ARM, so relatively late with AArch64, was able to compel Fujitsu to take the instruction set to the heights of the top-performing supercomputer. I understand that there are exotic addressing modes involved. I'm not versed enough to understand. https://en.m.wikipedia.org/wiki/Fugaku_(supercomputer) https://en.m.wikipedia.org/wiki/Fugaku_(supercomputer)
- pezezin 3y ago
  Fujitsu was using their own in-house SPARC designs with custom vector instructions, but they could see that SPARC is dead and has no future. In fact, not that long ago they announced that they will stop sales in 2029 and support 5 years later: https://www.fujitsu.com/global/products/computing/servers/unix/sparc/key-reports/roadmap/index.html https://www.fujitsu.com/global/products/computing/servers/un... So if they wanted to keep pushing their own designs they needed a new architecture, and ARM64 was their best option. The modern SVE extensions were co-designed by ARM and Fujitsu based on their HPC experience.
fulafel 3y ago
Yep, the conventional (current) wisdom is that they hit compilers. Itanic was predicated (pun intended) on compilers being able to deliver the parallelism from existing C/C++ apps. It's pretty tragic how this has turned out. Still no mainstream CPU languages that are good for parallelism and all the action is happening in the GPU side with the tragic fragmented mutually incompatible buggy properietary dev stacks (and C++ baggage to top it off), going on for 15+ years.

chasil 3y ago

I wonder how ARM, so relatively late with AArch64, was able to compel Fujitsu to take the instruction set to the heights of the top-performing supercomputer. I understand that there are exotic addressing modes involved. I'm not versed enough to understand. https://en.m.wikipedia.org/wiki/Fugaku_(supercomputer) https://en.m.wikipedia.org/wiki/Fugaku_(supercomputer)

pezezin 3y ago
Fujitsu was using their own in-house SPARC designs with custom vector instructions, but they could see that SPARC is dead and has no future. In fact, not that long ago they announced that they will stop sales in 2029 and support 5 years later: https://www.fujitsu.com/global/products/computing/servers/unix/sparc/key-reports/roadmap/index.html https://www.fujitsu.com/global/products/computing/servers/un... So if they wanted to keep pushing their own designs they needed a new architecture, and ARM64 was their best option. The modern SVE extensions were co-designed by ARM and Fujitsu based on their HPC experience.

fulafel 3y ago

Yep, the conventional (current) wisdom is that they hit compilers. Itanic was predicated (pun intended) on compilers being able to deliver the parallelism from existing C/C++ apps. It's pretty tragic how this has turned out. Still no mainstream CPU languages that are good for parallelism and all the action is happening in the GPU side with the tragic fragmented mutually incompatible buggy properietary dev stacks (and C++ baggage to top it off), going on for 15+ years.