One thing that I would like to bring up for discussion is the recurrence of the same problem at so many different levels in a computing system. In the foil, examples were given for programming languages, operating systems, and network communications. But there are examples at a higher level systems software, for example, database management systems and transaction monitors, layers that some called ``middleware.'' Similarly, there are examples at a lower level. I will briefly explain one that we discussed today at OGI.
In the Synthetix project at OGI, we have been using dynamic code generation to optimize (by specialization and consequent code simplification) Unix File System kernel calls. We have been able to cut out some of the READ code from HP-UX (the HP version of Unix) and have been measuring the performance gains by this shorter code. We have noticed significant variances in the measured kernel call time for exactly the same sequence of machine code, when executed repeatedly, even though it is a machine dedicated for our measurements, running nothing else. This effect is particularly noticeable when READing large chunks of data (e.g., 64KB).
As it happens, the hardware we use (an HP PA-RISC 9000/800 dual processor) has a direct-mapped cache. To avoid pathological cache conflicts, it randomizes the cache mapping in complicated ways. It is quite successful in what it does. But as we move a larger chunk of data, the probability of cache conflicts increases. Because the software (operating system) does not have a meta-interface to control the cache, it is quite hard for us to avoid the conflicts. In fact, we were ``coding between the lines'' to make the caching hardware behave in specific ways.
The point is that we are dealing with a systemic problem here, from top to bottom, not just between a few layers of software interfaces. The mapping dilemmas exist potentially for all the interfaces in the system. The problem is becoming more urgent and obvious partially because of the increasing complexity of the systems we build, which introduce more layers of interfaces.
More technically, one problem that always intrigued me and that was not discussed in the foil paper is the specification of meta-star-interfaces. In other words, how do we peek into the meta interfaces in a recursive way? Suppose that for my performance needs, I really have to look into all the software layers that I use for my distributed multimedia real-time control application?
The recursive composibility of meta interfaces may be an important criterion in the judgement of how we should specify them. From my experience, it is easier to compose declarative statements than imperative statements. For example, suppose I need software modules that satisfy some real-time constraints. It is relatively easy choosing between module A has a response time of 5 milliseconds with a variance of 1 millisecond, and module B has a response time of 3 milliseconds with a variance of 10 milliseconds. If possible, I would like to do this recursively to sharpen the predictability of my software. This is especially the case if module B has a specialized version that can do the job for me, but that has a variance of 2 milliseconds. It is not clear to me how this can be done easily when facing meta interfaces that describe imperative code.
Back to Alphabetical List of Responses
(Last Revised October 1994)