Feb17

Abstract Thought

Categories: Productivity
Sorry there isn’t much going up here, but we are all busily preparing for a huge presentation to Darpa. This is where we tell them all of the wonderful things we’ve done, and the wonderful plans we’ve made. Then we hope that they want us to do more of them.Anyway, though my partners are busy preparing posters for the presentation, my talk is frozen and I have a little bit of time. So I thought I’d talk a little about abstraction.
The mantra among the software engineering community is that increasing the level of abstraction (the language level) increases productivity. There is certainly some truth to that. One poster child for abstraction is garbage collection, which replaces allocation and deallocation with the abstraction of infinite memory. For programs where this works, it truly does improve productivity. All is not, however, sweetness and light.

I recently sat in on a panel of HPC managers and programmers, talking about what would improve their lives. A manager got up, and said that he wanted a high level language that matched the abstraction of mathematics, in which the compiler and runtime took care of all of the performance issues. A programmer got up and said that he wanted a high level language that gave him explicit control over data layout and similar performance-related issues. Of course, as is usual, both are right. The manager is right to want an abstract language that will make it easier to translate mathematics into programs. The programmer, on the other hand, had to face the fact that the abstraction offered is never perfect. In particular programs, as opposed to equations, have performance characteristics. They may be too slow, or too big, and the programmer, armed only with the high-level code, has no control over either factor. What he needs is a way to ignore the abstraction, which is imperfect in the ways that he cares most about, and to manipulate those performance elements directly.

Guy Steele has been designing a language that tries to meet both requirements. You can read about it in general or in excruciating detail, but the important idea related to our current discussion is that it provides a separation between the abstract algorithm specification and the important implementation details that determine speed. The other HPCS vendors have their own languages with similar characteristics. Cray is developing Chapel and IBM is developing X10. The PGAS languages UPC and Fortran, which I mentioned earlier, are another, though lower level, attempt to add data placement to the language while keeping algorithmic development simple. These languages are a recognition that the abstractions offered for programming mathematics are broken in ways that are important for HPC.

Sometimes, though, abstraction fails simply because it’s harder to use than more direct approaches. Sometimes, you are much better off with direct manipulation of important objects. My favorite example is the game editor offered with products like WarCraft. (Note that I resisted the temptation to add a link to the gaming company!) When you are building a field to play the game, you don’t want to write a loop that puts mountains, N, E, S, but not in the middle, and a ridge running NW to SE. No, you want to say “Mountain. There. There. There, (no, remove that one), There….”. If you don’t like computer games, consider a GUI builder, it’s the same sort of thing. This is a case where direct manipulation of the objects of interest beats going though a set of indirect steps. Oh, yes, this is a lot more abstract than bits, but it reduces the task to a concrete one, not an abstract one.

More on this later, I need to knock off for some sleep.

Feed for this Entry Trackback Address

Leave a Reply