Tuesday 5 August 2008

Von Neumann Machine: why we love it.

There are a couple of things we should not forget:

(1) Hardware is about software.

(2) The diversity of software, in size and in behaviour, is staggering: and they should coexist in the same machine.

(3) Not only coexist: they need to do so asynchronously. First they are often unrelated, which is the simplest way to be asynchronous: then they will interact, and an application may demand some service at any point during its run --- we cannot predict --- for example some part of JVM will become necessary abruptly; some part of GNU library; some part of OS functions. That's how your applications work, and that's why these services need always be prepared. They are interactional.

And this is precisely what a Von Neumann machine, combined with the good old operating system architecture, can offer us: numerous pieces of software running asynchronously which may be interacting from time to time (there are further internal interactions which are hidden: we shall come back to them in later posts). Its linear memory is ideal for putting the diversity of data structures and code laid out; combined with its engineering simplicity (and here we do not intend to give any scientific elucidation of this point but just note its beauty and effectiveness coming from its simple profile) we find what this abstract machine model offers us so convenient an ecosystem for software. While the current discussion does not intend to capture the key features of this machine model with precision (for example: what element in VNM enables this asynchrony?), we have at least obtained one way to view its value --- why it is being used and why it is so robust.

There is another thing we should not forget: this model has generality, and we can build our software infrastructure essentially on the same general abstract machine, even if different applications have different purposes, and different programmers program in so diverse ways, so this is just a corollary of Turing completeness, but we cannot avoid reality: software technologies built on a general hardware interface work --- even if it is built in a rather care-free, sloppy way.

Yes that is one of the secrets: without really really good notions of types, without really really good support of assertions, our software is working, in fact if you can program for Mac you can program for PC and you can perhaps program for a mainframe computer and you may even be able to program a Cray machine (well you should study a bit if your program is to run fast and yes this is reaching a different realm but anyway they are after all the same sort of computers!); and layers of layers of libraries, APIs, network stacks, OSes, applications --- they all simply work --- in some ways or other.

So here is the axiom:
if a system of software infrastructures is built on a general hardware architecture, even if they are built with human's fallible skills, and her/his usual sloppiness, without much support from types etc., they may still work. And perhaps it will work very well if we do build infra with good care about foundations.
As to the last part of the axiom above, my argument goes further: in the coming era of inherent concurrency we dearly need foundations if we wish to be effective. But let's not go too fast: let's stick to the problem at hand. In summary our machine model is good fot the diversity of software, in the sense that it gives us a good abstract basis for the flourishing ecology of software, and perhaps relatedly in that it is general, it works with the same general principle whatever your purposes are and whoever the manufacturer of your hardware would be.

And this machine is abstract not only as an abstraction but in its concrete origin: it was not born as an abstraction of the diversity of hardware but rather all these different kinds of hardware started from this abstract machine, first Turing then Von Neumann (in Turing machine we already find the same kind of programming as we do now for Pentium or ARM or PowerPC, an early beautiful example is by Kleene). And when the originators of RISC went back to Von Neumann its simplicity and generality are again made the best of.

So we have been using machine models which are based on an abstract machine with general principles (and therefore can be used for all different purposes) which are moreover based on asynchrony --- if I am to give a very crude summary of the pre-CMP era, this is it. And I believe these criteria are rather basic --- at least in the age computing is and software is intrinsic part of our society, part of our life --- I think these will continue to be basic principles, with some fluctuations. For example any hardware architecture (say a microprocessor with multiple cores) which does not satisfy these properties may not be a good engineering basis for future programming.

In other words: let's not compromise until we reach something everybody can agree on.

* * *

In spite of my promise in my last post I went into software. In fact I am finding I may need to dwell on it for some time, before we can discuss one of the root causes that is making our hardware model asynchronous.

kohei