home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / transput / 941 < prev    next >
Encoding:
Text File  |  1992-08-18  |  2.1 KB  |  50 lines
  1. Newsgroups: comp.sys.transputer
  2. Path: sparky!uunet!mcsun!sun4nl!dutrun!dutrun2!dutncp8!rob
  3. From: rob@pact.nl (Rob Kurver)
  4. Subject: Re: Why should you consider using occam?
  5. Message-ID: <rob.714140217@dutncp8>
  6. Sender: news@dutrun2.tudelft.nl (UseNet News System)
  7. Nntp-Posting-Host: dutncp8.tn.tudelft.nl
  8. Organisation: PACT, Delft, The Netherlands
  9. Organization: Delft University of Technology
  10. References: <1992Aug14.155639.1045@EE.Surrey.Ac.UK>
  11. Date: Tue, 18 Aug 1992 12:16:57 GMT
  12. Lines: 36
  13.  
  14. In <1992Aug14.155639.1045@EE.Surrey.Ac.UK> R.Peel@ee.surrey.ac.uk (Roger Peel) writes:
  15.  
  16. >So why is occam not liked by so many programmers?  Well, some write
  17. >sequential code for which occam only provides a few extra benefits.  Fine
  18. >- they can justifiably continue to use a sequential language provided they
  19. >only attempt to run their code on a single transputer.  Parallel
  20. >enhancements to a sequential language might be acceptable for particularly
  21. >large-grained parallel tasks, too, but this is not where occam stands out,
  22. >either.
  23.  
  24. I tend to agree insofar as Roger is referring to sequential languages with
  25. library support for parallel processing added.  Such function calls don't
  26. provide the necessary level of abstraction for fine-grain parallelism,
  27. and often cause an unacceptable overhead.
  28.  
  29. Now, without wishing to get dragged into yet another religious discussion
  30. about programming languages or editors, I feel that I must point out
  31. that the PACT Parallel C compiler has language extensions very similar
  32. to those found in Occam (par, alt, channel) folded into ANSI Standard C
  33. in a natural manner.  This allows fine-grain parallelism to be expressed
  34. just as easily as in Occam.
  35.  
  36. I agree with Roger that many communicating lightweight threads, buffers,
  37. multiplexers etc., combined with a clean and powerful syntax to describe
  38. them makes for a very nice programming model indeed.  This model is now
  39. accessible to both Occam and C programmers alike.
  40.  
  41. Best,
  42.  
  43. Rob
  44.  
  45. --
  46.      PACT                   Rob Kurver
  47.     Foulkeslaan 87         rob@pact.nl
  48.    2625 RB Delft     ph: +31 15 616864 
  49.   The Netherlands   fax: +31 15 610032
  50.