Seibel: You mean in the sense that you can have a pointer into the middleof a struct or an array?

Allen: Yeah, into an element of it. And that brings, depending on theprotocols of the hardware and of the architecture itself, the value to whereit can be used as part of the computation.

But another way to do that would be to organize locations of data in theirrelative positions as a target of optimization. The other part of it is that veryoften what is good for one computation is poor for another. Oneorganization, even of simple things like matrices, is bad when you’re actuallyaccessing it in a different way. So it’s a combination of the order of theaccessing against the location. It may require some architectural work, andhardware work, but I think that one can do this if we put some of thereferencing, addressing capabilities back out in the hardware itself. Thereare machines where one has the ability, at the point data comes into thememory, to do quite a lot of transformations. Mapping can happen there.

Computation speed is what we measure, mostly, in high-performancecomputing so we go through all kinds of things to increase that speed.Feeding that computational unit is one of the big issues that we face, but wenever made it a first-order problem to solve. We leave it to the hardware.

Seibel: In your Turning Award lecture you said something along the linesof, “We’re at a crossroads here and we might miss it. We might go downthe wrong path and then be going down it for quite a while.”

Allen: Yeah.

Seibel: So the right path, in your view, is getting back to that kind of workin automatic parallelization?

Allen: Right, but it has to be done against a higher-level language than wehave now.

Seibel: And the wrong path is finding better ways for people to expressparallelism explicitly?

Allen: Well, I think we would eventually realize that we’ve created more ofa mess than we had. But we do need higher-level languages and therecertainly are domain-specific languages, and ways of developing things, whichare really quite wonderful.

But we have to be willing to try and take advantage of that, but also takeadvantage of the integration of systems and the fact that data’s coming fromeverywhere. It’s no longer encapsulated with the program, the code. We’reseeing now, I think, vast amounts of data, which is accessible. And it’snumeric data as well as the informational kinds of data, and will be stored allover the globe, especially if you’re working in some of the bioinformaticskind of stuff. And we have to be able to create a platform, probablycomposed of a lot of parts, which is going to enable those things to cometogether—computational capability that is probably quite different than wehave now. And we also need to, sooner or later, address usability andintegrity of these systems.

Seibel: Usability from the point of the programmer, or usability for the endusers of these systems?

Allen: Of the end users of these systems. It’s a resource, a giant resource.And the integrity of the correctness of the systems. I worked on project forthe NSA on risk management, quite a few years ago, and it suddenly dawnedon me that we often, in high-performance computing, do not need tocompute to the accuracy that we have. We do not need all the data to beable to make progress on a solution. And so there’s some nice work goingon in the data side, I think, with accommodating good enough answers. I seethese multicores—they’re a wonderful opportunity—to go back and to takeanother look at lots of things.

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

Allen: I think of myself as a computer scientist. I was involved in my cornerof the field in helping it develop. And those were interesting times—theemergence of computer science—because there was a lot of questionabout, “Is this a science? Anything that has to have science in its name isn’t ascience.” And it was certainly unclear to me what it meant.

But compilers were a very old field—older than operating systems. Someday want I to really look it up. The word compiler comes actually from theembedding of little snippets of instructions to execute. Like an add would bespelled out in very primitive terms for the machine. If you want to do anadd, then it would go to its library that defined that and expand it.

But assemblers were also using symbolics. I’m not sure this is accurate, but Iused to believe that the first early use of symbolics for names of variablescame from a man named Nat Rochester, on a very early IBM machine, the701 around 1951. He was in charge of testing it and they wrote programs totest the machine. In the process of doing that, they introduced symbolicvariables. Now, I’ve seen some other things since that make me believe thatthere were earlier ways of representing information symbolically. Itemerged in the early ’50s, I think, or maybe even in the ’40s. One wouldhave to go back and see exactly how things were expressed in the ENIAC,for one thing.

Seibel: So somewhere along the line, you realized you had become acomputer scientist, developing theories about compiler optimization and soforth. But you started out as a programmer, hired to write code. By thetime of the PTRAN project you were managing a team of people who wereactually writing the software. Why did you make that switch?

Allen: Well, probably two reasons—one, I wasn’t a very good programmer.I tended to make quite a few mistakes—unlike the conventional wisdom atthe time that said that women make good programmers because they payattention to details. I didn’t fit that category. So I tended to be kind ofdisinterested in getting all the details right and I was much more interestedin the way systems work.

My interest in mathematics was very abstract. If I had had enough money to goon to get a PhD, I would have become a geometer. I loved the rigor of thatprocess. That’s what I really most enjoy, puzzling through systems—puzzlingthrough the engineering kinds of things without necessarily knowing the detailsof what one would need to know to be an engineer, which is quite a differentarea.

Seibel: The way you contributed technically to the PTRAN project, itsounds like you had the big architectural picture of how the whole thing wasgoing to work and could point out the bits that it wasn’t clear how theywere going to work.

Allen: Right.

Seibel: Do you think that ability was something that you had early on, ordid that develop over time?

Allen: I think it came partially out of growing up on a farm. If one looks at alot of the interesting engineering things that happened in our field—in thisera or a little earlier—an awful lot of them come from farm kids. I stumbledon this from some of the people that I worked with in the NationalAcademy of Engineering—a whole bunch of these older men came fromMidwestern farms. And they got very involved with designing rockets andother very engineering and systemy and hands-on kinds of things. I thinkthat being involved with farms and nature, I had a great interest in, howdoes one fix things and how do things work?

Seibel: And a farm is a big system of inputs and outputs.

Allen: Right. And since it’s very close to nature, it has its own cycles, itsown system that you can do nothing about. So one finds a place in it, and it’sa very comfortable one.

Seibel: You mentioned earlier that when you were working on the Stretchcompiler, that three of the four people leading the compiler effort werewomen. Can you talk about how that came about?

Allen: This was in ’59, something like that. Women were playing a big roleat that time as programmers. And IBM has always been a great, greatcompany on that. I saw some history recently, that IBM’s diversity policiesgo back to 1899, just consistently, all through these periods when therewasn’t much attention being paid to that—very explicit policies.