10 ms·

CTRL+F "transmeta crusoe": Not found ah well

by velcrovan 4y ago

mrintellectual 4y ago
My vote for worst CPU goes to the iAPX 432 (also not on this list).
- Max-q 4y ago
  When I saw the headline I expected the iAPX to be number one on the list.
- sidewndr46 4y ago
  I was looking for this as well. It should be on there for introducing a completely new architecture, costing more, and underperforming contemporary products from Intel's catalog.
- jandrese 4y ago
  Wow, a garbage collector implemented inside of the processor. Chip level support for objects. You can't fault Intel for their ambition here, just their common sense. And the whole thing is built for a world where everybody is writing code in Ada. I bet some compiler makers were salivating at the prospect of collecting all of those huge license fees from developers.
  - Taniwha 4y ago
    It was a different time - memory/CPU speed trade-offs were very different - we saw RISC once we were able to move cache on-chip (or very very close) - but at that point CISC made sense and the 432 pushed CISC to the extreme. IMHO the x86 won out (an d is still with us) because of all the CISCs of its time it was the closest to RISC when memory started to get a lot faster (almost all instructions make at most 1 memory access, few esoteric memory operations etc)
    - Thetawaves 4y ago
      All instructions take at least 1 memory access. All instructions that do memory access need at least 2 memory accesses.
  - p_l 4y ago
    I once encountered a note from one of the people working on iAPX 432, claiming that the core idea of high level cpu wasn't really the issue it tanked, but project mismanagement and horrible design applied which resulted in a chip that would be technologically at home... In 1960s, just done in VLSI - one of the things I recall were issues with actual physical implementation of the memory data paths resulting in horrible IPC
- ncmncm 4y ago
  Isn't the i860 the inheritor of iAPX 432 design details?
UmbertoNoEco 4y ago
Oh those were the days were I was young and naive and I thought Linus was going to change the world (again) blurring the lines between 'software' and 'hardware'
hajile 4y ago
I think transmeta was MUCH better than Itanium. Itanium held the idea that we could accurately predict ILP at compile time (when the halting problem clearly states that we cannot). Transmeta said VLIW has the best theoretical PPA possible, so let's wrap that in a large, programmable JIT to analyze/optimize stuff to take advantage. Modern CPUs run quite a bit closer to transmeta, but they largely use fixed-function hardware rather than being able to improve performance at a later time. If we could nail down that ideal VLIW architecture, we could sell a given chip at various process sizes and then offer various paid "software" upgrades or compatibility packs for various ISAs to run legacy code. At least there's a pipe dream worth looking into.
- cogman10 4y ago
  > Itanium held the idea that we could accurately predict ILP at compile time (when the halting problem clearly states that we cannot). I don't know where these notions are coming from. Compilers can (and do) reorder instructions to extract as much parallelism as possible. Further, SIMD has forced most compilers down a path of figuring out how to parallelize, at the instruction level, the processing of data. Further, most CPUs now-a-days are doing instruction reordering to try and extract as much instruction level parallelism out as possible. Figuring out what instructions can be run in parallel is a data dependency problem, one that compilers have been solving for years. Side note: the instruction reordering actually poses a problem for parallel code. Language writers and compiler writers have to be extra careful about putting up "fences" to make sure a read or write isn't happening outside a critical section when it shouldn't be.
  - p_l 4y ago
    The critical difference is that EPIC (the architecture model of Itanium) essentially exposed CPU pipelines naked to the code - so you didn't just have to reorder instructions as optimizers do today, you also had to figure out changes that experience so far suggests is doable either in hw with runtime-only data, or in very tight numerical code. This includes compiler taking the place of branch predictor as well as OOOE scheduling, as well as no on-cpu instruction reordering or out of order retirement, and IIRC a branch mispredict was quite costly. More over, EPIC pretty much meant thar you couldn't apply similar chip-level IPC improvements as you could elsewhere, at least originally.
deleted 4y ago
[deleted]
pengaru 4y ago
I had a Transmeta Crusoe based PC104 SBC and for the time it was relatively quick for something low power, does it really deserve to be in the "worst cpus ever" list? why for?
- velcrovan 4y ago
  You’re right. I was kind of being snarky. But it was a huge disappointment compared against the promises from Transmeta and the tech journalism of the time.

