Studly Work: Talking Transmeta with Linus Torvalds
The reason I work for Transmeta is that I think the approach is so studly from a technical viewLinus Torvalds
Wednesday, January 19, 2000 was a long day for Linus. It was Rollout Day for Transmeta: the day the company spilled the beans about what it had been doing for last four and a half years. During that time Transmeta kept a Masonic secrecy about its work. By being the one thing Linus and his co-workers couldn't talk about, Transmeta became the one thing everybody had to talk about. This made for great buzz; but it was pretty weird that a movement built on conversation was led by a guy who had to keep silent about his work.
Until yesterday. That's when the weirdness finally stopped.
The first time I saw Linus at the event, he was pushing his way through the crowd, trying to get safely behind the stage. The second time was when I had sneaked out to get something from my car in the parking lot behind the building. Linus was running through the rain, threading his way between giant television trucks and portable satellite uplink installations, no doubt circumventing the throng inside. The third time was when he came on stage long enough to get his ass kicked at Quake by one of the game's own developers. (Couldn't they find a fairer way to demonstrate Transmeta's equal support of Linux and Windows?)
When I finally got to sit down with Linus in a room upstairs, I expected him to be at a point of maximum stress, final relief, or both. But he just seemed happy to have the thing over with (mine was his last obligation for the day). So it was a relaxed and upbeat conversation.
As background, here are direct links to Transmeta's subject pages (unfortunately, all of the more technical stuff is in .pdf form):
- Doc Searls
Doc: How are you doing?
Linus: Well, I'm so used to doing this kind of thing for Linux. It's much more stressful to do it for the company.
Doc: Because you're a company guy now.
Linus: Well, it's also that I've never done this before.
Doc: Well everybody did a very good job. And I was just talking with Linley Gwennap (one of the leading microprocessor analysts), who was very positive about the whole thing.
Linus: Oh, so Linley is positive? He was one of the ones we knew would be here, and we didn't know how he would react.
Doc: I asked him if Transmeta had in fact achieved the ideals of RISC, and he said yes.
Linus: It's Java.
Doc: It's Java?
Linus: It's Java. Exactly. I mean, it's much harder than Java, because Java was designed for being translated. And the x86 instruction set was definitely not designed for being translated.
Doc: And now it is, in a way, because of what you guys have done with it.
Linus: But you can tell it wasn't designed that way. I was surprised that nobody yet has asked the question, "Why not self-modifying code?" If you design a language for being translated, you cannot do self-modifying code. You just don't allow that trick. But with x86, you have to allow self-modifying code, because it's a fact of life. So it is much harder to translate when you know that the code might change from under you.
Doc: How much energy at Transmeta went into software versus hardware? One person I talked to thought more energy might have gone into software.
Linus: I think it's partly true for the last half year or so. When I came on board, there were about 60 people, and about 5 people were involved with software. Or maybe it was under 10 people. A lot of people came from Sun and SPARC, so a lot of the initial work was in hardware, and there was a lot of speculation about what the software would do. People were optimistic, but you have to be optimistic because otherwise you'd never start. But software is now clearly one of the main issues.
Linus: One of the hard parts is just bootstrapping things. When you don't have the software, you don't really know the problems. You don't know enough really to design the hardware yet. So that's why we had this internal Silicon Spin, and we learned a lot from just being able to run for the first time, at a reasonable speed, major applications. Before that happened, you could simulate, but at such a glacial speed that you completely lacked the feeling for how fast it was.
Doc: What is "Mobile Linux," and how does it differ from every other kind of Linux?
Linus: It's easier to say what it is not. It's not a Red Hat. It's not a distribution. It's not a special kernel. It's really more of a term we have for the people we support. It gives them a sense of what we give them to play with.
Doc: Which is?
Linus: It's the standard 2.3 kernel with some power management stuff done on it, but anybody can see what that is. There is the compressed file system that I made part of the standard kernel not long ago. And that's really the question of ... you have a very limited amount of ROM. You want to fit Netscape in there, too. And you want to page things in from the ROM. You obviously want to compress it. That's number one. But how do you compress it so you can still do random seeks and paging in things? Those are the kinds of questions I spent a fair amont of time thinking about. What's the good way of doing this? What fits in and works well? These are not fundamental design shifts.
Doc: I was impressed at how it worked in the prototypes I saw in the demo room.
Linus: Yes. We have added pieces like the virtual keyboard.
Doc: Is this a Linux thing--this touch-sensitive virtual keyboard that slides out the side of the screen when you want to type?
Linus: It's an X application that takes Graffiti and turns it into X events. So you can feed characters to other applications. It's kinda cool. But it's not rocket science. It's something that Linux didn't have before, and that we wanted to be able to offer any customer coming to Transmeta saying "We hear you have this x86 embedded low power device, and we'd like to do one of these Web slates." There are a ton of people who want to do these Web slates. And they all want to use Linux, because they can't fit Windows in there.
Doc: And they've been burned by Windows CE.
Linus: Yeah. And then at the same time they all have the same questions. So these additional features are ways to say, "Okay, if this is what you want, here is what we have done to get you started."
Doc: The future of computing is clearly increasingly mobile. You've been talking about this for quite a while. What do you see as the future milestones of Linux? What do these developments say about where Linux is going to go?
Linus: Not that much, I think. The fact that I happen to think (in that direction), yes. I mean, it's not just that I work for Transmeta. I think mobility is a good idea.
Doc: The reason you work for Transmeta is that you like ...
Linus: ... The reason I work for Transmeta is that I think the approach is so studly from a technical view. We should have shown technical people real demos of all these tools that show: what's the original x86 code? What did we change it into? Half of what the software group has done is just these tools, for visualization, for figuring out what things we missed, so we can be better at not missing those things. That's just incredibly cool, whether it's mobile or not.
Doc: Are these tools relatively public? Are they exposed at all?
Linus: There is a debugger environment that is exposed, but we don't want to expose the internal stuff. You should think of it as a chip in itself. And there is a lot going on behind the curtains. Basically it's a lot of interesting technology that I don't think anybody has done before. A lot of people have done just in time compilers, and Digital used to do FX!32, which was translating x86 to Alpha. But nobody has done something in this kind of real environment. You didn't have real-time applications with real real-time guarantees, including the whole OS working. So that's what made me want to work with Transmeta in the first place. And then the fact that yes, I think mobile and wireless communications are good and I want more of that. For now it just makes me really happy to be able to say yes, we can do this. I don't have to be ashamed about what Transmeta does. They have all this cool technology.
Doc: I was intrigued by what Dave Ditzel said about how this was something that could not have come out of the chip or the software businesses by themselves; one side wants to throw more transistors at a problem and the other side wants to throw more code and that everybody came from one side or the other.
Linus: Nobody really seriously considered doing this. Even SoftPC. And this is kind of what SoftPC does. It's a lot of the same thing. But at the same time SoftPC does not track with the low level hardware. And it has nothing to do with what Transmeta does. Even SoftPC never even tried to go head-to-head on real CPU performance. Everybody just thought that it can't be done. What Transmeta says is it can be done, but you need special hardware. And you need hardware that is designed for doing this kind of thing.
Doc: It seems to me that this does change the game. Or creates a new game.
Linus: I hope it's true. And that the market will be quick to react to it. There is always a problem when you have a first generation product, and you are comparing this first generation product against the fifteenth generation of your competitor's product. So yeah, we think we're there, but... (laughing)
Doc: I did a bunch of work with Hitachi a few years ago, helping roll out their H8 microcontrollers. I learned then that the company didn't like to make a microprocessor or microcontroller unless it was a "10 - 10 - 10," which was: over ten million units, under ten dollars, over 10 MIPS. Or something like that. I forget exactly what each stood for, but the idea was to start in fifth gear. There was no ramping up in the marketplace. You had to be assured that it would sell to one or two giant customers (including yourself), which guaranteed your volume of umpty-zillion units. Also, everything that was good came out of the central laboratory, which had farms of computer scientists and engineers, working almost at the molecular level to churn out fresh ideas and patents. This was the model for chip development behind consumer electronics. And these are still the guys who make portable units. I'm also not sure it is much different for Nokia, Ericsson, Philips and the European manufacturers. What you're doing here is very different. I'm wondering if there is any concern at Transmeta about the kind of cultures and markets you are dealing with here, coming from the outside.
Linus: One of the things we noticed is that it is clear that American companies don't worry much about bulk. They sell these big, bulky PCs with 14 inch LCDs. And they sell that as a feature: it's got a big manly screen. And they are not too convinced by the power advantage, because for them the system is so large ... who cares when the CPU takes only 20% of the system's power? On their machines, the CPU is a low percentage of the whole system's power consumption. The Japanese manufacturers have been much more open. It also helps us that, on the PC side, they're using Intel. Bend over! (laughter)
Doc: They've been conditioned already.
Linus: So, in some sense, I don't think it's going to be an issue. And, in any case, we're not going into the Super H market.
Doc: What else excites you?
Linus: One thing that makes me excited is that we have this LongRun thing, and it's great.
Doc: It was a great demo - about how the chip adjusts to application behavior.
Linus: The reason you saw power consumption go up at the beginning of that demo is that it needs more power to do the translating up front, but then it's easier, and the consumption goes down. So it's a really good demo. But there also are all of these other areas where we can do something else with software. Especially on the Windows side, if somebody wants to create a really cheap power Windows device and get rid of all the legacy hardware. Let's face it: Windows doesn't work unless you have all that hardware. But we can simulate a lot of that hardware. So there are all these areas where we can use software to do the job.
Doc: Maybe that's a gift to Windows, in a way.
Linus: Strange. We'll see.
Doc: You know, my expectation coming in today was that the rollout would be 90% Linux and 10% something else. Instead it seemed more Windows than Linux. But that makes sense because you have these two classes of chips, and the more high performance chip, with the Level 2 cache and all that, is aimed at the Windows market.
Linus: Looking at the Windows side brings up the issue of soft modems, which do not have Linux drivers. One of the things we've toyed around with is the idea of having the modem driver done by the CPU. So the CPU just dusts the soft modem. And it looks like a normal serial port. Again, it's the same thing: we simulate hardware in software.
Doc: So you're treating certain hardware itself as a bottleneck.
Linus: You always want to eliminate some parts. But look at all the trade-offs we've been able to do on the x86 instruction side. How much of that do we do in hardware and how much in software? We can do the same kinds of things on the system side. We don't do that yet.
Doc: The old chip answer used to be VLSI. We'd just integrate everything we could onto the chip.
Linus: Integration is still a good idea. Because it drives down power, assuming you use all the integrated parts, you don't have to drive electricity between chips. In all of this, the most interesting stuff is what we haven't done. We've been in this panic mode to get the basic instruction set working, without worring about the future too much.
Doc: I'm looking forward over the coming months to seeing how certain things start to resolve: to see how much interest is in your work and not just you, how much interest is in Transmeta and not just the mystery around the company, what the design-ins start to look like and what customers start to show up.
Linus: What I'd really like to have is that little unit we have as a mock-up. (See "Going Mobile." It's the unit in the first graphic.)
Doc: The little pad?
Linus: Yeah, that little one with the pieces.
Doc: With all the pieces that fit around the edge, the game controllers and GPS unit and camera and so forth?
Doc: And they all attach by USB conections? That's the best use of USB I've seen yet.
Linus: Right. And that's do-able right now, from a technology point of view. It's just not economic.
Doc: For the right customer, maybe.
Linus: That screen--there really is an 800 x 600 screen with that form factor, that's really that small --is very expensive. And just getting everything to fit into that size is really hard. They measured with micrometers just to say "yes: we can do this. It's physically possible."
Doc: What's the noun for that thing?
Linus: A work pad.
Doc: And the other one is what, a slate?
Linus: They're the same thing. It's just that the big ugly ones are easily designed. They're full of air. And that's probably what the first generation will look like, just because the first generation won't have all the refinements. We'll need to learn to pack things tighter with our new chip. There's a learning curve. The first versions won't have the optimal packing. Next time, they'll move one chip ninety degrees and find a bit more room. But the small form factor, that's the real challenge. They're hard to do. The big Web slate is the only thing we can demo that works. But it is not something that is going to make a market yet. It's too big to take to the toilet with you. But the small ones are so much more useful.
Doc: You may know the answer to this last question. Nobody else seems to know. It's a hardware question. Do these new chips put out less RF? One of the things I would love to see in one of these little computing devices is a radio: one that picks up regular broadcast signals. The problem in the past with integrating these things is that the computing chips throw off too much RF.
Linus: I really don't know. It's a hard problem to solve. We've seen the heartbeat of the low power modes show up at all these frequencies that depend on what you are doing. It's one reason the power supply is such a critical part of the system. You have to feed a fairly consistent power level, even when it's going from, like, 10 milliwatts to 2 watts, very rapidly. There might easily be RF signals coming out from just those, regardless of what the CPU does.
Doc: In my office I can hear the computers sing over the AM radio, as they move from program to program, or as they spin up the hard drive.
Linus: Hmm. I really don't know.
Doc: Another interesting problem to solve.
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide