Eugene Leitl wrote:
> Perhaps I should illustrate what I mean by fine grain. Let's say I'll
> order ~4 k of chips like
>
> http://products.analog.com/products/info.asp?product=ADSP-21160M
>
> hotglue them onto a stack of perforated plexiglas sheet and wirewrap
> them gluelessly into a 16x16x16 DSP array (adding little LED blinkenlights
> to each link port for cuteness value), putting the edge node as a PCI
> card into a garden-variety Linux box. So this gives me 2 GBytes of
> on-die memory a la 4 MBit each, in toto a ~10 kW heat dissipation
> (heck put it into an aquarium filled with Fluorinert and mount an
> aircooled heat exchanger on top of that), 2.4 TFlops peak box in
> a half-height 19" rack (for how much? 100..500 k$? ballpark of a
> high-end workstation) -- enough horsepower to upload a nematode, or
> even a fruit fly. It's comparatively easy (well, possible) to write
> a nanokernel OS taking 4..16 kByte memory footprint or so, so this
> leaves me with essentially half a MByte/node to work with --
> however, how do you expect to port Excel to such an architecture?
> How much of Microsoft (or OpenSource stuff, for that matter)
> warez are written as asynchronous message-passing object soup?
AFAIK, all Microsoft apps have been written as "asynchronous message-passing object soup" since sometime in the mid-90s. Also, with the right software you can run a large app over a distributed architecture like this without having to explicitly modularize it to fit the hardware's quirks (see http://research.microsoft.com/sn/Millennium/, and especialy http://research.microsoft.com/sn/Millennium/Coign.html, for example).
But that isn't especially relevant, anyway. I was talking about programming techniques for existing PC hardware. Obviously, radical changes in hardware can require equally radical changes in programming methods.
Billy Brown, MCSE+I
ewbrownv@mindspring.com