| 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 ;-) But none of us that I know of, including myself, has actually done anything about this...
And the key is what Rick says, we start from the wrong place. 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. 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.
Except, of course, we don't really have to. We can start from scratch and do it right. (Transterpreter on the Cell, anyone?) Somebody ought to notice that ending this tripling of effort would make it worth it.
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
|