Transmeta Rewrites the Rules
When Linus Torvalds joined the secrecy-shrouded startup Transmeta Corporation, he couldn't tell anyone what he was working on. Now, the wraps are off a revolutionary new idea: a chip that combines the low power of a RISC chip with the software versatility of an x86 processor. This combination enables a new class of lighter, longer-lasting mobile devices with PC compatibility, and yes, some of these devices run Linux. The new chip (see Figure 1), dubbed Crusoe after the famous traveler, achieves this combination of features without any RISC or x86 hardware. Instead, it runs so-called code-morphing software on VLIW (very long instruction word) hardware to execute standard PC software. This unique combination delivers the low cost, low power and software compatibility needed in a mobile PC or a portable web pad.
Dave Ditzel (see Figure 2), a former Bell Labs and Sun CPU architect, founded Transmeta in 1995 to pursue a novel approach to x86 microprocessor design. Whereas Intel and AMD take power-hungry desktop PC processors and cripple them to fit into a notebook PC, Transmeta decided to design a new mobile x86 processor from the ground up. As a result, the company's Crusoe chips dissipate as little as one-fifth the power of Intel's Mobile Pentium III. To minimize power, Crusoe uses a simple yet powerful VLIW architecture that requires far fewer transistors than Pentium III or AMD's Athlon. These traditional chips execute several instructions at once to improve performance. Standard x86 programs, however, assume the processor executes one instruction at a time. Therefore, a huge portion of a Pentium III or Athlon chip is devoted to checking and arranging instructions so they can be safely executed together.
A VLIW design, such as Crusoe, avoids this overhead. Each Crusoe instruction contains the equivalent of four x86 instructions, all prearranged for optimum execution. With no checking or reordering logic, the processor can execute all four instructions at once and immediately begin the next set of four instructions. As a result, the processing logic in Crusoe requires 75% fewer transistors than in Pentium III. This difference provides several advantages. Each transistor on a chip consumes electricity; with far fewer transistors, Crusoe needs less power to operate. The missing transistors also make Crusoe less expensive to build than a Pentium III. The simpler chip requires less time to design and is easier to test—important issues for a small company such as Transmeta.
Alone, a VLIW chip is incapable of running programs designed for an x86 processor. But the Crusoe chips are paired with Transmeta's patented code-morphing software (CMS), which converts x86 programs into VLIW instructions that the chips can understand. Although Transmeta is a chip company, developing this software was a more daunting task than developing the chip itself.
The CMS, which Torvalds helped to develop, analyzes an x86 program and feeds the corresponding VLIW instructions to the processor. This translation is done on the fly and is invisible to the user. The CMS translates only those portions of the program that are in use; for example, when executing Microsoft Word, the “mail merge” module is not translated unless it is invoked.
Translated code blocks are saved in a translation cache; on subsequent iterations, no retranslation is needed. Since programs often execute the same loops and subroutines over and over, the translation cache is very effective. But the CMS has the odd property that it executes a program relatively slowly to start, but faster over time. Translations are not saved when the user quits an application, so the learning process starts anew each time the application is launched. The overhead of code morphing reduces the raw performance of the VLIW engine, but over time, this overhead is amortized across many iterations of frequently used code blocks. Transmeta's VP of Product Development, Doug Laird, claims that the 667MHz Crusoe chip will match the performance of a 500MHz Pentium III, although the company has not released benchmark data to support this claim.
Many popular PC benchmarks use a particular feature of an application very briefly before moving on, reducing the advantage of the translation cache. This problem makes measuring the performance of the Crusoe chip difficult. Real users, in contrast, typically use the same features again and again. For Transmeta to compete well against Intel, end users must perceive Crusoe to be just as fast as Pentium III.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
3 hours 7 min ago
- Yeah, user namespaces are
4 hours 23 min ago
- Cari Uang
7 hours 55 min ago
- user namespaces
10 hours 48 min ago
11 hours 14 min ago
- One advantage with VMs
13 hours 43 min ago
- about info
14 hours 16 min ago
14 hours 17 min ago
14 hours 18 min ago
14 hours 20 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?