Slashdot Mirror

Isn't this Transmeta territory? Transmeta was making ultra low power chips before it was the in thing to do. My question would be why weren't intel and AMD doing this 10 years ago?

http://www.transmeta.com/index2.html

Perhaps they could be making GPGPU that with a translation layer for x86 instructions, like the Transmeta Crusoe did in VLIW, or maybe they are enhancing a Via Nano CPU design with on die GPU (rather like they did with the Tergra ARM11 chip). Either way this won't be a desktop CPU, and it won't be serious competition for Intel, but could be targeted at the growing netbook market.

Intel could step in and try to block them, but they have lost against Via and Transmeta in the past, and they would also put themselves in a difficult situation, since they are being watched in the US, EU and Asia for antitrust violations. This would look quite bad for them.

I'm broke and I got all 6 numbers out of 6.

I invested in http://www.transmeta.com/ :(

"Eventually we'll end up with a decent processor that just emulates the x86."

Ahh, the days of the transmetta... Unfortunately that never really caught on :(

Transmeta's original claim to fame was low power consumption. Sadly they haven't done that well in the market.

Sun is currently making big claims for its new multicore servers, dubbing it CoolThreads technology. Their blurb is 5x the performance for 1/5 the power and 1/4 the space.

it's another thing entirely to actively cheer on the introduction of DRM, which Torvalds has been doing now for a couple of years. Doesn't Linus realize that with strict hardware controls enforcing what may and may not be run, one's freedom to tinker may disappear?

Does he still have relevant ties to (t)his (former?) employer during/after "a leave-of-absense [sic]" ?

These are questions that any serious reporting on his stance needs to ask and answer - before questioning the merits of GPLv3 (that would make perfect sense for Linux anyway) just because the FSF cannot get Linus Torvalds to fully and openly agree with it (yet).

It costs more money to include either an extra ROM or a bigger ROM that can contain restore code.

More interestingly, the question is what affiliations, if any, the "real" Linus (on "a leave-of-absense" in his own words?) still entertains with Transmeta, who reportedly just created the FlexGo hardware (which looks very much like what GPLv3 tries to prevent) for Microsoft - and what restrictions (e.g. on deservedly slamming DRM at least as applied to code rather than content -much rather than slamming the FSF!- in public) may result from that?

Appart from the fact that it might be replace by High K/Low K (whatever that may be), saying:
"could reduce the prices of electronic devices for consumers and, of course, create a positive environmental impact"
Seems wrong: Isn't production only a small part of actual environmental impact?
Of course any "greener" pruduction method helps, but when I think about green chips, I think about chips like the efficeon chip from Transmeta.

This CPU is one of those technology jewels that never got a spread interest in the market.
It is power savvy while being powerful enough and x86 compatible.
It would be great if AMD could really revitalise it to avoid flops like Amiga: good ideas with no luck! at all

Now, the question becomes whether you can extract 1/3 of the value of the PC in parts. Transmeta has a press release on the subject. Here is a quote from the press release: "The specialized microprocessor is an enhanced version of Transmeta's 90 nanometer Efficeon microprocessor that includes instruction set extensions developed with Microsoft to support the FlexGo technology, which enables both pay-as-you-go and subscription computing models in emerging markets. This new Efficeon processor provides a secure foundation for Microsoft's FlexGo technology and associated business models. The design of the processor offers robust protection from repurposing and protects the business investment in subsidized systems."

Quick! Someone tell Linus Torvalds about this newsflash. He could make millions!!!

Maybe it's the stress, dunno but this guy is developing a chip on his shoulder that needs to be knocked off.

I thought he stopped developing the Transmeta chip a long time ago.

What did I miss? I remember the hype, the early diagrams of how it was all supposed to weave through without the need for a clock. Would someone care to elaborate on the post-mortem of what was supposed to be the first clockless processor, 4 years ago?

Back in 2000, Transmeta started producing chips with Longrun technology, which automatically varied processor frequency and voltage many times a second in response to the current processor load. The technique is quite effective in reducing heat and increasing battery life.

Don't forget http://www.via.com.tw/en/products/processors/c7/ and http://www.transmeta.com/efficeon/index.html. Or maybe you would be better off forgetting them, I don't know.

If Transmeta proved anything, it was that you get more performance-per-watt and flexibilty by moving hardware into software. I guess that was the point behind the RISC processors that are now delivering up to 32 concurrent threads in hardware. Keeping the hardware simple gives you far greater potential. In light of this, I don't see how "system on a chip" can be a good thing?

http://www.transmeta.com/efficeon/partner_tech/uli .html

You see, Crusoe is different in almost every way. Unlike the industry's legacy hardware-only processors, Crusoe is a unique combination of software and hardware. http://www.transmeta.com/crusoe/

I for one salute our new, faster booting Cyborg Overlords.

Transmeta is what I think it was called before. http://www.transmeta.com/

Sorry, hit reply too soon last time.

The Orion Multisystem (96 processors under your desk) and the OQO are recent examples. They are in some Sharp notebooks ... browse the list here.

If Transmeta does close shop, I hope they consider opening up their "Code Morphing Software". It's an interesting approach to X86 processing on non-X86 processors, for more info check here: http://www.transmeta.com/crusoe/codemorphing.html

They're still working on putting out a chip based on LongRun2, which reduces transistor leakage. This is very important for cutting power consumption and increasing CPU speed. They've also licensed the technology to Fujitsu, NEC and Sony, none of which have released a product based on it yet.

It's quite possible, though apparently unlikely, that Transmeta will turn things around and manage to survive. However, Intel is already all over the leakage problem, so this may well be the end of Transmeta.

They're still working on putting out a chip based on LongRun2, which reduces transistor leakage. This is very important for cutting power consumption and increasing CPU speed. They've also licensed the technology to Fujitsu, NEC and Sony, none of which have released a product based on it yet.

It's quite possible, though apparently unlikely, that Transmeta will turn things around and manage to survive. However, Intel is already all over the leakage problem, so this may well be the end of Transmeta.

I read the article and basically decided that the authors were a bunch of overpaid muppets with too much time on their hands.

e.g.
http://www.transmeta.com/success/desktop.html
http://www.transmeta.com/success/workstations.html
http://www.transmeta.com/success/sbc.html
http://www.transmeta.com/success/server.html

etc etc etc.

I read the article and basically decided that the authors were a bunch of overpaid muppets with too much time on their hands.

e.g.
http://www.transmeta.com/success/desktop.html
http://www.transmeta.com/success/workstations.html
http://www.transmeta.com/success/sbc.html
http://www.transmeta.com/success/server.html

etc etc etc.

I read the article and basically decided that the authors were a bunch of overpaid muppets with too much time on their hands.

e.g.
http://www.transmeta.com/success/desktop.html
http://www.transmeta.com/success/workstations.html
http://www.transmeta.com/success/sbc.html
http://www.transmeta.com/success/server.html

etc etc etc.

I read the article and basically decided that the authors were a bunch of overpaid muppets with too much time on their hands.

e.g.
http://www.transmeta.com/success/desktop.html
http://www.transmeta.com/success/workstations.html
http://www.transmeta.com/success/sbc.html
http://www.transmeta.com/success/server.html

etc etc etc.

Comparison of various CPU in MIPS/Watt or MFLOPS/Watt.

http://www.acmqueue.org/modules.php?name=Content&p a=showpage&pid=80&page=4

And some suppliers of efficient servers.
http://www.transmeta.com/success/server.html

Having dealt with HP, I would be inclined to look at one of the other vendors.

The Transmeta Crusoe has been 128 bit since it came out five years ago.

Why is everybody so concerned with Transmeta suing every CPU user or manufacturer in sight? IP companies are not bad by definition. Just the contrary. And SCO is an exception! The first IP company I come up with, Rambus, is not the public enemy you are trying to turn those, who make a living out of intellectual property, into. Maybe not all of their products are as good or as cheap as many would like them to be (including Rambus themselves), but at least the company is not in the business with groundless lawsuits.

So please, stop bitching over insane snowflake_in_hell possibilities of Transmeta's future and ask yourselves what will you benefit if CPU manufacturers (ie Intel, AMD, IBM) adopt the very good technologies, part of Crusoe and Efficeon processors. (stuff like LongRun and LongRun2, you know)

Why is everybody so concerned with Transmeta suing every CPU user or manufacturer in sight? IP companies are not bad by definition. Just the contrary. And SCO is an exception! The first IP company I come up with, Rambus, is not the public enemy you are trying to turn those, who make a living out of intellectual property, into. Maybe not all of their products are as good or as cheap as many would like them to be (including Rambus themselves), but at least the company is not in the business with groundless lawsuits.

So please, stop bitching over insane snowflake_in_hell possibilities of Transmeta's future and ask yourselves what will you benefit if CPU manufacturers (ie Intel, AMD, IBM) adopt the very good technologies, part of Crusoe and Efficeon processors. (stuff like LongRun and LongRun2, you know)

To be fair, Transmeta Efficeon range has integrated DDR memory controller too. It's not a true x86 CPU but it can morph x86 instructions into VLIW ones.

It's a shame that it hasn't been too successful :/

It's interesting to that a number of manufacturers are putting out glowing press releases about their involvement with this, including Transmeta. There's a bit more information on Transmeta's site about the actual specs of the wearable system itself.

And, yes, it can run Linux.

Please look at the Crusoe Processor They consume under 2 watts and I believe they have broken the Ghz barrier.

It's called the Crusoe Processor by Transmeta. And yes, it is an x86 processor.

What's broken in Unix? Rob Pike isn't writing it anymore. So when Google hires Rob Pike, they very well might be "fixing" Unix, or Linux, or Plan 9 - in any event, the move has "OS" written all over it. They're probably not just planning to produce a low-power CPU with a geek spokesmodel.

It turns out that unless you have very high yield across the entire wafer its impossible to get everything you need for a "real" computer (CPUs, cache, memory, bus controllers, etc.) wired together and operating properly. Because each wafer is going to have different yields and different fault points you have to build in a lot of redundancy for all of the sub-components. Not only is wiring together the working parts a nightmare but the excess redundancy means the wafer is going to be much more expensive than wiring together known-to-work chips for equivalent computational capacity. This is compounded by the fact that the semiconductor manufacturing processes for CPUs and DRAM memory are significantly different. To get both types of hardware on a single wafer you have to make significant compromises in the capabilities of each (or significantly increase your manufacturing costs). [This is why, with the possible exception of IBM and maybe Intel, manufacturers tend to specialize in either CPUs (logic) or memory. I doubt any manufacturer has the same factory turning out both.]

Far more likely to be of interest is reconfigurable chips. Work in these areas is being done (slowly). Perhaps the best example is the Transmeta processors.

>Then, what would I like that processor for? Longhorn? M$-Office 2005?.. or my antivirus that now has a huge list to run over everytime?

Get one of these.

And I'm not talking about the girl on the frontpage.

http://transmeta.com/success/desktops/nec/nec_powe rmate_eco.html

http://www.fic.com.tw/product/server/janus.aspx

While with the AMD and Intel chips, 5.5 would be a long stretch, Transmeta has a long history of getting 10+ hours of battery life with their chips. (I've even seen a report or two with over 20 hours of battery life.) I would expect that the battery life would be at least 10 hours, probably around their mean of 11, at least with the Crusoe. I doubt they would release a processor with extremely less battery life for the Efficeon line. So, 5 hours would probably be way too low, unless the system was being utilized at full usage the entire time, under the heaviest of applications.

Check their website for more details - http://www.transmeta.com/efficeon/efficeon_tm8800. html

If only Transmeta would quit fucking up their manufacturing line and actually produce a chip, something like Efficeon can be ideal for such applications.

1) Java has bounds checking for arrays, C++ doesn't. This is specified in the language. This affects performance.

2) Java has garbage collection, C++ doesn't. This is specified in the language. This affects performance.
Also, the specification of Java says that it should be compiled to byte code and executed in a JVM.
So the "language" certainly affects performance.

