[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JCSP, CSP Networking, and other some other points
Hi,
Just forwarding a posting from Chris Jones on the above ...
Peter.
---------------------------------------------------------------------------
From: "Jones, Chris C (UK Warton)" <Chris.C.Jones@xxxxxxxxxxxxxx>
Sent: 08 May 2009 13:46
To: 'Larry Dickson'
Subject: RE: JCSP, CSP Networking, and other some other points
Larry,
Sorry I do not know how to send this directly to the mailing thingy.
You interest me greatly on the demise or potential future for occam.
We would still be using occam if we could. Many years ago, we rewrote a
large code for simulating electromagneitc effects on aircraft -
particularly lightning - into occam (it is about 140,000 lines now and
was proably about 100,000 then). We first analysed the main core of the
algorithm in CSP. Of course, we had transputers and the wonderful TDS.
It worked, was easy to maintain and continue to develop and we had more
fundamental proof of the correctness of the implementation than we can
now dream of. Sadly, our T9000 machine never actually happened and we
accepted parallel PowerPC processors with transputers handling the comms
instead. Even more sadly, we had to rewrite our code back into the
original Fortran, though by having gone through occam, it was much
easier and bug free than the original had been. That code would still
be occam if we had not been forced to reveert to Fortran for lack of
occam implementations on other commodity processors.
Even now, we would write some applications in occam were there a
reasonable way of programming a large parallel computer - we currently
run 128 quad cores with a Quadrics switch. There are some issues
though:
1. Lack of occam knowledge - actually this is far worse than it sounds.
We lack parallel computing knowledge at a fundamental level. Making
cals to MPI libraries is not the same thing.
2. Personnally, I'd like to see a development systems akin to the old
TDS - I am so old I actually do not like the modern programme writing
pardigm with thousnads of interlinked filelets requiring a compendium of
flow charts and dependency diagrams and spreadsheets to track effects.
I am actually in a day-mare trying to sort out such a problem at the
moment.
3. Access to standard libraries like LINPACK and NAG. This may be a
solved problem, I haven't looked recently.
4. We would have to be able to identify an organisation that would take
responsibility for supporting the compilers.
The lack of knowledge of occam is an interesting one in its own right
since we are moving towards this same situation on Fortran. My daughter
has been searching for a job in or around Edinburgh having completed her
physics degree. She found plenty of jobs requiring Fortran knowledge
but none for Java. Unfortunately the only programming language the
university would teach was Java. I had a scan across a range on UK
universities and found the same was generally true - even including the
Opne University. I draw the concluding that Sun is trying to do with
Java what it did decades ago for the early Sun workstations.
Edinburgh's stated justificaion was transportability, and then gave out
homework involving proprietary and University only libraries!
As a matter of interest, we have the following numbers of people
profient in respective languages:
Fortran 3
C 5
C++ 1
Matlab 2
Tcl 3
PERL 1
Python 1
Pascal 2
Occam 1
Java isn't even on the list and is not going to be for the forseealbe
future. Even the new codes we are looking to develop over the next 5
years will all be largely Fortran.
I would love to have transputers available again. The pain of making
codes run let alone well on Intel or AMD multi-core processors is not
pleasant. Occam would be used here if we could obtain from its use it's
primary benefit of programming large multi processor machines. I might
even realise my dream of hybrid data and functional parallelism. But
this will not happen till we have a reasonable way of launching code on
multiple processors from a perameterised architecture description - as
we could from the old TDS.
Regards,
Chris.
Dr Christopher C R Jones C.Eng. FIET
Technologist Consultant
BAE SYSTEMS (Military Air Solutions)
Warton Aerodrome
Preston
Lancashire PR4 1AX
* tel: 01772 854625
* fax: 01772 855262
* e-mail: chris.c.jones@xxxxxxxxxxxxxx
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 ####)