home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / parallel / 1799 < prev    next >
Encoding:
Text File  |  1992-07-27  |  2.7 KB  |  59 lines
  1. Newsgroups: comp.parallel
  2. Path: sparky!uunet!gatech!hubcap!fpst
  3. From: mccurley@cs.sandia.gov (Kevin S. McCurley)
  4. Subject: Re: Description of C*
  5. Message-ID: <1992Jul27.140906.25891@hubcap.clemson.edu>
  6. Apparently-To: comp-parallel@ucbvax.berkeley.edu
  7. Sender: usenet@cs.sandia.gov (Another name for news)
  8. Organization: Sandia National Laboratories, Albuquerque, NM
  9. References: <1992Jul23.134937.5098@hubcap.clemson.edu>
  10. Date: Fri, 24 Jul 92 04:21:51 GMT
  11. Approved: parallel@hubcap.clemson.edu
  12. Lines: 45
  13.  
  14. In article <1992Jul23.134937.5098@hubcap.clemson.edu> peteh@cs.rhbnc.ac.uk (PeterR.Hoare) writes:
  15. >Could anybody tell me where I can get a good reference to the new
  16. >version of C* which is being proposed as a ANSI standard parallel C.
  17.  
  18. OH NOOOOOOO!
  19.  
  20. Perhaps I have not kept up with what is happening with data parallel
  21. C, but this smells of a potential disaster.  For three years I have
  22. been disgusted with the lack of any reasonably flexible model of
  23. data-parallel C.  I am not an expert in computer languages, but I
  24. write considerable amount of code for parallel machines.  For three
  25. years I kept thinking that if I just waited until a reasonable
  26. replacement came along for the CM-2, then maybe we would see some
  27. reasonable data-parallel version of C come along to replace C*.
  28. Numerous times I have thought about writing some application in C*,
  29. only to realize that it would be severely limited by the lack of
  30. parallel pointers.  In my opinion adopting C* as the base for
  31. data-parallel C is ludicrous, since it is far too restrictive.  C* was
  32. designed years ago for a machine whose processors were incapable of
  33. doing indirect addressing, and required every processor to have an
  34. identical memory map.  It has some nice features, but it has a long
  35. way to go until it will be powerful and flexible enough to allow
  36. people to parallelize existing serial code in a natural way. 
  37.  
  38. I would hope that any new standard would get us beyond this, and look
  39. forward to what programmers will want to use in the future.  In my
  40. opinion it is far too early to adopt such a standard, and the parallel
  41. computing community (including TMC) would be better served by letting
  42. data parallel C mature more before pushing for a standard.  In the
  43. meantime there is a glaring need for more work to be done on this
  44. subject.
  45.  
  46. I am simply a scientist who has longed for a data-parallel C language
  47. that would allow me to express my algorithms in a straightforward and
  48. efficient manner.  I am not a language expert, so it is possible that
  49. I do not understand all of the issues involved.  On the other hand,
  50. you don't have to be a racehorse breeder to recognize a horse with no
  51. teeth and a potbelly.
  52.  
  53. Kevin McCurley
  54. Sandia National Laboratories
  55.  
  56.  
  57.  
  58.  
  59.