Peter Seibel - Coders at Work - Reflections on the craft of programming

Seibel:Are there still tasks which, for performance reasons, people still have to get down to hand-tuned assembly code?

Thompson:It’s rare. It’s extremely rare unless you can really get an order of magnitude and you can’t. If you can really work hard and get some little piece of a big program to run twice as fast, then you could have gotten the whole program to run twice as fast if you had just waited a year or two. If you’re writing a compiler—certainly 99 percent of the code you produce is going to be run once or twice. But some of it’s going to be in an operating system that’s run 24 hours a day. And some of it’s going to be in the inner, inner loop of that operating system. So maybe 0.1 percent of the optimization you put into a compiler here is going to have any effect on your users. But it can have profound effect, so there maybe you want to do it.

Seibel:But that would be a result of generating better code in the compiler rather than writing the compiler itself in assembly.

Thompson:Oh, yes, yes.

Seibel:And presumably part of the reason writing programs directly in assembly is less important these days is because compilers have gotten better.

Thompson:No. I think it’s mostly because the machines have gotten a lot better. Compilers stink. You look at the code coming out of GCC and it’s awful. It’s really not good. And it’s slow; oh, man. I mean, the compiler itself is over 20 passes. It’s just monstrously slow, but computers have gotten 1,000 times faster since GCC came out. So it may seem like it’s getting faster because it’s not getting slower as much as computers are getting faster underneath it.

Seibel:On a somewhat related note, what about garbage collection? With Java, GC has finally made it into the mainstream. As Dennis Ritchie once said, C is actively hostile to garbage collection. Is it good that folks are moving toward garbage-collected languages—is it a technology that deserves to finally be in mainstream use?

Thompson:I don’t know. I’m schizophrenic on the subject. If you’re writing an operating system or a C compiler or something that’s used by lots and lots of people, I think garbage collection is a mistake, almost. It’s a cheat for you where you can do it by hand and do it better—much better. What you’re doing is your sloughing your task, your job, making it slower for your users. So I think it’s a mistake in an operating system. It almost just doesn’t fit in an operating system. But if you are writing a hack program to do a job, get an answer and then throw the program away, it’s beautiful. It takes a layer of stuff you don’t want to think about, at a cost you can afford, because computers are so fast, and it’s nothing but a win-win-win position. So I’m really schizophrenic on this subject.

Part of the problem is there are different garbage-collection algorithms and they have different properties—massively different properties. So you’re writing some really general-purpose thing like an operating system—if you’re going to write it in a language that garbage-collects underneath, you don’t even have the choice of the algorithm for the operating systems. Suppose that you just can’t stand big real-time gaps and you have a garbage collector that runs up to some threshold and then does mark and sweep. You’re screwed before you start.

So if you’re doing some general-purpose task that you don’t know who your real users are, you just can’t do that. Plus, garbage collection fights cache coherency massively. And there’s no garbage-collection algorithm that is right for all machines. There are machines where you can speed it up by a factor of five or more by messing around with the cache. They should be tied to the machine much more than they are. Usually they treat them as separate algorithms that have nothing to do with machines, but the cache coherency is very important for garbage-collection algorithms.

Seibel:Do you think of yourself as a scientist, an engineer, an artist, a craftsman, or something else?

Thompson:I don’t know. I hate to use the word scientist because I think it’s elitist. And implies a PhD. There’s no certificate that says “scientist” on it when you complete the scientist course, so I don’t like the term or use it. Engineer, I do have a degree that says “engineer” on it, so I can use the word engineer . And when I fill out an occupation I either put engineer or programmer because I can justify those. But mostly I just don’t worry about it.

Seibel:Well, leaving aside what you call yourself, who do you feel the most affinity with? Is it a physicist, a guy who builds bridges, a painter, or a carpenter?

Thompson:Kind of the lower things. I believe a craftsman but with a certain amount of artistry to keep it alive.

Seibel:How do you identify talented programmers?

Thompson:It’s just enthusiasm. You ask them what’s the most interesting program they worked on. And then you get them to describe it and its algorithms and what’s going on. If they can’t withstand my questioning on their program, then they’re not good. If I can attack them or find problems with their algorithms and their solutions and they can’t defend it, being much more personally involved than I am, then no. At the same time you can get a sense of enthusiasm. It’s not something you ask directly, but in the conversation you’ll come with this enthusiasm-ometer, and that is tremendously helpful for me. That’s how I interview. I’ve been told that it’s devastating to be on the receiving side of that.

Seibel:I would imagine. It’s sort of like an oral exam. Do you suppose you’ve ever run into people who just didn’t have the personality that can deal with that, independent of their programming ability?

Thompson:No, I don’t think it’s independent of programming. It would be if I started asking them classical computer-science kind of questions, but that’s not what I’m asking them. I’m asking them to describe something they’ve done that they’ve spent blood on. I’ve never met anybody who really did spend blood on something who wasn’t eager to describe what they’ve done and how they did it and why. I let them pick the subject. I don’t pick the subject, so I’m the amateur and they’re the professional in this subject. If they can’t stand an amateur asking them questions about their profession, then they don’t belong.

Seibel:What are you doing here at Google?

Thompson:Infrastructure. Operating-systems kind of stuff. Glue between the pieces. I have a charter for anything I want. The challenge is to get a bunch of unreliable machines to work like a reliable multiprocessor machine. I guess that’s the closest thing.

Seibel:Isn’t the point of Google’s famous MapReduce machinery that it’s shared-nothing message-passing rather than a shared memory?

Thompson:Well, it’s a process that has well-known semantics and no feedback loops. If you have a reliable structure to do that, you can fit a lot of problems into that structure.

Seibel:And are you working on things within that kind of framework?

Thompson:No, it’s just trying to keep the burden of reliability off the individual programmers. It’s a real tough challenge. All the software here has layers and layers and layers of what happens if this doesn’t work, what happens if that doesn’t work. What happens if I don’t work—who kills me and who starts up, who does what. I would guess way more than 50 percent of the code is the what-if kind.