CTRL+F "transmeta crusoe": Not found ah well

mrintellectual 4y ago

My vote for worst CPU goes to the iAPX 432 (also not on this list).

Max-q 4y ago
When I saw the headline I expected the iAPX to be number one on the list.
sidewndr46 4y ago
I was looking for this as well. It should be on there for introducing a completely new architecture, costing more, and underperforming contemporary products from Intel's catalog.
jandrese 4y ago
Wow, a garbage collector implemented inside of the processor. Chip level support for objects. You can't fault Intel for their ambition here, just their common sense. And the whole thing is built for a world where everybody is writing code in Ada. I bet some compiler makers were salivating at the prospect of collecting all of those huge license fees from developers.
- Taniwha 4y ago
  It was a different time - memory/CPU speed trade-offs were very different - we saw RISC once we were able to move cache on-chip (or very very close) - but at that point CISC made sense and the 432 pushed CISC to the extreme. IMHO the x86 won out (an d is still with us) because of all the CISCs of its time it was the closest to RISC when memory started to get a lot faster (almost all instructions make at most 1 memory access, few esoteric memory operations etc)
  - Thetawaves 4y ago
    All instructions take at least 1 memory access. All instructions that do memory access need at least 2 memory accesses.
- p_l 4y ago
  I once encountered a note from one of the people working on iAPX 432, claiming that the core idea of high level cpu wasn't really the issue it tanked, but project mismanagement and horrible design applied which resulted in a chip that would be technologically at home... In 1960s, just done in VLSI - one of the things I recall were issues with actual physical implementation of the memory data paths resulting in horrible IPC
ncmncm 4y ago
Isn't the i860 the inheritor of iAPX 432 design details?

UmbertoNoEco 4y ago

Oh those were the days were I was young and naive and I thought Linus was going to change the world (again) blurring the lines between 'software' and 'hardware'

hajile 4y ago

I think transmeta was MUCH better than Itanium. Itanium held the idea that we could accurately predict ILP at compile time (when the halting problem clearly states that we cannot). Transmeta said VLIW has the best theoretical PPA possible, so let's wrap that in a large, programmable JIT to analyze/optimize stuff to take advantage. Modern CPUs run quite a bit closer to transmeta, but they largely use fixed-function hardware rather than being able to improve performance at a later time. If we could nail down that ideal VLIW architecture, we could sell a given chip at various process sizes and then offer various paid "software" upgrades or compatibility packs for various ISAs to run legacy code. At least there's a pipe dream worth looking into.

cogman10 4y ago
> Itanium held the idea that we could accurately predict ILP at compile time (when the halting problem clearly states that we cannot). I don't know where these notions are coming from. Compilers can (and do) reorder instructions to extract as much parallelism as possible. Further, SIMD has forced most compilers down a path of figuring out how to parallelize, at the instruction level, the processing of data. Further, most CPUs now-a-days are doing instruction reordering to try and extract as much instruction level parallelism out as possible. Figuring out what instructions can be run in parallel is a data dependency problem, one that compilers have been solving for years. Side note: the instruction reordering actually poses a problem for parallel code. Language writers and compiler writers have to be extra careful about putting up "fences" to make sure a read or write isn't happening outside a critical section when it shouldn't be.
- p_l 4y ago
  The critical difference is that EPIC (the architecture model of Itanium) essentially exposed CPU pipelines naked to the code - so you didn't just have to reorder instructions as optimizers do today, you also had to figure out changes that experience so far suggests is doable either in hw with runtime-only data, or in very tight numerical code. This includes compiler taking the place of branch predictor as well as OOOE scheduling, as well as no on-cpu instruction reordering or out of order retirement, and IIRC a branch mispredict was quite costly. More over, EPIC pretty much meant thar you couldn't apply similar chip-level IPC improvements as you could elsewhere, at least originally.

deleted 4y ago

[deleted]

pengaru 4y ago

I had a Transmeta Crusoe based PC104 SBC and for the time it was relatively quick for something low power, does it really deserve to be in the "worst cpus ever" list? why for?

velcrovan 4y ago
You’re right. I was kind of being snarky. But it was a huge disappointment compared against the promises from Transmeta and the tech journalism of the time.