I believe I disagree with all of these.

When Transmeta's Crusoe launched, it was not widely known that they had the fastest native picojava processor on the planet.

To prove it, they compiled most of Doom down to x86 machine language, and then they compiled the exceedingly hot spots (rasterization) down to x86 for one executable and down to picojava for the other executable.

They both ran at the same speed.

You might say this is because Transmeta processors don't really run x86, but instead translate it to another format. That is correct. So does a JVM. So do Intel and AMD chips. Pentium processors haven't been native x86 processors since the original Pentium.

The trick to most on-the-fly x86 optimizations is figuring out when the strict x86 behavior is necessary, and when you can bend the rules. If you're in the middle of bending the rules, and the processor receives an IRQ or generates an exception, you need to dump everything on the floor and back up to the last time you had a valid x86 state, otherwise, as long as the x86 state is the way it's supposed to be at the end of the block or trace or however much you can get away with, it's all good.

This is true of Java bytecode as well. If you can simply trap out-of-bounds memory instead of doing an explicit bounds check on each access, your code will run very fast. If you get an exception, then it's back to the JVM. If you get lots of execptions, you can retranslate that particular block to do explicit bounds-checking and again manage to avoid calling the JVM.

If your garbage collector learns individual app behavior and tailors its behavior to a particular application runtime memory allocation track record, you can get superior performance to C++ new()/delete()'s compiled to x86, depending on how much time the app developer got to profile his memory management system, a task all too often overlooked in today's memory-is-cheap-get-it-to-market rush.

