RE: Transputer Development System, 2006? (aka Sony PS/3 runs multi-core Linux)

[tjoccam@xxxxxxxxxxx]

>
> Barry wrote:
>> I'm still trying to find the compelling reason that will convince the
> world
>> to jump to parallel software

I've got to try to do this for DARPA... My thoughts thus far:

Transparency (not hiding the most important part of the design, like
interrupts and peripherals, in "drivers" just because they involve real
parallel hardware and function);

Real components (things that you can hook together and get genuinely
predictable behavior that is the join of the behavior of the parts -- I do
NOT mean the things OO laughably calls "components", but real pieces as
found in an automobile);

As a consequence, this kind of programming does not hit a complexity WALL.
If done wrong, of course, it worsens the complexity wall -- which is why
it has the reputation it has.

Larry Dickson

>
> The office and money, and quality factors:
>
> Office: wysiwyg of a process (one can sit in the office and get things
> done, provided the protocol contract is adhered to)
> Money: less releases, the system works when it works
> Quality: same thing, really
>
> This is what's good about POP!
>
> Med vennlig hilsen / sincerely
> Øyvind Teig
>
>
> Øyvind Teig
> Senior utviklingsingeniør, M.Sc.
> Autronica Fire and Security AS
> A UTC Fire & Security Company
> Tlf: +47 7358 2468 / Faks: +47 7358 2502 / Mob: +47 9596 1506
> oyvind.teig@xxxxxxxxxxxxxxxx / www.autronicafire.no
> http://home.no.net/oyvteig/pub - Publications
>
>
>
>                     "Chalmers,
>                     Kevin"                 To:     "Barry Cook"
> <Barry@xxxxxxxxxxxx>, "Tony Gore"
>                     <K.Chalmers@napi        <Tony@xxxxxxxxxxxx>, "Matt
> Jadud" <mcj4@xxxxxxxxxx>, "Andrew
>                     er.ac.uk>               Delin"
> <Andrew.Delin@xxxxxxxxxxxxx>
>                     Sent by:               cc:     <occam-com@xxxxxxxxxx>
>                     owner-occam-com@       Subject:     RE: Transputer
> Development System, 2006? (aka Sony
>                     kent.ac.uk              PS/3 runs multi-core Linux)
>
>
>                     29.11.2006 16:21
>
>
>
>
>
>
> Hi all,
>
> There are a couple of links in the Transterpreter Wiki about Intel's
> surging forward with more and more cores, one of which is a bit more
> critical of Intel's approach.  My concern is that we are going to see a
> new processor race, with GHz replaced by cores, and no concern over
> whether they can be used correctly (hence my earlier post).
>
> One thing I have noticed, being a game player, is an emergence of games
> that say they are "optimised" to run on multi-core systems.  What do
> they mean by optimised in this respect?  I find it hard to believe that
> an industry of that size can all of a sudden do a paradigm shift so
> easily, without any discussion in the press about re-training.  But then
> again I could be misinterpreting their meaning on this.
>
> Kevin Chalmers
> Research Student
> School of Computing
> Napier University
> Edinburgh
>
>> -----Original Message-----
>> From: Barry Cook [mailto:Barry@xxxxxxxxxxxx]
>> Sent: 29 November 2006 15:11
>> To: Tony Gore; Chalmers, Kevin; Matt Jadud; Andrew Delin
>> Cc: occam-com@xxxxxxxxxx
>> Subject: Re: Transputer Development System, 2006? (aka Sony PS/3 runs
>> multi-core Linux)
>>
>> Hi Tony,
>>
>> Funnily enough I've just read the IEEE Computer article on
> virtualisation
>> (separate virtual OS's) [pp12-14, November issue]. This is the Nth
> time
>> virtualisation has crossed my horizon and it appears to have a lot of
>> support - I guess IBM proved its value back in the VM/370 days and
> there
>> are
>> now several companies offering software for single-processor machines.
>>
>> It seems to me more like having several CPU's just happening to be on
> the
>> same silicon (with cost savings in sharing memory etc.) - a rather
> limited
>> interpretation of parallel computing. I am certainly finding it useful
> to
>> have a "dual" processor so I can leave a compute-intensive task
> running
>> and
>> still do email (as now) without it going annoyingly slowly.
>>
>> I suspect the occam community is thinking of something more complex in
>> terms
>> of concurrency.
>>
>>       Barry.
>>
>> Dr Barry M. Cook, BSc, PhD, CEng, MBCS, CITP, MIEEE
>> CTO,
>> 4Links Limited,
>> The Mansion,
>> Bletchley Park,
>> MK3 6ZP,
>> UK.
>> ----- Original Message -----
>> From: "Tony Gore" <Tony@xxxxxxxxxxxx>
>> To: "Barry Cook" <Barry@xxxxxxxxxxxx>; "Chalmers, Kevin"
>> <K.Chalmers@xxxxxxxxxxxx>; "Matt Jadud" <mcj4@xxxxxxxxxx>; "Andrew
> Delin"
>> <Andrew.Delin@xxxxxxxxxxxxx>
>> Cc: <occam-com@xxxxxxxxxx>
>> Sent: Wednesday, November 29, 2006 12:07 PM
>> Subject: RE: Transputer Development System, 2006? (aka Sony PS/3 runs
>> multi-core Linux)
>>
>>
>> Hi Barry
>>
>> Out in one part of the world, multicore has got some uses -
> Microsoft's
>> Virtual Server can allocate a virtual machine to a core, so that it is
>> possible (say) to have one core allocated to the "host" and three
> cores
>> allocated to three separate VMs. Since you can then network these, it
> is
>> possible to have very coarse CSP.
>>
>> Now what would be interesting is if this development were to go
> further,
>> and whole chunks of the OS be put onto specific cores.
>>
>> In my area - I do a lot of Windows Small Business Server support, I
>> could see a great improvement in security and robustness. For example,
>> one core handling all the traffic to the outside world e.g. running
> the
>> firewall and VPN processes, and everything else communicating through
>> them would ensure that at least perimeter security could be dealt with
>> more effectively.
>>
>> Overall the security and robustness could be improved, because instead
>> of a monolithic OS that is growing patch by patch, then it is possible
>> to have a divide and conquer approach that makes use of the multicored
>> silicon.
>>
>> Obviously, it would be nice to have a lighter weight inter-process
>> communication than the full Ethernet stack running on Virtual
> hardware,
>> but it seems to me that the server virtualisation is a good target for
> a
>> coarse CSP approach, and at this atage, we need to convince people
> that
>> CSP is a valid approach.
>>
>> Tony Gore
>>
>> email  tony@xxxxxxxxxxxx
>> tel +44-1278-761000  FAX +44-1278-760006  GSM +44-7768-598570
>> URL: www.aspen.uk.com
>> Aspen Enterprises Limited
>> Registered in England and Wales no. 3055963 Reg.Office Aspen House,
>> Burton Row, Brent Knoll, Somerset TA9 4BW.  UK
>>
>>
>>
>>
>> -----Original Message-----
>> From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx]
> On
>> Behalf Of Barry Cook
>> Sent: 29 November 2006 11:35
>> To: Chalmers, Kevin; Matt Jadud; Andrew Delin
>> Cc: occam-com@xxxxxxxxxx
>> Subject: Re: Transputer Development System, 2006? (aka Sony PS/3 runs
>> multi-core Linux)
>>
>> Kevin,
>>
>> It probably says nothing about Intel's views on parallel development.
>>
>> Intel's business is selling chips and if they can offer even slightly
>> more performance for no more effort from customers (keep the same
>> software) they will achieve their goal.
>>
>> Even great gains in performance that include re-development of
> software
>> (whether easy or not, anything is more effort than nothing) are more
>> difficult to sell (recall Inmos).
>>
>> I'm still trying to find the compelling reason that will convince the
>> world to jump to parallel software - and thinking along the lines of
> it
>> needing to be new software and maybe to reduce power consumption (as
> is
>> a paper at Eindhoven). This is leading me to think of embedded systems
>> that are relatively small (in terms of lines of code as well as for
>> energy or size).
>> If you add reliability / safety-critical supported by formalism then
>> Automotive might be a target (as suggested by Eric Verhulst), as might
>> Space.
>>
>>       Barry.
>>
>> Dr Barry M. Cook, BSc, PhD, CEng, MBCS, CITP, MIEEE CTO, 4Links
> Limited,
>> The Mansion, Bletchley Park,
>> MK3 6ZP,
>> UK.
>> ----- Original Message -----
>> From: "Chalmers, Kevin" <K.Chalmers@xxxxxxxxxxxx>
>> To: "Matt Jadud" <mcj4@xxxxxxxxxx>; "Andrew Delin"
>> <Andrew.Delin@xxxxxxxxxxxxx>
>> Cc: <occam-com@xxxxxxxxxx>
>> Sent: Wednesday, November 29, 2006 10:52 AM
>> Subject: RE: Transputer Development System, 2006? (aka Sony PS/3 runs
>> multi-core Linux)
>>
>>
>> Perhaps a little off topic on this one.  Myself and Jon Kerridge were
>> looking at Intel's descriptions and plans with multi-core.  From what
> we
>> can gather, their plan is to remove any need to develop parallel
>> systems, and let the system try and work out the best approach.  It
>> seems Intel believes that parallel development is too difficult.
> Sigh.
>>
>> Kevin Chalmers
>> Research Student
>> School of Computing
>> Napier University
>> Edinburgh
>> >
>> > Hi Andrew,
>> >
>> > Damian Dimmich at is working towards this; he had a paper in CPA
> 2006
>> > that explores just this issue, and has a working port of the
>> > Transterpreter (a small, portable runtime for occam-pi) to the Cell.
>> >
>> >
>>
> http://www.transterpreter.org/papers/dimmich-jacobsen-jadud-cpa-2006.pdf
>> >
>> > Running on top of Yellow Dog would be the easy way in; Damian is
>> > exploring code distribution and code generation for multi-core
> targets
>>
>> > like the Cell, and (currently) has 9 separate instances of the
> runtime
>>
>> > environment on a single CPU.
>> >
>> > See the paper for more details; also, since Damian is on this list,
> he
>>
>> > might have additional comments or be able to address more specific
>> > questions that you or others might have.
>> >
>> > Cheers,
>> > Matt
>> >
>> > Andrew Delin wrote:
>> > > Team, I thought this was interesting.
>> > >
>> > > Why might we be interested in the release of Sony's PS/3 games
>> console?
>> > >
>> > > Because it contains a multi-core Cell processor - and can run
> Linux.
>> > >
>> > > Fred and others - I am wondering if it is possible to release a
> KROC
>> > that targets this platform and takes advantage of the multiple
>> processors
>> > inside the new Sony console. This would give a true parallel machine
>> to
>> > run Occam-Pi. It could be used as a modern 'TDS' with several cores
> to
>> run
>> > on.
>> > >
>> > > Nine cores is very tempting - and rather cheap. I understand the
> YD
>> > Linux distribution doesn't fully use all cores, but perhaps an
>> Occam-Pi
>> > build could? If we can piggy back on the interest in Linux, perhaps
> we
>>
>> > might get more interest in the process-oriented-design philosophy
>> we've
>> > discussed on this group.
>> > >
>>
>> This message is intended for the addressee(s) only and should not be
>> read, copied or disclosed to anyone else outwith the University
> without
>> the permission of the sender.
>> It is your responsibility to ensure that this message and any
>> attachments are scanned for viruses or other defects. Napier
> University
>> does not accept liability for any loss or damage which may result from
>> this email or any attachment, or for errors or omissions arising after
>> it was sent. Email is not a secure medium. Email entering the
>> University's system is subject to routine monitoring and filtering by
>> the University.
>>
>>
>>
>>
>
> This message is intended for the addressee(s) only and should not be read,
> copied or disclosed to anyone else outwith the University without the
> permission of the sender.
> It is your responsibility to ensure that this message and any attachments
> are scanned for viruses or other defects. Napier University does not
> accept
> liability for any loss
> or damage which may result from this email or any attachment, or for
> errors
> or omissions arising after it was sent. Email is not a secure medium.
> Email
> entering the
> University's system is subject to routine monitoring and filtering by the
> University.
>
>
>
>
>
>
>
> THIS E-MAIL AND ANY ATTACHED FILES ARE CONFIDENTIAL, PROTECTED BY
> COPYRIGHT AND MAY BE LEGALLY PRIVILEGED.
> E-mail cannot be guaranteed to be
> secure, error free or free from virus. Neither the sending company nor its
> group of companies accepts any liability whatsoever for any loss or damage
> which may be caused as a result of the transmission of this message by
> e-mail. If verification is required, please request a hard copy version.
>
>
>