Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!ucbvax!vax1.physics.oxford.ac.uk!HALLAM From: HALLAM@vax1.physics.oxford.ac.uk ("Phillip M. Hallam-Baker") Newsgroups: comp.sys.transputer Subject: Re producers and consumers Message-ID: <1461.9101292134@prg.oxford.ac.uk> Date: 29 Jan 91 21:35:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 75 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.