🚀 go-pugleaf

Dear Net,

>>The following was extracted from the article:
Jaap Hollenberg
"People are getting more comfortable with parallelism" - an interview
....
>> There is a tremendous amount of 
>management function placed on him. In the parallel Fortran paradigm the user
>has very little management requirement, he can write an algorithm that - apart
>from the fact that he must use the number of processors - works very much like
>the programming paradigm he is used to.  ... 

Does anybody have any comments regarding this article ? Particularly, can we say
that occam is a producer-initiated language  and Fortran is a 
consumer-initiated language ?

..... yes I have a comment 

	1	I am unable to understand what it means
	2	I don't agree with the parts I can make out.

The premise of the article apears to be that communication based languages
such as occam are less efficient than parallel fortran. The justification for
this apears to be that interprocess communication involves a lot of copying
of data. 

The first point I would make is that `efficiency' is very much less important
to me than coding clarity. I am quite prepared to sacrifice half my CPU time
if it makes the code easier to maintain. The amount of code I see which has
turned into useless junk because of (frequently misguided) attempts at
`optimisation' is quite depressing. If the code dosen't run fast enough I
would prefer to write a tool to perform the optimisation of the code than
start hacking arround in `parallel fortran'. The clarity of the CSP model and
the simplicity of coding it allows are for me it's most significant 
advantage.

My second point is that I do not beleive that the CSP paradigm is inefficient.
Most communications between processes involve small packets of data. Time taken
to copy the data is then less significant than the time taken to set up the
transfer. I agree that passing data arround a single processor via a common
block may be faster for large amounts of data but that trick is not 
particularly effective between different processors (even with shared memory
). In any case it is a technique allowed in the inmos occam compiler - just
turn off the useage checking. Provided that your synchronisation mechanism 
prevents read/write and write/write ambiguites it should work. If you need
that particular optimisation it is avaliable, however a better alternative
would probably be to reduce the amount of virtual parallelism and rewrite 
a parallel section as a single sequential one. If your problem allows effective
use of parallel common blocks in the manner described it almost certainly
isn't taking advantage of virtual parallelism.

Thirdly what is meant by 
>>>>> In the
>parallel Fortran area (anybody's standard, IBM, PCF) it is a receiver-initiated
>transmission.You can assume that the data is somehow left behind by name by the
>producers (we typically associate that with a storage cell in a shared-memory)
>and the consumer then names the data and retrieves it under its own-initiative
<<<<<
?

Does this mean that in this parallel Fortran there is no synchronisation
provided and therfore there is no need to worry about it?

Fourthly Occam and CSP are neither receiver nor originator oriented. The whole
point is that the communication is symetric. The only exception is the occam
ALT which only allows input guards. However it is simple enough to extend the
model to output guards - the only problem being that you start to lose 
efficiency since you have to provide a global synchronisation between all
pairs of processes which might possibly be engaging either directly or
indirectly in a given guarded communication. 

	Phillip M. Hallam-Baker
	ZEUS Group
	Oxford Dept nuclear Physics.