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
|