home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / parallel / 1896 < prev    next >
Encoding:
Text File  |  1992-08-11  |  4.0 KB  |  91 lines
  1. Newsgroups: comp.parallel
  2. Path: sparky!uunet!gatech!hubcap!fpst
  3. From: lycmit@x1sun6.ccl.itri.org.tw (Yin-Chih Lin)
  4. Subject: How to parallelize?
  5. Message-ID: <1992Aug12.122035.6922@hubcap.clemson.edu>
  6. Sender: fpst@hubcap.clemson.edu (Steve Stevenson)
  7. Organization: Clemson University
  8. Date: Wed, 12 Aug 92 16:28:31 CST
  9. Approved: parallel@hubcap.clemson.edu
  10. Lines: 79
  11.  
  12. Greetings:
  13.  
  14. I would like to apologize in advance, if the similar subject had been
  15. discussed before.
  16.  
  17. Currently, I was asked for the possibility of using the idle CPU's times
  18. of workstations to do the jobs for remote computers. The intention is
  19. doing the work concurrently on many computers for obtaining the better
  20. throughput rate and performance than the single one.
  21.  
  22. Somewhere in some textbooks or journals (I can't tell according my
  23. hand-on info) adverted that the parallelism can be achieved in
  24. different levels:
  25.     
  26.     o hardware (ex. VLIW, superscalar, multi-processors)
  27.  
  28.     o O.S. (ex. distributed OS, multi-threaded OS, some
  29.             specific MP-based commerical OS)
  30.  
  31.     o user (ex. Linda, Strand, PVM and other distributed
  32.             data structures or libraries)
  33.  
  34. The *hardware* level seems very obviously. You can explore the
  35. parallelism by concate many processors/instructions to the machine
  36. and get better performance. However, in most cases, you should 
  37. spend additional costage for obtaining this parallelism ($30,0000
  38. for one desktop parallel computer for instance).
  39.  
  40. And the *OS* level might be the parallelism approached from the
  41. software aspect. The operating system kernels provide the 
  42. facilities to parallelize the programs execution in user
  43. transparent way. It can supports the parallelism to you without
  44. extra hardware expansion. But replacing the current O.S. with the
  45. brand new one, however, is not a trivial task for users or 
  46. administors. It is true there are some micro-kernel based O.S. 
  47. (such as Locus, V, Mach, Amoeba, Chorus, Plan 9) emerging from
  48. diverse corners. I won't try to invoke any debate about these OSs,
  49. the only fact I know is that such OSs won't be possible installed
  50. in my units for the near feature. Cause, you could not make sure the
  51. previous codes would still be executed correctly without 
  52. recompilation or recoding.
  53.  
  54. The *user* level parallelism won't rely on the last two levels if 
  55. such facilities are missing. Users only need to rewrite their
  56. programs for integrating the parallelism functions into their codes
  57. then recompile. It will be OK, if you could get the source code of
  58. the programs. But for many programs, you have no way to obtain the
  59. source codes of them for recodeing and recompiling.
  60.  
  61. So I wonder, does there have someone proposed any method to
  62. parallelize the current task without buying the new hardware platforms, 
  63. installing the new O.S. and recoding the programs. It might be a 
  64. addle-header question or a silly one to ask.
  65.  
  66. I believe there is one article in IEEE Tran. of Computers (or Computer)
  67. talked about using the CPU idle time of workstations to execute
  68. the concurrent tasks. But I am not quite sure that such proposition 
  69. won't need to recode the programs.
  70.  
  71. Please don't blame me for ignoring the importance in hardware, O.S. and
  72. user level parallelisms. I am just highly interesting to figure out the
  73. best ways to utilize my workstation clusters. They had once been the 
  74. outstandings in performance (and also cost ;-), but seems decrepit
  75. and would be sent to hell if I couldn't save them.
  76.  
  77. Please forward your opinions and comments to me directly, I appreciate
  78. for any reply message casue it might just save my baby computers.
  79.  
  80. Regards,
  81.  
  82. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  83. Yin-Chih Lin                   Industrial Technology Research Institute (ITRI)
  84. Design Eng.                    Computer & Communication Research Labs.  (CCL)
  85. lycmit@x1sun6.ccl.itri.org.tw  Microcomputer System Department X100
  86. Tel: 886-35-917331             14 Bldg, 195 Chung Hsing Rd., Section 4
  87. Fax: 886-35-917503             Chutung, Hsinchu 31015
  88.                                Taiwan, R.O.C. 
  89. Disclaimer: I only speak for myself. 
  90.  
  91.