HP's Dynamo runtime actually proved that you can get better native machine language performance by running the native machine language in a runtime.

Modern JVM's aren't executing bytecode. They're making fully native x86 translations, and the x86 translations jump to each other. In fact, you're not really spending much time running the JVM at all. Your program is getting compiled, linked, and is running native. It's only going to the JVM when it has to.

The bottom line is that your Java perf is going to be wildly variable, depending on the quality of your JVM, and your x86 performance is going to be much less wildly variable, because x86 processors really became C++ bytecode processors several years ago. They're very carefully tuned to destroy benchmarks, particularly Winstone, which is a spectrum of bloated C++ Windows apps, a depressingly representative benchmark of what most of us run.

However, Intel and AMD processors can't see or remember beyond a tight window of x86 instructions. They will make the same optimization mistakes over and over again, no matter how many times you run the application. If your hot spots are longer than the size of that window, you lose. JVM's don't have this restriction. They see and can remember the entire application.

Nothing about x86 or C++ prohibits C++/x86 runtimes. This is precisely what Transmeta and VMWare are doing. They are both little companies and do not have the incredible muscle and financing of AMD and Intel, n

The reason is that most people PREFER not buy power-saving notebooks, which easily sport 7h of battery power... :-)
Your own choice...

Although i have never programming, my first college leve CSCI class used SCHEME (a direct descendant of Lisp if i remember correctly) as the language.

