Allow me some remarks,
From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Larry Dickson
Sent: zondag 11 oktober 2009 17:06
To: Rick Beton
Subject: Re: Quote from CACM paper: cost of parallelism
I think the key task for our side is what the previous poster talked about - the Cell processor (and similar). We all know that it should be + EASY + to program the Cell, because it's just a slightly disguised PC and B008 with 8 transputers ;-)
Far from. It is a very complex PowerPC with 8 less complex PowerPCs connected by some kind of complex bus. Don't be surprised it is difficult to program. In addition, parallel programming requires concurrency on the individual processor. The only conclusion is that the procssors are in the way of doing it EASILY.
But none of us that I know of, including myself, has actually done anything about this...
have a look at OpenComRTOS (www.altreonic;com). We go as fast as we can taking into account processor limitations, but you get meta-CSP semantics, while still being faster and smaller than almost any other (RT)OS because we used formal methods to design.
And the key is what Rick says, we start from the wrong place.
[EVR] That part is correct.
Namely, the mountain of massive OS constructs and their insistence on hiding the "bare metal". The Transputer was a big technical success because it was driven from DOS, a totally minimalistic non-OS that allowed you to go around it and whack away, in standard code, at things like DMA addresses.
[EVR] No, it was driven by CSP. DOS was not an OS. It was a jump table.
Now we have to tiptoe around the whole attic full of exploding OS and driver constructs, never doing a real design (like a classic car), and the effort involved is not only triple or more, but discouragingly senseless.
Of course, current OS and so-called "modern" programming tools are a pain because they were overdesigned (rather: over developed) and often bottom-up. Fill up the bag with anything that comes to mind, make it look complicated and "big" so it must be good. Wrong. Apply oocam's razor and you would be surprised how lean things can be.
Except, of course, we don't really have to. We can start from scratch and do it right. (Transterpreter on the Cell, anyone?)
No, redesign the Cell implementing the transterpreter in silicon. By the way, have a look at XMOS. This is the closest you can get today.
Somebody ought to notice that ending this tripling of effort would make it worth it.
They only remedy is to show that less code is less power, hence show the "green" value.
On Sep 18, 2009, at 8:25 PM, Rick Beton wrote: