|
Allow me some remarks,
Eric Verhulst From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Larry Dickson Sent: zondag 11 oktober 2009 17:06 To: Rick Beton Cc: occam-com@xxxxxxxxxx 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 ;-)
[EVR] 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...
[EVR] 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.
[EVR] 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?)
[EVR] 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.
[EVR] They
only remedy is to show that less code is less power, hence show the
"green" value.
Larry Dickson
On Sep 18, 2009, at 8:25 PM, Rick Beton wrote:
|