This language is structed very difficult for a new computer science student to easily understand.

The endless parenthesis does not help either.

And, on top of this, the language is completely dead!

I much rather would have learned an assembly language. This would have given students a better feel for the hardware and would have had useful applications.

Wouldn't the wood covering just act like an insulator?

I was wondering the same thing.
If the back isn't covered and the case fan is good enough would that work?

If they only build the box, are they responsible if it overheats?

Maybe it would be best to put a Crusoe chip in it.

I think most of the energy consumption does come from the processor itself, but you're correct in that laptops need to be thought of as completely different machines, and not simply miniture designs of power-hogging desktops.

Transmeta's Crusoe chip was, I believe, designed with the specific intent of being a mobile processor. I haven't really kept up with their progress, but it was an interesting niche to attempt to carve.

I may be wrong, but I seem to recall that Intel's mobile processors are simply versions of their desktop chips modified to consume less power and generate less heat. While both of those things are great, one would think there'd be more efficiency in creating a chip solely for mobile purposes.

Here's what I wonder...has backwards-compatibility caused hardware to get so kludgy that things would actually run faster if we designed a brand new system and ran an Intel-compatible VM in firmware? I think yes...and that would provide the perfect opportunity for companies to transition to a new platform over a number of years.

Check out Transmeta.

While not actually a tablet PC, I think the Fujitsu lifebook would be just the thing for you. I have been delighted with mine. It is very small, has excellent battery life, uses a Transmeta Crusoe processor, and runs linux like a charm

that it would run Linux on a Crusoe CPU.

This IL obviously like many other things cannot be the best solution in all cases.
Which is why there generally are a million ways to solve each of the kazillion problems... each having its own plus points.

Its thus difficult to say that a universal intermediate runtime language for hi perf computing will emerge.
Even the design of a new computing architecture can render it ineffective (unless it is designed to avoid these issues, but then?) though ofcourse this doesnt happen overnight.

On the other hand ppl can even start making architecture specifically optimized for this language widely increasing its popularity. (speculation)>/p>

Look at what transmeta did in the crusoe. Adding another abstraction layer between the vliw cpu and the native x86 code had some very interesting results. As a matter of fact an IL could be even more useful in vliws when this arch gains popularity since optimization at the level of the IL maybe preferred over direct assembly(!) optimization in this case.

so imho this IL is not really going to be anything more than an interesting way to do high perf computing.

happy computing fellow nerds.