home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / parallel / 1986 < prev    next >
Encoding:
Text File  |  1992-08-26  |  4.9 KB  |  103 lines
  1. Newsgroups: comp.parallel
  2. Path: sparky!uunet!destroyer!gatech!hubcap!fpst
  3. From: Douglas Meyer <dougger@ERC.MsState.Edu>
  4. Subject: Analysis of Parallel Algorithms/Programs (PVM vs Pablo vs ??)
  5. Message-ID: <1992Aug26.193154.19970@hubcap.clemson.edu>
  6. Sender: fpst@hubcap.clemson.edu (Steve Stevenson)
  7. Organization: Clemson University
  8. Date: Wed, 26 Aug 1992 19:31:54 GMT
  9. Approved: parallel@hubcap.clemson.edu
  10. Lines: 91
  11.  
  12. [We are having a hard time getting this particular item through
  13. the network. It has been sent two previous times. If you've
  14. seen this one before and your last name starts with L-N, please
  15. do a quick follow-up to let me know. Steve]
  16.  
  17. I'm currently trying to find simulation/analysis tools which will
  18. allow parallel algorithm/program developers cull through a number of
  19. solution options without:
  20.  
  21.   1.  having to write codes for real machines
  22.   2.  having to write complete codes (ie. to shorted the culling 
  23.          process, it would be preferable to write skeletal codes
  24.          which describe the general communications and computation
  25.          behaviors)
  26.  
  27. The focus is intended to be a rough, qualitative analysis of
  28. "skeletal" programs (programs that do not have the mathematical guts,
  29. but rather approximate the guts with a library function call which
  30. simply indicates how many floating point operations would be done in
  31. critical sections, etc.).  These analyses are only required to account
  32. for very basic, first-order effects, and would probably only permit
  33. the engineer to eliminate those algorithms that are blatantly bad.
  34. Metrics of interest would be things like CPU time, "Real" time, and
  35. average message latency.  The focus is on the SPMD paradigm, with
  36. message passing constrained to a family of "global" or "systematic"
  37. communications patterns (eg. everybody send to the right, everybody
  38. broadcast, global sum, etc. such as is found in the Intel iPSC
  39. library).
  40.  
  41. As I'm sure you have determined, what we are talking about is modeling
  42. a parallel machine in such a manner that the algorithm (in the form of
  43. skeletal code) being analyzed can be "executed" on that model, and
  44. performance information can then be extracted.  I suppose this would
  45. fall into the broad catagory of synthetic modeling.
  46.  
  47. So you can see, that these answers are not terribly detailed, and the
  48. people running this project don't want detailed answers.. just answers
  49. that provide general guidance.
  50.  
  51. ------------------ End of description---------------------
  52.  
  53. I am convinced, through the little bit of reading and research I've
  54. done in the last week that there are a fair number of tools already
  55. developed and reasonably mature.  PVM and HeNCE clearly are for
  56. running complete parallel codes; Express is similar and some of its
  57. analysis abilities are close.  As far as I can tell, they are more
  58. complex (and less speicific) than what is needed.  It may be like
  59. killing an ant with a ICBM.  (So motivating the use may be tough.)
  60.  
  61. Reading a paper on Pablo (The Pablo Performance Analysis Environment -
  62. University of Illinois/NCSA) pointed out some important facts about
  63. motivating the user, and providing extensibility and usefulness.  I am
  64. convinced that tools exist which either already do what we need, or
  65. that our need requires re-thinking.  There is a sensibility to the
  66. Pablo approach which is very appealing.  I have a difficult time
  67. justifying asking algorithm developers to learn to use a tool to write
  68. very simple parallel algorithms for a "simulation tool" (which would
  69. take as long to write for a real machine) only to learn qualitatively
  70. about them (and that only roughly) so that they can eliminate a few
  71. really awful choices (which would probably be intuitively obvious
  72. after getting some experience) and then being forced to code all the
  73. others for the real machine to figure out what's best.  It seems
  74. superfluous right now.
  75.  
  76. Nonetheless, I'm trying to research the issue, and asking for any help
  77. you're willing to offer.
  78.  
  79.   - Are you aware of any tools currently available which will
  80.     perform the simple tasks we require?  
  81.  
  82.   - What about the Pablo/Picasso stuff - do you think that it has
  83.     merit for us? 
  84.  
  85. Philosophically, can you add you $0.02 to the idea of an tool that
  86. does this kind of algorithm analysis?  Talking with Geoffrey Fox, he
  87. seemed to indicate that we were looking at a very large investment of
  88. time and people.  (I also am starting to get the impression that a
  89. project like this has so little "return on investment" compared to
  90. things like Pablo, HeNCE, Express, etc. that it isn't worth it.)
  91. Daniel Reed, at NCSA, says that he took the route that we're
  92. considering for a time, and found it to be fruitless due to growing
  93. disparity between the source and executable (due to compiler issues
  94. and languages like Fortran90), loss of utility due to fast turnaround
  95. of new architectures, etc.
  96.  
  97. Can you offer us any thoughts?
  98.  
  99.  
  100. I will compile all the information that I get and post it.  It will
  101. probably be at the end of this week or start of next.
  102.  
  103.