4 ms·
I was there from 2001 until the end (roughly). History is written by the winners and outsiders tend to draw technology conclusions based business outcome, whic
by FullyFunctional 6y ago
I was there from 2001 until the end (roughly).
History is written by the winners and outsiders tend to draw technology conclusions based business outcome, which is unfortunate and lacking in nuance.
Crusoe at the time of the release was far more power efficient than anything Intel had to offer and was a revolution to the notebook market. Intel has officially credited Transmeta's LongRun as the motivation for creating SpeedStep.
Performance of Crusoe ("Fred") fell short of the expectations as the approach assumed a faster VLIW core. CMS was very good, but couldn't compensate for the hardware. Had Transmeta not made terrible business screw-ups, the architecture could perhaps have had the iterations necessary the improve the technology. The third generation ("Tokomak") would have been significantly better and almost happened, except for ... business reasons.
IMhO, the original approach has two flaws:
1. Software based interpretation of cold code leads to a dramatic performance difference that can be nearly impossible to catch up to for some applications. IOW, the difference between worst and best performance is much too big.
2. Out-of-order execution is a much simpler and better way to deal with cache misses. The tricks and efforts that went into the architecture to compensate for the in-order execution were mind-boggling and were part of the reason the core was slower than it should have been.
NVIDIA's Denver improved (fixed?) 1. by added hardware acceleration for Arm decoding.
- jecel 6y agoAbout bad business decisions, I have read that some were made for them by others. They were using IBM as their foundry and a new head of IBM's semiconductor department decided to cancel CMOS to focus exclusively on SOI. Now Transmeta couldn't ship to customers until they did a new design for some other foundry. I have no idea how much this was actually the case.
- FullyFunctional 6y ago(edited) Hmm, if that's true it would be news to me. Do you have a reference? addendum: there's also the fact that Intel deployed many illegal tactics to block Transmeta from selling to customers. This is another large part of why Transmeta failed. It seems entirely plausible that Intel pressured IBM to drop Transmeta as a customer.
- jecel 6y agoFound it (Google didn't help at all) on page 19 of the oral history of David Ditzel at the computer history museum. https://archive.computerhistory.org/resources/access/text/2016/07/102737949-05-01-acc.pdf https://archive.computerhistory.org/resources/access/text/20... But I sort of remembered it wrong. Here he talks about having to switch from IBM but in page 16 he talks about the new lab not being able to make chips for a whole year as being the problem. "In the end, Transmeta didn't make it, and I'll just say here I think it was not because of the technologies. It actually turned out to be manufacturing problems. We switched fabs. The fab we switched to actually had a problem, and couldn't actually make our chips for a year. We had to prove where the issue was in the fab, and what was happening. They're not happy if I speak too much about those details. But, the technology itself worked fine."
- FullyFunctional 6y agoThat's a very important distinction. The person who made that fatal decision against the objections of many (no, it wasn't Dave) bear much of the responsibility of the death of Transmeta. It was reckless and ultimately a disaster.
- jecel 6y agoIn 1999 I set up a company to develop a VLIW processor that used adaptive compilation (but for Smalltalk bytecodes instead of x86 instructions). I was taken more seriously after Transmeta announced Crusoe, then a lot less seriously when it failed. Even though the reasons for that were not technical, everybody remembers it wrong.
- ethbro 6y agoCurious, would OoO execution been possible with CMS? It's complicated enough to resolve things when you're dealing with instructions + hardware execution units. When that becomes x86 instructions + CMS + native instructions + hardware execution units... it seems a daunting task to hit stability and outlier response targets for the system as a whole.
- FullyFunctional 6y agoThe whole thing was already incredibly complex: getting the x86 semantics and state right, generating perfectly scheduled P95 code that had the the most useful speculation - while avoiding known hazards in the hardware, etc. Using a speculative superscalar OoO would migrate part of the complexity from software to hardware. The major concern cited is usually power, but I don't know how much the renamer + scheduler would add relative to everything else; the hardware already had all the rest: extensive speculation support, branch predictors, large register file, store buffers, etc. It's a fascinating topic and this isn't the ideal forum. However my point is this: there are very few companies out that that tries something truly new, and when one does and fail in the market there too much "told you so" going around.
- ethbro 6y ago> However my point is this: there are very few companies out that that tries something truly new, and when one does and fail in the market there too much "told you so" going around. Absolutely agreed. And from what I hear, the spirit of Transmeta ended up in a lot of other places (either via cleanroom design of similar tech, personnel working on similar projects, or inspiration). People are also starting to wake up to the just how underhanded and illegal technology companies will behave to squash their competitors, whereas I think the 00s still had rose tinted glasses about the best technical product winning.
- FullyFunctional 6y agoThis is a little late, but this link is relevant: http://datasheets.chipdb.org/Transmeta/pdfs/Transmeta_Efficeon_Launch.pdf http://datasheets.chipdb.org/Transmeta/pdfs/Transmeta_Effice... I had forgotten just how short the pipe was (~ 7 stages!). Going OOO would have added at least one stage.