[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Quote from CACM paper: cost of parallelism

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

Sorry to be a little slow on this, but...

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. 

Larry Dickson

On Sep 18, 2009, at 8:25 PM, Rick Beton wrote:

I haven't read the reference yet  - I ought to, but I felt inclined to share my gut feeling first.

writing multithreaded code tripled software costs

A factor of three, eh? as little as that?!

I write primarily as a Java developer and I guess it comes down to the skills of individual colleagues.  Some seem totally at ease with complex dynamic behaviour and rise to the challenge of Futures and Executors and the like.  But I think most just "have a go", blithely ignorant of uncaring of the serious issues involved.  This leads to testing difficulties, ongoing cost and risk piling up.

I sometimes feel this myself whenever I'm tempted to let loose another 'synchronized' into the wild.  I inevitably find myself a few weeks later, machete in hand, hiking back out into 'the wild' to attempt to re-tame those lost 'sychronizeds'.  I'd rather do a clean JCSP-like design but, usually, there is no other choice because of the constraints of some pre-requisite framework or product we're working with.

Fundamentally, we start from the wrong place for it to be as easy as it ought to be.  This is deeply ingrained into our mainstream technology.

I'm not glum about this - aside from perversely enjoying the challenges, I always look forward to the next 'ahah!' conversation with a colleague who's just realised where we're at and what might be possible if our starting point were slightly different.

Rick :)
Big Bee Consultants Limited : Registered in England & Wales No. 6397941
Registered Office: 71 The Hundred, Romsey, Hampshire, SO51 8BZ