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.

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.

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.

Transmeta CPUs used a VLIW architecture with a software layer that decoded x86 instructions into VLIW instructions. The software worked a bit like a JIT where optimizations would be applied to frequently running code.

I would credit them for pushing Intel (and AMD) to optimize for power savings rather than raw speed, because Intel started making significant perf/W improvements.

Transmeta processors were (I believe) the first x86 processors to automatically vary voltage and clock speed multiple times per second. In fact, I wrote a small utility that would display the current clock speed on your taskbar in a graph because it changed so rapidly.

It was a cool idea. That was its point, lower power for acceptable performance. It wasn't trying to be the fastest; their value proposition was being able to play a DVD on a SF NY flight on battery. But Intel pivoted and did that too.

The problem was that back then the platform (chipset, etc) consumed a significant amount of power as well, so even dropping the processor to Atom level TDP couldn't really achieve that much given the rest of the system.

Leading to some "interesting" outcomes.

Anyone remember Moblin? Apparently Intel started work on that Linux distro because Microsoft balked regarding an x86 platform without PCI device lookup. And Intel removed the PCI stuff in an effort to cut power drain.

As an aside, running windows on ARM to this day require special SoCs.

The Transmeta Crusoe also included most of the features of the "chipset", it had PCI and memory controller built in at a time when other manufacturers' CPUs didn't.

You still needed to add a display controller but that was true of all the competing CPUs too.