oo hardware (was: Why so few garage processors?)

Alan Kay Alan.Kay at squeakland.org
Fri Mar 21 00:40:55 UTC 2003


Hi Jecel --

I think you've made here what I consider the most important points about this.

I would only add one thing. At PARC we estimated that we could get 
about a factor of 5 from special low level (HW+firmware) design.  If 
Moore's Law is doubling every 18 months, then this is almost 4 years 
of being ahead if you can compete with ordinary silicon (your factor 
of 8 would be 3 turns of Moore's Law, or about 4.5 to 5 years). The 
Alto was a big success because it took Chuck Thacker and two 
technicians only about 3.5 *months* to make the first machine, and it 
only took another month to move the first Smalltalk over from the 
NOVA to the Alto. So we were off and running.

If we believe Chuck's estimate that we've lost about a factor of a 
thousand in efficiency from the poor design choices (in many 
dimensions) of Intel and Motorola (and Chuck is a very conservative 
estimator), then this is 10 doublings lost, or about 180 months, or 
about *15 years* for Moore's Law to catch up to a really good scheme. 
This is a good argument for trying very different architectures that 
allow a direct target to be highly efficient VHLL *system* execution.

A small group approaching this should try to do everything with 
modern CAD and avoid getting messed up with intricate packaging 
problems of many different types. So I would look at one of the 
modern processes that allows CPU and memory logic to be on the same 
die and try to make what is essentially an entire machine on that die 
(especially with regard to how processing, memories and switching 
relate). Just how the various parallelisms trade off these days and 
what is on and off chip would be interesting to explore. A good 
motivator from some years ago (so it would be done a little 
differently today) is Henry Fuch's "pixel planes" architecture for 
making a renderer as a smart memory system that has a processor for 
each pixel. Such a system can be have a slower clock and still beat 
the pants off a faster single processor von Neumann type architecture.

Cheers,

Alan

At 8:53 PM -0300 3/20/03, Jecel Assumpcao Jr wrote:
>On Thursday 20 March 2003 07:49, Torsten Sadowski wrote:
>>  [...] My personal interest faded when I realized how much work it
>>  would be and when I read an article by David Ungar "Is Hardware
>>  Support for OO Languages really necessary". He says no and he was one
>>  of th main designers of SOAR.
>
>I really recommend the paper you mentioned to anyone interested in this
>thread:
>
>   http://www.cs.ucsb.edu/labs/oocsb/papers/oo-hardware.html
>
>While Urs Hölzle did a great job, in my opnion the question he really
>answered "no" to was "does patching a processor optimized for C help OO
>languages?"
>
>People looked at the output of C compilers and then created the best
>possible chip for running that. Urs looked at this processor and then
>created the best Self compiler for that. Finally, he looked at the
>things that had made a large difference in SOAR (tagged integer math
>instructions, register windows, etc) and noticed that the output of the
>Self compiler was so similar to that of a C compiler (duh!) that they
>wouldn't help here. Only a larger instruction cache (of course - with
>dynamic translation we trade off memory for speed, so more memory
>helps) and a different data cache policy made a difference.
>
>But suppose that you were not limited to tweaking. If you could adopt
>the virtual object cache of the Mushroom project, for example. Like N.
>Vijaykrishnan did for a Java processor in his PhD thesis
>(http://www.cse.psu.edu/~vijay/dissertation.ps). Then you might have a
>very different result.
>
>>  Language requirements change and
>>  processors are rather static which might lead to dead ends as CS goes
>>  on.
>
>Alan already commented on the need to stay flexible. And certainly it is
>a bad idea to hardwire the state-of-the-art garbage collector or
>something when somebody will come up with a far better idea soon that
>can beat your solution when implemented in software on a stock
>processor.
>
>But the real tragedy for language specific processors are simply the
>difference in resources. Even Motorola can't seem to keep up with
>Intel, so why should a small academic (or start up) team be able to?
>You start your project in 2003 thinking you will get 8 times the
>performance of the Pentium IV 3GHz with your little bag of tricks. But
>in 2006 you will still be working on exactly the same design and what
>will Intel have out by then?
>
>Now suppose you can get a competitive solution working on an FPGA. If
>somebody comes up with a better idea, just patch your VHDL and
>recompile! And you get to ride Moore's law like all the big guys since
>faster and cheaper FPGAs will be coming out every year.
>
>-- Jecel


-- 



More information about the Squeak-dev mailing list