This is inside parentheses: I happened to find my immature old memo on a thin book on philosophy (from 2006!) in a web bookshop. It was not about my speciality and the writing was far from up to quality --- I had accidentally posted it after reading this beautiful book and asked the bookshop to withdraw it: and they said they would do so (at that time the site did not allow a poster to cancel such a post oneself).
I suspect it has been there for some time: if so I wonder why I was not aware of it. Now that I found that it has been there at least for some time I feel somewhat stupid to cancel it: after all it has already been public for a while, though I may in the end cancel it, after some time (I should say I spent only a few minutes in writing it, immediately after reading that book).
What I wrote there is not as clear as I'd like my writing to be nor will it be useful for others --- but I do not find the need to add to or retract from that old note, at least what I had written might be honest in its own way, except recording one point: the author of that book is known to be both a great scholar and a political personality; and I am learning about some basics of that social part, on which I wish to unequivocally admit that I am ignorant (that little book however does not refer to this political aspect directly). I am hoping that my learning on that topic, which is slowly proceeding, will be enriched by interactions with my new acquaintance(s) in the modelling and other worlds: since the conversations with sincere individuals whom I respect are what I value most when learning about an intricate historical topic, as well as the reading of those words left by good authors.
kohei
Sunday 10 August 2008
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:
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
(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
