RE: Occam-Tau anyone???

Really good idea. I have been waiting for this for a very long time.

We have sunk to programming our big application in Fortran and C++ with MPI and OpenMP. We run out of stream between 250 and 500 cores depending on problem size and shape. Our next computer will be many more cores. What I really want is to be able to have a mix of data (spatial) and functional decomposition, but that has proved to be far too complex to achieve with present approaches. Prioritisation is also of no concern to me whatsoever,

Chris

Prof. Christopher C R Jones BSc. PhD C.Eng. FIET MIEEE

EMP Fellow of the Summa Foundation

BAE Systems Engineering Fellow

Technologist Consultant – Lightning, EMP & CEM abcd

Military Air Solutions ( Direct: +44 (0)1772 8 54625

Electromagnetic Engineering, W423A ( Mobile: +44 (0)7855 393833

Engineering Integrated Solutions 7 Fax: +44 (0)1772 8 55262

Warton Aerodrome * E-mail: chris.c.jones@xxxxxxxxxxxxxx

Preston : Web: www.baesystems.com

PR4 1AX

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
Exported from the United Kingdom under the terms of the UK Export Control Act 2002 (DEAL No ####)

From: Mailing List Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of David May
Sent: 04 October 2012 23:51
To: Rick Beton
Cc: Occam Family
Subject: Re: Occam-Tau anyone???

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Dear all,

I would like to see an Occam-like language agreed, defined,

implemented and promoted in an open process.

I'm not interested in discussions about how to represent

priority. There were several very good reasons why this was

relegated to the 'configuration' section of the original language

specification. In the meantime, nothing has changed.

The occam-pi language is an over-extended version of occam

with no formal specification. Some of the novel features have no

efficient implementation in message-passing distributed memory

machines.

So my suggestion is that we start form occam2, and look at what

we need to add from occam3 and occam-pi. What is essential?

I've been working on language issues for quite a while now -

mainly looking at how we can really get value out of thousands

of processors.

Not sure how best to do this but I'd like to see it happen. I'd be

happy to host a meeting.

Best wishes

David

On 4 Oct 2012, at 20:38, Rick Beton wrote:

Hi all,

I started the original discussion following Peter's 'Occam Obviously' presentation, but sadly the language discussion petered out, lapsing into a fascinating but many-year-long rehearsed discussions on priority.

My original hope was to seek an answer to this question: if the answer is Occam (obviously or otherwise), what will it take to make Occam generally usable? In its present form it is not so.

Then there's the question of aspiration versus practicalities. The first suggestion I made was for packages to be added to Occam-pi and I put it first deliberately. Not a new suggestion, this; in fact Occam3 had 'modules' way back in 19xx (choose your own xx). I don't really care for the details of the implementation, I'm much more concerned that Occam-pi/-tau should belong to a busy community, inspired by (a) clarity of thinking and (b) a need to make things happen.

If this is wishful thinking, then alas Occam is not obviously going ever to be more than a teaching tool.

So, what next?

Rick