[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JCSP, CSP Networking, and other some other points

Chris,

It's good to hear from you again. I do hope you can find a way to get to the conferences again!



You interest me greatly on the demise or potential future for occam.
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.
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?


algorithm in CSP.  Of course, we had transputers and the wonderful TDS.
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?
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. 


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.
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 embraced. 


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.
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 fundamentally flawed. 

That's not to say TDS wasn't good for its time.


3.  Access to standard libraries like LINPACK and NAG.  This may be a
solved problem, I haven't looked recently.
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 expressed in! 


4.  We would have to be able to identify an organisation that would take
responsibility for supporting the compilers.
There are many examples on the web of "open source" or otherwise non-profit orgs being created for just that purpose. A trivial example is Mozilla. 

The actual problem is that it needs people...


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.
Why Fortran? What advantages does it give over all the other (more recent) languages? 


Best regards,

Ruth