Hi Ralph --
I don't think either Ungar's architecture or the criticism of it below address the most important issues of making VHL object-oriented computer hardware (both then and now).
Cheers,
Alan
At 08:05 AM 5/24/2007, Ralph Johnson wrote:
Here is what Dave Ungar says he did on the project (among other things): http://www.linkedin.com/in/davidungar
His thesis is online at ftp://sunsite.berkeley.edu/pub/techreps/CSD-86-287.html
It also got turned into a book: http://www.amazon.com/Evaluation-Performance-Smalltalk-Distinguished-Dissert...
Here is some criticism of his results: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/txt/garbage/...
I like his thesis very much, but there is certainly room to argue with the conclusions, if for nothing else than that the world has changed in the last 20 years.
-Ralph
On 5/24/07, Alan Kay alan.kay@squeakland.org wrote:
Hi Ralph --
I don't think either Ungar's architecture or the criticism of it below address the most important issues of making VHL object-oriented computer hardware (both then and now).
I would be interested in knowing what issues you think are the most important.
The thesis is Ungar's, but the architecture is not. I think the architecture was a group project by Patterson's students.
The point of the thesis is that a lot of proposed hardware features don't help performance very much, and in fact there are software solutions that are more effective. This is a good point. However, it doesn't mean that no hardware features can help. Moreover, it assumes that hardware is expensive and software is cheap, and in fact the opposite is true. People have been working on a JIT compiler for Squeak for some time, and we aren't using one yet. It is easy to say "just put it in the compiler", but it might be too complex to ever get the compiler working.
What do you think are the main issues?
-Ralph Johnson
Ralph Johnson writes:
The point of the thesis is that a lot of proposed hardware features don't help performance very much, and in fact there are software solutions that are more effective. This is a good point. However, it doesn't mean that no hardware features can help. Moreover, it assumes that hardware is expensive and software is cheap, and in fact the opposite is true. People have been working on a JIT compiler for Squeak for some time, and we aren't using one yet. It is easy to say "just put it in the compiler", but it might be too complex to ever get the compiler working.
But we've been making continuous progress towards a JIT for the last few years. I doubt that finishing Exupery would cost anything like what a modern high performance CPU costs to design. Exupery has just started compiling in the background, a few bugs need to be fixed before that's a safe way to run it. It is progressing.
Writing in Smalltalk is a good way to keep development costs down.
Bryce
On Thursday 24 May 2007 10:32 pm, Ralph Johnson wrote:
The point of the thesis is that a lot of proposed hardware features don't help performance very much, and in fact there are software solutions that are more effective. This is a good point. However, it doesn't mean that no hardware features can help. Moreover, it assumes that hardware is expensive and software is cheap, and in fact the opposite is true.
Mmm.. Software and hardware represents two end of a continuum, so both propositions are over simplifications.
The fixed costs in hardware is so high now that it is economical only if manufactured in large numbers. Therefore it is important to get 'it right the first time'. This depends on the accuracy and precision of the design and testing tools. The dependency trace will lead you back to building software that 'works the first time'. Doing that is not cheap. Dijkstra's Turing award lecture goes into why producing correct software in the large is so difficult. Until we solve these issues and learn to produce microcode/nanocode/picocode within acceptable limits of accuracy, the system costs will be tough to control.
Regards .. Subbu
On 24-May-07, at 8:49 PM, subbukk wrote:
The fixed costs in hardware is so high now that it is economical only if manufactured in large numbers. Therefore it is important to get 'it right the first time'.
Not if you do it right and build highly programmable hardware. The only thing you have to fear then is someone discovering the secret of the Halt and Catch Fire instruction[1]
tim
[1] I worked with a chap at IBM who used a pair of 29116 bitslice cpus in a project. It was entirely possible to cause a tri-state bus contention that really would execute the HCF instruction. Amusing but expensive. Possibly a useful anti-theft mechanism?
-- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Fac me cocleario vomere! = Gag me with a spoon!
On Friday 25 May 2007 11:02 am, tim Rowledge wrote:
On 24-May-07, at 8:49 PM, subbukk wrote:
The fixed costs in hardware is so high now that it is economical only if manufactured in large numbers. Therefore it is important to get 'it right the first time'.
Not if you do it right and build highly programmable hardware. The only thing you have to fear then is someone discovering the secret of the Halt and Catch Fire instruction[1]
'doing it right' is a big if :-). I was referring to the costs of masks (few million) and the fab costs (a few billion). The cost of the first CPU is quite steep. ASICs and FPGAs are cheaper because it is easier to get them right in the first place.
There is a big 'impedance mismatch' between mass CPUs of today and what Dynabook needs means that the cost of the first Dynabook CPU will be quite steep. It would be easier to create a Dynabook virtual machine (like qemu) in software and experiment with it for a few years before taping out silicon.
Regards .. Subbu
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
bryce＠kampjes.demon.co.uk -
Ralph Johnson -
subbukk -
tim Rowledge