Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What happened to Transmeta, the last big dotcom IPO

dfarq.homeip.net

Post reply on HN
Print view View original

101–110 of 156 posts

Re: What happened to Transmeta, the last big dotcom IPO

#101

Post by monocasa »

pizlonator wrote: post #93
monocasa wrote: post #88

Earlier quoted context omitted.

Skewed execution are just different traces. Basic blocks don't have a requirement that they don't partially overlap with other basic blocks. You want that anyway for optimization reasons even without skewed execution. Self modifying code is handled with MMU traps on the writes, and invalidation of the relevant traces. It is very much a slow path though. Ideally heavy self modfying code is able to stay in the interpre…

> Self modifying code is handled with MMU traps on the writes, and invalidation of the relevant traces. It is very much a slow path though. Ideally heavy self modfying code is able to stay in the interpreter though and not thrash in and out of the compiler. This might end up having a bad time running JavaScript VM JITed code, which self-modifies a lot. But all of that makes sense! Thanks!

Yeah, nesting JITs was kind of always an Achilles heel of this kind of architecture.

IIRC, they had a research project to look at shipping a custom JVM that compiled straight to their internal ISA to skip the impedance mismatch between two JITs. JITed JS (or really any extremely dynamic code that also asks for high perf) probably wasn't even on their radar given the era with even the SmallTalk VM that HotSpot derived from being a strongly typed derivative of SmallTalk.

Re: What happened to Transmeta, the last big dotcom IPO

#102

Post by hinkley »

actionfromafar wrote: post #49
gdiamos wrote: post #6

Transmeta made a technology bet that dynamic compilation could beat OOO super scalar CPUs in SPEC. It was wrong, but it was controversial among experts at the time. I’m glad that they tried it even though it turned out to be wrong. Many of the lessons learned are documented in systems conferences and incorporated into modern designs, ie GPUs. To me transmeta is a great example of a venture investment. If it would hav…

Did anyone try dynamic recompilation from x86 to x86? Like a JIT taking advantage of the fact that the target ISA is compatible with with the source ISA.

I believe it was HP who accidentally tried this while making an early equivalent of Rosetta to deal with a hardware change on their mainframes and mini computers. They modified it to run same-same translations and they did get notable performance improvements by doing so.

I’m pretty sure this experiment happened before Transmeta existed, or when it was still forming. So it ended up being evidence that what they were doing might work. It also was evidence that Java wasn’t completely insane to exist.

Re: What happened to Transmeta, the last big dotcom IPO

#104

Post by andrewf »

gdiamos wrote: post #6

Transmeta made a technology bet that dynamic compilation could beat OOO super scalar CPUs in SPEC. It was wrong, but it was controversial among experts at the time. I’m glad that they tried it even though it turned out to be wrong. Many of the lessons learned are documented in systems conferences and incorporated into modern designs, ie GPUs. To me transmeta is a great example of a venture investment. If it would hav…

At the time I recall https://dl.acm.org/doi/pdf/10.1145/301631.301683 being an oft-discussed data point - speeding up DEC Alpha code by recompiling it into different DEC Alpha code using runtime statistics.

This was commonly cited in forum debates about whether Java and C# could come close to the performance of compiled languages. ("JITs and GCs are fast enough, and runtime stats mean they can even be faster!" was a common refrain, but not actually as true in 1999 as it is in 2025)

Re: What happened to Transmeta, the last big dotcom IPO

#105

Post by dlcarrier »

sophacles wrote: post #87
dlcarrier wrote: post #37

TL;DR: What happened to Transmeta was that in 2005, Transmeta shifted to licensing intellectual property rather than selling CPUs. …they became a patent troll

