home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / sci / math / numanal / 2567 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  5.3 KB

  1. Xref: sparky sci.math.num-analysis:2567 comp.lang.fortran:3230
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!mips!news.cs.indiana.edu!umn.edu!lynx!aquarius.unm.edu!john
  3. From: john@aquarius.unm.edu (John Prentice)
  4. Newsgroups: sci.math.num-analysis,comp.lang.fortran
  5. Subject: Re: The importance of high-performance computing
  6. Message-ID: <wvcndja@lynx.unm.edu>
  7. Date: 27 Aug 92 16:34:14 GMT
  8. References: <l9p02vINNorv@almaak.usc.edu>
  9. Organization: Dept. of Physics & Astro, University of New Mexico, Albuquerque
  10. Lines: 86
  11.  
  12. In article <l9p02vINNorv@almaak.usc.edu> ajayshah@almaak.usc.edu (Ajay Shah) writes:
  13. >In the Great Lwars, one point which commonly comes up is that fortran
  14. >is conceptually lowbrow and hence well-suited for the generation of
  15. >good code, esp. to exploit various parallel architectures.
  16. >
  17. >  [some stuff deleted]
  18. >
  19. >Parallel hardware is obviously a way to get revolutionary gains in
  20. >compute power, but Bill Joy's law suggests that single CPUs will give
  21. >tremendous gains without paying any software irritations (they
  22. >certainly have done great in the last five years).
  23. >
  24. >If this is indeed the case; that most people use workstation-type
  25. >computers, then the argument changes quite a bit.  There may be room
  26. >for a language with simple semantics like fortran, but only for those
  27. >5% of users who want to use parallel hardware.  I suspect most
  28. >scientific computation out there does not know or care about parallel
  29. >hardware.
  30. >
  31.  
  32. Let me make two comments.  One is overall agreement with your statement
  33. as regards the likely users of massively parallel supercomputers.
  34. The general comment about supercomputing is that 10% of the computing
  35. community uses 90% of the supercomputing power.  I think that is probably
  36. a correct statement, it certainly is within the DoD and DoE laboratories
  37. I have been affiliated with over the years.  The projections for the use
  38. of high performance massively parallel supercomputers preserve that 
  39. user mixture, meaning that only a small minority of people doing
  40. scientific computing will use highly parallel computers.  The outlook
  41. for small parallelism is quite different however.  Consider the
  42. Sparc 10, a workstation by any measure.  It has 4 CPU's in it and is
  43. meant to exploit parallelism on a small scale.  Just as there has not
  44. been a single CPU supercomputer built in years, I stronly suspect that
  45. there will be fewer and fewer single processor workstations in the future.
  46. It is less clear whether the multiprocessors in your workstation will be
  47. something only the operating system will know about or whether they will
  48. be available to the user.  An side comment is that most workstations sit
  49. idle most of the time, which has generated considerable interest in
  50. distributing parallel computing where you use network linked workstations
  51. as the computing nodes.  
  52.  
  53. My second comment takes issue with your characterization of Fortran as
  54. the language of choice for parallel computing.  Let us assume you meant
  55. Fortran 90, since there is nothing about Fortran 77 that would make it
  56. particularly good for this purpose (the same being true of C and other
  57. procedural languages out there).  Fortran 90 does have array syntax,
  58. which makes data parallelism easier to perform.  However, the trend is
  59. away from data parallelism and toward control parallelism (though many
  60. would argue this.  However, even the guru's of data parallelism, 
  61. Thinking Machines Corporation, are now producing a system which is
  62. at least partly MIMD).  I guess I don't see anything about Fortran 90
  63. which makes control parallelism any easier.  I would argue in fact
  64. that none of the current generation of procedural languages address
  65. parallelism at all well.  Some of the OOPS concepts make it easier,
  66. but only in allowing one to hide the machine architecture from the user.
  67. Certainly they do little to enhance efficiency and the usual reason you
  68. run on a supercomputer is because you are sweating bricks about
  69. speed (otherwise, why not use a workstation).  Functional languages
  70. actually strike me as the ones currently best suited to expressing
  71. parallelism (data or control).  
  72.  
  73. Having said all that, there is hardly a bit of difference in the
  74. functionality of Fortran 90 and any of the other procedural languages.
  75. Fortran 90 has structures, pointers, recursion, all the things that
  76. people have been trashing on it for not having all these years.  So
  77. I am not sure I see where you are going with your comment, since there
  78. is little about it that I would call "conceptually lowbrow".  That
  79. it is not an OOPS language or a functional language hardly makes it
  80. conceptually lowbrow.  In addition, each of these concepts, OOPS,
  81. procedural, and functional, have their pros and cons.  If you want
  82. to compete in the 90's world of computing, you are going to have to
  83. use a variety of languages, exploting the strength of each when the
  84. problem demands it.
  85.  
  86. I would make a final comment about Fortran also.  There are now at
  87. least two variants of Fortran 90 being developed which are attempting
  88. to address the issue of parallelism.  One is Fortran D by Ken Kennedy
  89. and company, the other is High Performance Fortran.  I don't think I
  90. would call either of these "lowbrow" languages.
  91.  
  92. John
  93. -- 
  94. Dr. John K. Prentice                      
  95. Partner, Quetzal Computational Associates    
  96. 3200 Carlisle N.E., Albuquerque, NM   87110-1664; 505-889-4543
  97. john@aquarius.unm.edu -or- jkprent@cs.sandia.gov -or- prentice@rufous.cs.unm.edu
  98.