3 ms·

Eh, the Transmeta Crusoe (first gen) processors had pretty decent performance compared to Pentium M at much lower TDP. The Transmeta Efficeon (second gen) had p

by PeCaN 9y ago

Eh, the Transmeta Crusoe (first gen) processors had pretty decent performance compared to Pentium M at much lower TDP. The Transmeta Efficeon (second gen) had performance comparable to bigger processors but had some thermal issues that hindered it a fair bit. Efficeon kinda lost Transmeta's original goal of decent performance at lower power consumption, and they went downhill afterwards. They weren't great but for a small, ambitious company without much chance to iterate they definitely weren't bad. The technology got incorporated into NVIDIA's Project Denver ARM chips, which were very fast… sometimes. Actually, Denver 2 is shipping in the new Jetson devkit, but I haven't seen much about that or been able to get my hands on one. That's the general problem with VLIW chips, is that they're amazing on some workloads and pretty bad on others. Itanium, for all its faults, was by far the best general-purpose VLIW CPU.

FullyFunctional 9y ago
Thanks for the rare fair comment. People are quick to forget the difference between concept and implementation. The Transmeta concept was clearly viable, but the implementation needed more iterations to before we can fully judge the concept. Your comment about VLIW is true, but in this case that was a 2nd order effect. Far far worse was The effect of the JIT (CMS): a small kernel running over a long time (e.g., DVD playback) would work absolutely excellently, even on the Crusoe, whereas a large codebase with relatively little reuse (say, Word) would give very uneven performance. This problem was never solved [at Transmeta]. The irony is that today, x86 compability is irrelevant in most places.
- PeCaN 9y ago
  Yeah, code-morphing/hardware JIT is extra weird (and probably why Nvidia's Project Denver kinda tanked—turns out, that doesn't work too great for smartphone apps). One thing I've thought about is having a code-morphing CPU as a sort of accelerator that a single process could be offloaded to (of course, this would require an OS that can marshal processes). Think a database server, a JVM, NodeJS—long-running processes that would benefit from JIT. Might even be viable with upcoming cache-coherent interconnects like CCIX and GenZ. A more ambitious implementation could offload groups of functions.

by PeCaN 9y ago

FullyFunctional 9y ago

Thanks for the rare fair comment. People are quick to forget the difference between concept and implementation. The Transmeta concept was clearly viable, but the implementation needed more iterations to before we can fully judge the concept. Your comment about VLIW is true, but in this case that was a 2nd order effect. Far far worse was The effect of the JIT (CMS): a small kernel running over a long time (e.g., DVD playback) would work absolutely excellently, even on the Crusoe, whereas a large codebase with relatively little reuse (say, Word) would give very uneven performance. This problem was never solved [at Transmeta]. The irony is that today, x86 compability is irrelevant in most places.

PeCaN 9y ago
Yeah, code-morphing/hardware JIT is extra weird (and probably why Nvidia's Project Denver kinda tanked—turns out, that doesn't work too great for smartphone apps). One thing I've thought about is having a code-morphing CPU as a sort of accelerator that a single process could be offloaded to (of course, this would require an OS that can marshal processes). Think a database server, a JVM, NodeJS—long-running processes that would benefit from JIT. Might even be viable with upcoming cache-coherent interconnects like CCIX and GenZ. A more ambitious implementation could offload groups of functions.