Slashdot Mirror
Torvalds's Former Company Transmeta Acquired and Gone
desmondhaynes sends along a posting from the TechWatch blog detailing the sale of Transmeta (most recently discussed here). Linus moved ten time-zones west, from Finland to Santa Clara, CA, to join Transmeta in March 1997, before this community existed. Here is our discussion of the announcement of the Crusoe processor from 2000. Our earliest discussion of Transmeta was the 13th Slashdot story. "Transmeta, once a sparkling startup that set out to beat Intel and AMD in mobile computing, announced that it will be acquired by Novafora. The company's most famous employee, Linux inventor Linus Torvalds, kept the buzz and rumor mill about the company throughout its stealth phase alive and guaranteed a flashy technology announcement in early 2000. Almost nine years later Transmeta's journey is over." Update: 11/21 16:25 GMT by KD : It's not the 13th Slashdot story, only the 13th currently in the database. We lost the first 4 months at one point.
Probably offset against debt.
The dangers of knowledge trigger emotional distress in human beings.
Most of their $250M is from a recent settlement with Intel. They won't be getting any more money from THAT source.
I'll just leave this here.
The dangers of knowledge trigger emotional distress in human beings.
Pretty sure they're talking about the Slashdot "community" -- Slashdot was founded in Sept 2007.
As much on slashdot this is self-referential, i.e. "this community" = Slashdot, and if you take this frame of reference "March 1997, before this community existed" is indeed correct:
"Hannibal's plans never work right. They just work." Amy/A-Team
and Intel ran them out of business like so many others.
Intel ran Cyrix, Centaur, out of business and they got bought out. Intel stopped NEC (Remember the V20 CPU that replaced the 8088?), and almost ran VIA and AMD out of business.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
The raw performance of the chips wasn't very good either. They were low power and low performance in a ratio that didn't provide any benefits over Intel's solutions.
Plus working with small companies for such a vital part, wasn't in apple's interest. I think Apple learned its lesson working with Motorola. As big as it was, Motorola couldn't fulfill apple's meager request for power pc chips, nor could it fund development of faster chips.
Well.. maybe. Or Maybe not. But Definitely not sort of.
That a small start up could take on Intel in a serious way?
Well, that wasn't what killed them. There are many stories of garage companies taking on the fat, lazy big boys and winning (Microsoft/Apple against IBM, for one).
What killed them was the Fundamentally Wrong Approach. They wanted to, in essence, make a "magic optimizer" that would take Intel instructions and convert them to run on a very simple, low-power device. The "magic optimizer" was left as an "exercise to the geniuses". The business plan for that consisted solely of hand waving. "Hey, we'll just hire smart people and let them figure it out."
Unfortunately, optimization is a notoriously difficult problem, and is really a subset of Strong A.I. No one programs in assembly language these days, so one really understands how bad compilers really are at producing code, compared to human optimized code. Computers are so fast and programmers are so expensive, so we don't really care anymore.
Taking assembly and trying to translate/recompile it into another very-low-level assembly and do this on-the-fly without any time or performance penalty is a fool's game. It was never going to work. I could probably even dig up my posts on this subject way back when. :)
See also: VLIW processors, where the hardware guys fool themselves by saying, "the software guys will figure out how to compile to it."
Sometimes it's best to just let stupid people be stupid.
Define "founding fathers".
Linus is a good programmer. There are several good programmers who could write a kernel, specially the kind he wrote.
The GNU project was well underway when he started working with Linux, so he was no needed to found any revolution. Maybe adoption of free software would have been slowed, but things would not be much worse w/o him.
But that was done on purpose, so they wouldn't hit the obvious wall that hurts all VLIW architectures: increasing IPC without changing the architecture, and without adding all the complex re-ordering logic seen in RISC-like superscalar processors. Once you get above one VLIW per clock, you have to throw the compiler's assumptions out the window, or you need to re-compile the code.
If you don't have to support the old architecture, you can change it to increase IPC without excessive overhead. This was the concept behind adding an interpreter layer between the chip and the OS. Of course, they didn't realize that they were trading one performance bugaboo for another: instead of making a bigger, more expensive chip, they sapped tons of performance doing x86 instruction transation and re-ordering in software. This cost them tons of performannce, as a lot of the time, their VLIW pipeline was only %50 filled.
Transmeta had the same problem Intel did with Itanium: with the exception of perfectly tailored code, the VLIW compiler couldn't keep processor resource utilization anywhere near %100. Transmeta had one additional problem over Intel: their compiler had to work in REAL TIME, with a tiny 16 or 32MB buffer. It's no wonder they got toasted by the x86 market..Itanium, even with Intel backing, is on the way to a similar fate.
Man is the animal that laughs.
And occasionally whores for Karma.
Nothing could be further from the truth. Out of the five major components of the Crusoe firmware -- the dynamic translator, interpreter, nucleus (mini-OS), virtual I/O, and out-of-line handlers ("microcode"), Linus was the driving force, designer and primary implementor of one (the interpreter.) He eventually transitioned into an "advanced research" role, working on more "far out" projects.
You might find this link interesting.
For anyone who's interested in Mr. Byrne slating the song here you go.
Comedians the world over must have kicked themselves when they first saw Ed' routine. A collective "D'oh! Why didn't I think of that!"
As Ed says, the only thing ironic about that song is that it was a song about irony written by someone who doesn't know what irony is.
"Three eyes are better than one" -- Lieutenant Columbo
What killed Transmeta was a few things things:
Transmeta felt they were taking too many risks on the software side, and adopted a hyper-conservative culture on the hardware side. The result ended up being both late and below target. All the software optimizations in the world could not help push more operations down the pipe than it could actually perform.
As time went on, the cost of x86 decode and scheduling in hardware went down, and the cost of memory performance -- caching systems, and so on -- went up. The VLIW instruction set consumed more icache than the native x86 instruction set.
The best design in the world doesn't help if your fab partner don't deliver for their own design rules.
RISC machines made sense before Intel figured out to make x86 go faster than one instruction per clock.
That's not what made RISC fade into the background.
RISC was about tradeoffs: Do only very simple instructions and you can do them very fast with a small amount of logic (which makes you even faster). Then trade this for occasionally doing several instructions instead of one and you're still ahead.
The smaller machine also means you can move to the next, still faster, logic family while the yeild is still low - because with a low-area design you can get enough working devices off a wafer to go to market when larger design would still be impractical because it's too big a target, so nearly every chip on the die is defective. Again you end up faster and/or better crunch/watt.
What brought CISC back is that semiconductor tech got to where you COULD get decent yields on chips with a LOT of transistors and running very fast. So what do you do with them? With RISC about all you can do is integrate peripherals and memory, add coprocessors (trending toward a CISC design again), or put large numbers of parallel cores on a chip. (But not all algorithms are parallelizable.) Meanwhile, CISC designs can go wide, throwing extra logic into building parallel data paths while launching, scheduling, and mediating between multiple instructions (even if multi-cycle). So a CISC design could use the extra logic to gain performance even in non-parallelizable algorithms.
Which is not to say that RISC machines ever really went away. They still kept getting faster (though they lost the advantage they once had). They're in heavy use where they're fast enough, especially where power, space, and cooling are limited (like in peripherals and portable devices). Also there are chips composed of arrays of them in both current production and future development, doing things that ARE parallizable (such as packet handling in large routers).
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
What model did you have? I own a sony c1 picturebook with a first-gen crusoe. Very slow, but it got impressive battery life (at the time) and ran very cool. The entire unit had one fan about the size of a quarter which only ran when the cpu was maxed out. The rest of the time you could barely hear it idling. Of course the horrible hard drive (10x louder than the fan, slow, unreliable) more than made up for it...
And PII@233 sounds about right speed-wise.
I consider crusoe the perfect example of an idea that looks wonderful on paper and utterly fails in execution.