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.
that something Linus worked on was a failure.
You mean he's human after all?
Oh the humanity.
From the article:
Transmeta today announced that Novafora will acquire Transmeta and its assets for $255.6 million in cash.
Transmeta's cash, cash equivalents and short term investments at September 30, 2008 totaled $255.2 million.
So, the entire worth of the company intellectual property was about $0.4M?
Layne
Whot?
If you mod this up, your slashdot background will turn into a beautiful sunset!
...it's ironic that the man who much of the world considers one of the primary founding fathers of the Open Source revolution, seems to have wasted so many productive years of his young adulthood working for a company that fizzled out into vaporware?
You are a liar and an idiot. Learn to fucking read your clueless fucking piece of shit morong. Fuck you and your descendents for 100 generations. You are a total piece of shit.
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
This may not be a done deal. Some stockholders are suing, trying to block the sale, because the price is equivalent to the cash on hand, investments, and tangible assets. It appears to value the IP at $0 and the stockholders think Transmeta is worth more.
For me, the real problem is that when you sacrificing babies using Linux, they all have to be sacrificed to GPL dieties. This makes the GPL a real ball and chain. With Windows, your baby sacrificing is less constrained. Sure you need to tithe a modest 80% of your baby sacrifices to the dark lords of Redmond, but the rest can be to whomever you desire as long as it's not an open source diety. So seriously, what's not to love with Windows? And the UI is so much better.
Makes me feel old... oh wait I am. Crap.
Have you looked at BSD instead? Its an open free operating system, but the licence allows you to not publish any changes you make to it. There are many flavours to choose from, OpenBSD, NetBSD, FreeBSD, and DragonflyBSD.
it's kinda sad. They tried. But the juggernauts ran them right over. Their technology was gee-whizzy and innovative. But they had a hard job getting anybody to buy into such a radical change.
That a small start up could take on Intel in a serious way? Sure you can make processors for some narrowly defined market that Intel might not be interested in pursuing. But at the time (this was before Pentium M and Centrino) Intel's mobile offerings were embarssing, and Intel was hurting to push something out quickly that could solve the mobile problem. Even at that time laptops were consider the wave of the future, and I think we can safely assume that Intel and AMD both realized that the laptop market was only going to grow much larger.
Do you really jump in between Intel and AMD when they are both scrambling to come out with a solution first for a low power mobile chip with good performance? It didn't make sense to me then, and it doesn't make sense looking back on it.
Sorry to be so critical of Transmeta, but I really couldn't see them achieving anything more than Cyrix/VIA with the Crusoe architecture, as novel as it was.
The only thing that I thought might save them from the beating they received from Intel was the Efficeon. Having worked with product development for blades and modules, there are some serious power constraints in many of these products. And if you can get even a few more MIPS per Watt it can make the difference between being able to run an application or not. For application-oriented blades and modules (for example, Cisco NM, AIM and blades) the ability to have a little more oomph means you can offer more connections per blade or more features or do products that you could not do before. (afaik Cisco never used the Efficeon)
“Common sense is not so common.” — Voltaire
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.
Yet another buyout.... The problem here is that we now are (actually, almost always were) in a duopoly shared by Intel and AMD. Let's see if another processor company emerges in the future... How about that chinese company?
Archives go back to December 31, 1997 but the site itself goes back to September. So I don't think that was the real 13th story.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Did anyone seriously think that 2 students would be able to take on Yahoo and MS and win?
Our earliest discussion of Transmeta was the 13th Slashdot story. And without any comments too! This could my very chance to get in a first post! mwahAHAHAHA!
If you count something as "wasted" just because it was a part of something that failed many years later, then virtually all of humanity's efforts are wasted in the long run.
E.g., what was the point of building cities and inventing civilization in Mesopotamia, since millenia later it fell to the semitic populations, then to the iranians (indo-europeans), and finally to the arabs? Even Sumerian, the language of the first human civilization, soon was a dead language kept just for religious services and texts. (Much like what millenia later would happen to Latin.) Was Hammurabi's life wasted on working on that law code and construction and whatnot, since he worked for Babylon which later got conquered by Assyria and today is just a bunch of ruins?
Was the life of every Roman that ever lived wasted, because their country would eventually implode and be conquered by a tribe as primitive as the Longobards?
Was Egipt all a big waste for that same reason?
Sometimes it makes sense to live in the present. It matters what you do now, not what will become of it in 10 years. What may make a difference in the long run is that you were one of the guys who tried and contributed a bit to the advancement of technology/culture/whatever, not whether you left some monumental legacy that will for ever be intact. Because if you're aiming for the latter, you might as well give up now, 'cause in the long run everything turns to dust.
Even the the Great Lighthouse, or the Colosus of Rhodes, or whatever, eventually turned to little more than ruins or disappeared altogether. Was it a waste of someone's years to build them? Well, no, they served their purpose while they existed, _and_ more importantly humanity learned something new in the process. Even if it's how to stack a lot of bricks to build a f-ing huge lighthouse. The road to the mighty gothic cathedrals of later, or to the Hagia Sophia, goes through such earlier achievements. Even if the grand monumental testament to someone's work is gone, their contribution to the species' knowledge lived on and accumulated.
Plus, in this case we're not even talking about some personal failure, but the failure of one company he worked for. Well, gee.
A polar bear is a cartesian bear after a coordinate transform.
People like you said the same thing about Nvidia. Sometimes it works, others not. I'd like to see your international corporation and IP, almighty one.
Yes. The web search/advertising market was very young, Yahoo! and MS's search engines sucked, their designs were fundamentally wrong for the direction the web was going, they showed no indication that they were going to make any meaningful changes.
The CPU market was not young, Intel and AMD had decent products, and they were pouring resources into R&D.
Go green: turn off your refrigerator.
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.
Linus Torvalds formerly owned a company.
Linus Torvalds' former company was acquired.
Whats really ironic is a song called Ironic with no irony in it at all.
The days of the digital watch are numbered.
huh? ... you might not have been here but we existed...
I remember reading with anticipation as to where he was gonna work when he graduated. At the time rumors abounded...
albeit back then it was a lot more relevant...
RISC machines made sense before Intel figured out to make x86 go faster than one instruction per clock. That happened with the Pentium Pro, which came out in 1995. (The Pentium II and III were basically Pentium Pro architecture, shrunk down to a single die in a newer fab.) Transmeta didn't announce a product until 2000.
Before the Pentium Pro, RISC architectures seemed to be the way forward. The RISC designs could get down to one instruction per clock, and they weren't that hard to design, because all the hard cases were prohibited. I met the design team for one of the MIPS CPU parts, and it was about 15 people.
Intel took on the insanely hard problem of making a superscalar x86 CPU. All the awful things that can happen in x86 code had to be handled, and not only handled, handled fast. The internal complexity of the Pentium Pro/II/III is huge. It took a design team of 3000 people at peak to bring it off, and a huge transistor count in the CPU. Yet they did it. With that architecture, they could beat one instruction per clock, which blew away the whole rationale for nice, simple RISC machines. Transistors on the chip had become cheap enough that a CPU with 5.5 million transistors was commercially feasible.
Along with blowing away RISC, that technology blew away Transmeta. Transmeta had an OK idea, but they were five years too late.
Compilers are actually extremely good. I'm pretty sure it's been a while since a compiler can beat most of the hand-written assembly out there, unless it's written by a true guru (and there's very very few of them out there - not because assembly is not as common, but because it's hard to write optimized code).
In fact, even all modern x86, from what I've read, have for a long time been doing translation. None of them do CISC internally anymore, instead having a RISC-translation layer because there's plenty of die space. CISC decoders are more complicated (dunno if slower, although unlikely) & converting to RISC allows you to add more pipelining (better performance).
The reason Transmeta had worse performance is that they did the CISC translation in software. They decided their focus was on power consumption, not performance - hence their design decisions. The technology is certainly amazing and worked for them. They weren't targeting 0-overhead translation.
Also, I'd disagree that compiler optimization is a subset of Strong AI (I'm assuming here you mean human-level intelligence). It's on the same level as path-finding, which isn't even close to Strong AI.
On a side note, architectural changes are far more likely to give you your performance improvements than optimizing with assembly or getting a better compiler.
Also, please back up your claim that a compiler generates worse code than a human. Provide example C code where your assembly is better than what gcc produces at O2.
Wasn't there enough room to say that in the subject field?
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Also, please back up your claim that a compiler generates worse code than a human. Provide example C code where your assembly is better than what gcc produces at O2.
Well, I was willing to maybe believe that you might know what you were talking about, until this... 'gcc' is a notoriously bad optimizer compared to commercial compilers (especially Intel's compiler). The advantage of 'gcc' is that it's common and portable, not that it's a good optimizer.
Compilers are actually extremely good. I'm pretty sure it's been a while since a compiler can beat most of the hand-written assembly out there, unless it's written by a true guru (and there's very very few of them out there - not because assembly is not as common, but because it's hard to write optimized code).
Let me guess... you've never programmed in assembly language in your life. Funny that it's only people who have little experience with writing in assembly language that believe this. It's also only people who have never written in assembly who believe that it's hard.
But if you want proof, look at Photoshop, where filters are commonly written in assembly language for performance reasons.
Sometimes it's best to just let stupid people be stupid.
He cheated on her or didn't lick her mangina or somthing. I wouldn't blame Brother Dave for not servicing such a virulent wretch as Alanis Morisette. Just her name sounds like somthing I would imagine myself yelling before plumetting to my death from the ballast chamber ejecting the alien waste byproducts to gain lift-off from that Prison Planet that lt. Ripley saved me from. It's obvious that Dave was given a choice: do you wat to die on your knees begging, or do you want to die on your feet running?
All this time was a sacrifice to get from point to point in an uncertain origin and destination despite known casualties along that way and mode. Who would have known that a telescope could put a man on Mars before even knowing how to walk his first steps or even fly? Societal order does equally as much harm as good will depending whose hands or subserviance it is in.
See also: VLIW processors, where the hardware guys fool themselves by saying, "the software guys will figure out how to compile to it."
Q: How many software engineers does it take to change a lightbulb?
A: Isn't that a hardware problem?
Q: How many hardware engineers does it take to change a lightbulb?
A: Can't the software guys just code around it?
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Some style-guides' guidance on apostrophes: The Economist, The Times, The American Heritage Book of English Usage.
The Guardian and the Emory Writing Center are more tolerant and admit your way of doing it, albeit as a less common alternative.
And that's just the links on the relevant Wikipedia article. Please inform yourself before dictating dogma.
I've programmed in assembly language. I still would not want to beat even GCC, unless I was competing in a scenario where I knew the compiler was unusually weak.
To beat a modern compiler, amongst other things, you have to be able to consider how the instructions will run in parallel and thus how to interleave them to keep the pipeline from stalling and memory access latencies hidden. You have to have memorized instruction sizes so you don't write crap like "mov %eax, $0" instead of "xor %eax, %eax" and so make inefficient use of icache capacity. You have to understand a ton of ridiculous edge cases around the instructions and their internal implementation - for instance, is BSF really faster than the equivalent manual loop just because it's in hardware? No, it's the same speed, probably the CISC decoder converts it into the equivalent loop internally.
I rather suspect most Photoshop plugins are written in standard C++ with compiler extensions for access to SSE2/3 intrinsics, which gives you the same performance with easier syntax. There's no particular reason to use assembly language any more, not even for performance, unless you're doing operating systems level work or you need to do things that are very unusual, like switching stacks or using a calling convention your compiler doesn't support.
Huh - modern graphics cards do this when they translate HLSL into their own internal code - and do it massively parallel at the same time. Most drivers had just-in-time shader compilers of some level for DX9 (take DX9 state and convert to internal representations)
But yes, you're right its very very hard - graphics cards do this by narrowing the problem down very specifically and not allowing you to do other than that. Not like general purpose cpus
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
Sorry, but you are just flat out wrong.
I've programmed in assembly language. I still would not want to beat even GCC, unless I was competing in a scenario where I knew the compiler was unusually weak.
I can beat GCC (and probably any other compiler) anytime with hand-crafted assembly code. Well, unless we're talking about a scenario where the compilers are unusually strong. Heavy on branching, low on computation code (like typical GUI and "glue" code) being a prime example. But give me some heavy data-crunching algorithm to optimize, and I'll make it (on average, depends on algo of course) twice as fast.
To beat a modern compiler, amongst other things, you have to be able to consider how the instructions will run in parallel and thus how to interleave them to keep the pipeline from stalling and memory access latencies hidden.
True, it does require a high amount of knowledge on inner workings of contemporary CPUs. But given that knowledge and some patience, it is not that hard to achieve.
You have to have memorized instruction sizes so you don't write crap like "mov %eax, $0" instead of "xor %eax, %eax" and so make inefficient use of icache capacity.
Instruction size is not (very) significant, as your innermost loop will usually be much smaller than L1 icache. uop count is more important. You do not need to memorize instruction sizes to know that instruction that carries an immediate will be larger. It has to encode the immediate. It's common sense that it's larger. And most importantly, the main reason you don't do "mov eax, 0" has nothing to do with instruction sizes. Modern CPUs will internally flag a register as "zeroed" when you xor it with itself, which allows them to avoid some inefficiencies later (example: "xor eax, eax; mov al, cl" - fast; "mov eax, 0; mov al, cl" - partial reg stall). Immediates are not checked, so the CPU does not know if you loaded a zero. Smaller instruction size is only an added benefit.
You have to understand a ton of ridiculous edge cases around the instructions and their internal implementation - for instance, is BSF really faster than the equivalent manual loop just because it's in hardware? No, it's the same speed, probably the CISC decoder converts it into the equivalent loop internally.
Wrong again. BSF is faster that an equivalent loop on almost all CPUs. Even if your CPU implements it completely in microcode (most do), it will KNOW how many iterations are to be done, it will KNOW the next instruction to decode, and you avoid a branch misprediction.
The only CPU known to me that had BSF slower than a manual loop was ye olde Pentium the First, which had this instruction EXTREMELY slow.
You do need some heavy knowledge to write fast assembly code, but thinking and creativity is just as important. You can't make a compiler think and be creative, we are just not there yet. Until A.I. advancement makes it possible, a skilled assembly programmer will beat a compiler anytime, ESPECIALLY on f**ed up platforms like x86, with tons of caveats and edge cases. No, I would not be as self-confident about beating a compiler on some RISC platform.
I'm just going to whack you with the information stick and leave you to synthesize clue.
1. The more copies of a model sold, the less each copy pays for engineering.
2. A new chip design costs six to eight figures (USD) to develop.
3. A new computer model costs a lot to develop and support, even if you're starting with a reference design from a chip vendor.
4. People in the first world, where such niche segmentation is most likely to fly, care about run-time. Energy efficiency is irrelevant.
5. People in the first world do care about price. (See points 1-3)
6. GPUs can be gotten for USD20 at retail, soldered on a board with connectors and mounting bracket. (See point 1) Sold on reels, they're closer to USD5.
7. CMOS power consumption scales roughly linearly with clock speed.
8. To increase battery life, run twm instead of compiz at a lower vertical refresh rate and use solid-state disks. (See point 7)
9. Numbers is numbers. Who needs a specialized, custom coprocessor when you have SSE/AltiVec in the CPU? Or, who needs an x86 space heater when you can use Cg on the GPU to accelerate signal processing and reduce system power consumption by a significant factor by switching to ARM?
10. Battery R&D is hot thanks to electric cars. Progress here will make current laptops run SETI@home for days on a charge.
11. Apple has had modest success selling audio/video workstations and entertainment service clients. Their viability is mainly by virtue of "lifestyle marketing", major R&D expenditures, and a high gross profit margin, all of which imply a high MSRP.
12. Who's going to pay for someone to make applications use these new capabilities? Buyers, of course. Will buyers think it's worth it to pay more for less? Will volume make it cheaper than carrying an extra battery with? (See points 1, 5 and 11)
I'd go on but this is enough.
/. -- the Free Republic of technology.
"Maroon." Thus Spoke Bugs Bunny.
Gary Dunn
Open Slate Project
He said "kykes." Have we not been keeping up our ethnic slur vocabulary?
Gary Dunn
Open Slate Project
Not true. Pentium II and first Pentium III CPUs had L2 cache operating at half the core frequency. Celerons and later "B" Pentium III CPUs had L2 at full core frequency. The reason cache was "half-clocked" at the beginning were exactly the clock scalability problems with the original PPro. P2 like PPro had cache on a separate chip. When fabrication process advancements allowed to fit the CPU core AND cache on a single die, Intel returned cache clock to full-speed.
True scientists celebrate their failures.
I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga
This may be a stupid question, but, where does Linus work now?
-- thanks, Dave
Well Yahoo was two students too. So it's not inconceivable now is it?
“Common sense is not so common.” — Voltaire
I will agree with you that the technology decisions, while interesting research, were perhaps not the best investment.
But my argument is that if you're a little guy and want to take on major players in a market, you need to attack their weak points long before the major players realize they have a weak point. When companies with huge resources are competing in a R&D heavy sector, you don't want to jump in and try to compete in areas that the big players are aware of. They'll eat you for lunch.
Perhaps I'm just overly negative after working for six or seven different failed start ups. Some of which made the same mistakes as Transmeta. A great bunch of people, some cool technology, even some good management. But I have learned, rightly or wrongly, that being stealthy and going for the customers that are being ignored by more powerful players is a better strategy.
“Common sense is not so common.” — Voltaire
But I have learned, rightly or wrongly, that being stealthy and going for the customers that are being ignored by more powerful players is a better strategy.
I agree with you there. I don't remember the exact quote, but I still remember shaking my head when Andreessen started shooting off his mouth taunting Microsoft back in the Netscape browser days. I think I posted at the time something to effect of, "A browser is not the most difficult piece of technology in the world. All he's doing is causing The Navy Destroyer Microsoft to swing its howitzers around to take a shot at his little tug boat." And that's what happened.
Sometimes it's best to just let stupid people be stupid.
Yes, and that was the point I was making.
History has judged things diffrently. The P6 Architecture, from the Pentium Pro 133(Proto),150,166,180,200,233OD to the Pentium III Xeon, scaled the clock speed quite nicely. The Pentium Pro was unique in its Cache. The Pentium II just put that cache on the die. The Pentium III was just the next simple step in the evolution ofthe P6 micro architecture. ( Dont misunderstand my contention that the Alpha chip was VASTLY superior in every way ). The only thing Itanium shares with the Alpha is its failure. Alpha was from the ground up, the processor of the future, and far ahead of its time. Eventually, everything it was, will return to x86 architecture.