Nonsense. They are licensing IP they created. Thats different qualitatively and quantitatively than buying patent rights for cheap (since the even the original patent holders didn't think it was worth much) and suing random people who happen to use a product that may infringe on the patent.

If their patent portfolio wasn't being used for patent trolling, why is it currently owned by Intellectual Ventures, once called "the ultimate patent troll" by journalists. (https://www.theverge.com/2014/2/4/5375304/intellectual-ventu...)

Re: What happened to Transmeta, the last big dotcom IPO

#106

Post by CalChris »

gdiamos wrote: post #6

Transmeta made a technology bet that dynamic compilation could beat OOO super scalar CPUs in SPEC. It was wrong, but it was controversial among experts at the time. I’m glad that they tried it even though it turned out to be wrong. Many of the lessons learned are documented in systems conferences and incorporated into modern designs, ie GPUs. To me transmeta is a great example of a venture investment. If it would hav…

A 700 MHz Crusoe TM5400 delivered roughly the same performance as a 500 MHz Pentium III on SPEC benchmarks.

Transmeta as a startup (the pitch to early investors) went after high performance and maybe that could be construed as DC could beat OOO. But the released product pivoted (like that hasn't happened before) to low power, hence the name Efficeon. Its killer app was playing a DVD on a laptop on a cross country flight without running out of battery and without frying your own laptop. They basically invented that market which then gave them the great good pleasure of competing with Intel.

It was a heroic doomed effort. Brought to its attention, Intel quickly adapted to that market. Game, set, match. Ditzel became a VP at Intel.

Re: What happened to Transmeta, the last big dotcom IPO

#107

Post by rugina »

vlovich123 wrote: post #98
cpgxiii wrote: post #57

Earlier quoted context omitted.

> However, if you add it onto a better CPU it’s a fine technique to bet on - case in point Apple’s move away from Intel onto homegrown CPUs. I don't think Apple is a good example here. Arm was extremely well-established when Apple began its own phone/tablet CPU designs. By the time Macs began to transition, much of their developer ecosystem was already familiar. Apple's CPUs are actually notably conservative when com…

I think your focusing on the details and missing my broader point - the JIT technique for translation only works to break out of the instruction set lock-in. It does not improve performance, so betting on that instead of super scalar designs is not wise. Transmeta’s CPU was not performance competitive and thus had no path to success. And as for Apple itself, they had built the first iPhone on top of ARM to begin with…

> partially because Intel didn’t see a market

I saw some articles saying that Intel saw the market very well, they just could not deliver and rather than admit that, they claimed the CEO decided wrong.

Re: What happened to Transmeta, the last big dotcom IPO

#108

Post by vlovich123 »

rugina wrote: post #107
vlovich123 wrote: post #98

Earlier quoted context omitted.

I think your focusing on the details and missing my broader point - the JIT technique for translation only works to break out of the instruction set lock-in. It does not improve performance, so betting on that instead of super scalar designs is not wise. Transmeta’s CPU was not performance competitive and thus had no path to success. And as for Apple itself, they had built the first iPhone on top of ARM to begin with…

> partially because Intel didn’t see a market I saw some articles saying that Intel saw the market very well, they just could not deliver and rather than admit that, they claimed the CEO decided wrong.

Both were probably true to some extent but I doubt they wouldn’t have figured out a way to execute given the huge opportunity.

The mobile CPU market worth is a meaningful chunk of Intel’s overall current market cap and they’re not participating.

Re: What happened to Transmeta, the last big dotcom IPO

#109

Post by btilly »

hinkley wrote: post #99
btilly wrote: post #63

Earlier quoted context omitted.

That's kind of the bet they made, but misses a key point. Their fundamental idea was that by having simpler CPUs, they could iterate on Moore's law more quickly. And eventually they would win on performance. Not just on a few speculative edge cases, but overall. The dynamic compilation was needed to be able to run existing software on it. The first iterations, of course, would be slower. And so their initial market,…

Intel was already built on the Pentium at this point. Not as iterable as pure software but decoding x86 instructions to whatever they wanted to do internally sped up a lot of things on its own. Perhaps they would have been better off building the decode logic as programmable by making effectively a multicore machine where the translation code ran on its own processor with its own cache, instead of a pure JIT.

When you are operating at that level, there is a lot of similarity between software compiled to machine code, and software compiled to a chip design. The differences are that the machine code comes with some extra overhead, and changing chip designs takes more work.

Fundamentally Transmeta to make iterations of designs quicker, at the cost of some performance overhead. What Intel chose that extra low level performance, at the cost of overhead on iterations. And then Intel made up for the extra cost of iterating designs by having more resources to throw at the problem.

If Transmeta had equivalent resources to throw at their approach, they would have likely won. But they didn't. And I think that they made the right choices for the situation that they were in.

Incidentally the idea of programmable microcode on top of the CPU was not original. It was used in all sorts of software systems before them. Such as Java. The first big use that I'm aware of was the IBM 360, back in the 1960s. There are still programs running on mainframes today that fundamentally think that they are running on that virtual machine from the 1960s!

Re: What happened to Transmeta, the last big dotcom IPO

#110

Post by cpgxiii »

nostrademons wrote: post #89
fajitaforce5 wrote: post #83

Earlier quoted context omitted.

I was an intel cpu architect when transmeta started making claims. We were baffled by those claims. We were pushing the limit of our pipelines to get incremental gains and they were claiming to beat a dedicated arch on the fly! None of their claims made sense to ANYONE with a shred of cpu arch experience. I think your summary has rose colored lenses, or reflects the layman’s perspective.

I think this is a classic hill-climbing dilemma. If you start in the same place, and one org has worked very hard and spent a lot of money optimizing the system, they will probably come out on top. But if you start in a different place, reimagining the problem from first principles, you may or may not find yourself with a taller hill to climb. Decisions made very early on in your hill-climbing process lock you in to…

> It's worth noting that Google actually did succeed with a wildly different architecture a couple years later. They figured "Well, if CPU performance is hitting a wall - why use just one CPU? Why not put together thousands of commodity CPUs that individually are not that powerful, and then use software to distribute workloads across those CPUs?" And the obvious objection to that is "If we did that, it won't be compatible with all the products out there that depend upon x86 binary compatibility", and Google's response was the ultimate in hubris: "Well we'll just build new products then, ones that are bigger and better than the whole industry." Miraculously it worked, and made a multi-trillion-dollar company (multiple multi-trillion-dollar companies, if you now consider how AWS, Facebook, TSMC, and NVidia revenue depends upon the cloud).

Except "the cloud" at that point was specifically just a large number of normal desktop-architecture machines. Specifically not a new ISA or machine type, running entirely normal OS and libraries. At no point did Google or Amazon or Microsoft make people port/rewrite all of their software for cloud deployment.

At the point that Google's "bunch of cheap computers" was new, CPU performance was still rapidly improving. The competition was traditional "big iron" or mainframe systems, and the novelty was in achieving high reliability through distribution, rather than building on fault-tolerant hardware. By the time the rate of CPU performance improvement was slowing in the mid 2000s, large clusters smaller machines were omnipresent in supercomputing and HPC applications.

The real "new architecture(s)" of this century are GPUs, but much of the development and success of them is the result of many iterations and a lot of convergent evolution.

Post reply on HN