[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JCSP, CSP Networking, and other some other points
- To: "Jones, Chris C (UK Warton)" <Chris.C.Jones@xxxxxxxxxxxxxx>
- Subject: Re: JCSP, CSP Networking, and other some other points
- From: Ruth Ivimey-Cook <Ruth.Ivimey-Cook@xxxxxxxxxx>
- Date: Thu, 14 May 2009 14:24:01 +0100
- Cc: "P.H.Welch" <P.H.Welch@xxxxxxxxxx>, tjoccam@xxxxxxxxxxx, A.T.Sampson@xxxxxxxxxx, java-threads@xxxxxxxxxx, lewando@xxxxxxxxxxxxx, occam-com@xxxxxxxxxx
- Delivery-date: Thu, 14 May 2009 14:22:48 +0100
- Envelope-to: ats@xxxxxxxxxxxxxxxx
- In-reply-to: <E1M4RKJ-0001Ez-QN@xxxxxxxxxxxxxxxx>
- List-help: <mailto:firstname.lastname@example.org?subject=help>
- List-id: <occam-com.kent.ac.uk>
- List-owner: <mailto:email@example.com>
- List-post: <mailto:firstname.lastname@example.org>
- List-subscribe: <mailto:email@example.com?subject=subscribe%20occam-com>
- List-unsubscribe: <mailto:firstname.lastname@example.org?subject=unsubscribe%20occam-com>
- References: <E1M4RKJ-0001Ez-QN@xxxxxxxxxxxxxxxx>
- Sender: Mailing_List_Robot <sympa@xxxxxxxxxx>
- User-agent: Thunderbird 220.127.116.11 (Windows/20090302)
It's good to hear from you again. I do hope you can find a way to get to the conferences again!
I think occam was ~2 decades ahead of its time, in terms of its possible
acceptance by the wider community. I found it interesting that while
many people grumbled about occam's indenting rules, the very similar
rules of python have not stopped it becoming widely accepted.
You interest me greatly on the demise or potential future for occam.
The thing people still haven't cottoned on to is the point Peter made
many years ago: Turning sequential programs into parallel ones is so
hard that there is no general solution, and very patchy support for
point solutions. However, turning parallel programs into sequential ones
is so easy that we could do it generically in hardware 20 years ago. In
consequence *we should all be writing massively parallel programs*.
The problem is that most people not only think sequential programming,
but cannot conceive that there is a parallel solution.
Surely, if WoTUG has any higher purpose, it is to work to change this?
I'm curious about this - in many ways it was fine for a one-developer
project but I would have hated to use it in a multi-developer one! Was
your experience different?
algorithm in CSP. Of course, we had transputers and the wonderful TDS.
Anyway... have you come across the guys at picoChip
(http://www.picochip.com) or XMOS (http://www.xmos.com) yet? There's
also Tile64 (http://www.tilera.com &
http://www.linuxdevices.com/news/NS8981295285.html), the Cavium Octeon
series (http://www.cavium.com) and many others.
As I was suggesting above... many modern programmers think parallel
programming == threads programming and (rightly in my view) associate
threads with major pain! They also correctly associate threads with
major setup and comms costs - and reducing this was exactly the area
that much transputer work proved was critical in getting good
performance. The result is that for many people I know, parallel
programming is now considered a necessary evil, not something to be
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
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.
IMO the dev system should be up to the user; in some cases, command
lines are entirely appropriate; in others, handholding GUIs are... in
others, interactive interpreters are. I feel quite strongly that any
language solution that mandates the way you use the language is
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
That's not to say TDS wasn't good for its time.
occam 2.1 and its succesors has had access to C libraries for some time
now, and folks have built on that interfaces to various GUI libraries. I
can't imagine it would be too hard to enable access to LINPACK et al.
However, the problem would be that if LINPACK is using parallel
constructs internally then at the very least there would potential for
problems. That's the problem with all these parallel solutions : we
still haven't come up with a way to express a parallel programming
solution that is independent of the environment and language it's
3. Access to standard libraries like LINPACK and NAG. This may be a
solved problem, I haven't looked recently.
There are many examples on the web of "open source" or otherwise
non-profit orgs being created for just that purpose. A trivial example
4. We would have to be able to identify an organisation that would take
responsibility for supporting the compilers.
The actual problem is that it needs people...
Why Fortran? What advantages does it give over all the other (more
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.