home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / parallel / 1820 < prev    next >
Encoding:
Text File  |  1992-07-29  |  8.6 KB  |  198 lines

  1. Newsgroups: comp.parallel
  2. Path: sparky!uunet!gatech!hubcap!fpst
  3. From: ssp@csl36h.csl.ncsu.edu (Santosh Pande)
  4. Subject: Summary of responses - IPC on iPSC/860
  5. Message-ID: <1992Jul29.115310.7491@hubcap.clemson.edu>
  6. Sender: fpst@hubcap.clemson.edu (Steve Stevenson)
  7. Organization: Clemson University
  8. Date: Wed, 29 Jul 92 0:23:06 EDT
  9. Approved: parallel@hubcap.clemson.edu
  10. Lines: 186
  11.  
  12.     Hello Everybody,
  13.  
  14.     Here's a summary of responses I received about my posting : `IPC on
  15. iPSC/860'. Thank you all for your input. 
  16.     At the end of this posting you will find the description of an
  17. environment called `TOPSYS' which allows management of tasks and other 
  18. light-weight stuff, that may be useful. 
  19.  
  20.     -Santosh
  21.     
  22.      ----------------------- R E S P O N S E S----------------------------
  23. --->From: bhatt@src.honeywell.com (Devesh Bhatt)
  24.  
  25. NX/2 does not support multiple processes in a processor, so the question of IPC
  26. does not arise.  It is almost impossible to come up with a fix for this since
  27. the process managment support just isn't there in the kernel.
  28.  
  29. One thing you can do is to use isends(), irecvs() and then use an ualarm()
  30. handler to get the work done, using msgdone() calls.  This way you do not pay
  31. the handling penalty on every message.  However, I am not sure whether NX/2
  32. provides ualarm().  They do provide alarm(), but its units are in seconds.
  33.  
  34. --->From: prp@ssd.intel.com (Paul Pierce)
  35.  
  36. In most multicomputer applications it is relatively easy to synchronize message
  37. passing with computation, since the messages are related to the computation. It
  38. is not always so easy for a compiled approach, especially for unstructured
  39. problems, since it is apparently quite difficult for a compiler to generate
  40. both the send and receive sides of every message efficiently. This has led to
  41. suggestions that a get/put message passing paradigm (rather than send/receive)
  42. be supplied for use by compilers.
  43.  
  44. [ Yes, I completely agree with this. get() and put() paradigm will simplify a
  45. lot of cross-reference resolution to be done by the compiler and the RTS.
  46. It also avoids the compiled code to be littered with masktraps() to block 
  47. incoming message's side-effects on current thread -Santosh]
  48.  
  49. --->From: Steve Aliff (swaliff@afterlife.ncsc.mil)
  50.  
  51. Just a word of warning; the hrecv() mechanisms are not very robust.
  52. For example, you cannot reliably perform any system calls inside of
  53. an hrecv() handler, e.g. "printf." Also, the asynchronous message
  54. passing calls such as irecv() tend to break if they're invoked while
  55. there is lots of CFS I/O going on.
  56.  
  57. I discovered both of these "features" when I first attempted to use
  58. hrecv() and then attempted to use irecv() as a work-around to the
  59. hrecv() bug. So I guess the bottom line to all this is that if
  60. things don't work as you expect, it may be a system bug vice your
  61. bug.
  62.  
  63. ---->From: Scott Kohn (skohn@cs.UCSD.EDU)
  64.  
  65. You might find the following useful.  The TOPSYS people have implemented a light
  66. thread library for the iPSC -- there may be others, but I haven't heard of them.
  67. This is a tricky thing, since you have to hack the NX/2 kernel.
  68.  
  69. ---->From: Steve Roy (ssr@ama.caltech.edu)
  70.  
  71.  To the best of my knowledge the only calls supported in NX are things
  72. like hsend/hrecv, csend/crecv, and isend/irecv.  NX does NOT support
  73. multiple processes per compute node.  
  74. You might want to look into the Paragon Mach kernel stuff they're
  75. working on.
  76.  
  77. ---------------------------E N D  OF S U M M A R Y----------------------
  78.  
  79. ------------------------------T O P S Y S------------------------------
  80. This is to announce the availability of a new version of the TOPSYS
  81. parallel programming environment developed at the Munich University of 
  82. Technology (a.k.a. Technische Universitaet Muenchen).
  83.  
  84. What is TOPSYS?
  85. ---------------
  86. TOPSYS (Tools for Parallel Systems) is a tool environment which is aimed at
  87. providing support for all the phases of parallel program development. 
  88. The design and implementation of TOPSYS was started in 1987. The
  89. latest version consists of the following components:
  90.  
  91. * A programming library called MMK (Multiprocessor Multitasking Kernel).
  92.   This library provides lightweight processes (tasks) as well as 
  93.   communication objects (mailboxes) and synchronization objects (semaphores).
  94.   Communication and synchronization between tasks is location transparent.
  95.   Tasks, mailboxes and semaphores can be created statically (at program
  96.   start) or dynamically during runtime.
  97.  
  98. * A parallel debugger called DETOP (Debugging Tool for Parallel Systems).
  99.   DETOP is a true parallel debugger that provides a global view of the
  100.   system. In addition to the functionality found in sequential debuggers,
  101.   DETOP provides unique features such as distributed breakpoints and
  102.   the monitoring of communication and synchronization events.
  103.  
  104. * A performance analysis tool called PATOP (Performance Analysis Tool for
  105.   Parallel Systems). This tool supports performance measurements at different
  106.   levels of abstraction. The first level examines the system's performance
  107.   as a whole. The next level supports measurements for the different processing
  108.   nodes which form the distributed system (e.g. processor idle time). The 
  109.   finest level of granularity makes it possible to examine the performance
  110.   in terms of objects of the programming model (e.g. cpu-time used by tasks).
  111.  
  112. * A visualization tool (VISTOP) which provides a graphical animation
  113.   of task interaction (communication and synchronization) and can be used
  114.   to find bugs or bottlenecks in the communication and synchronization
  115.   structure (e.g. deadlocks).
  116.  
  117. * A software package called ALLOCCUBE which is useful for managing the
  118.   space-sharing multiuser access to distributed memory multiprocessors
  119.   in a network based environment.
  120.  
  121. All the tools are interactive and have a graphical user interface based on 
  122. X-Windows and the Athena Widget set.
  123.  
  124. What platforms does TOPSYS run on?
  125. ----------------------------------
  126.  
  127. The first implementation was done on hypercube multiprocessors (iPSC/2,
  128. iPSC/860). We now have an implementation on networks of SPARCstations.
  129. The programming library will also be available for i860 based UNIX machines
  130. (e.g. Alliant FX/2800). At the moment, TOPSYS is available for the following
  131. configurations:
  132.  
  133. * iPSC/2 with Sun SPARC as "remote hosts"
  134. * iPSC/860 with Sun SPARC as "remote hosts"
  135. * SPARC (networks) under SunOS 4.1
  136.  
  137. How can I get additional information?
  138. -------------------------------------
  139.  
  140. Postscript versions of papers and manuals describing the TOPSYS environment
  141. can be found on the ftp server:
  142.  
  143.   topsys.informatik.tu-muenchen.de (131.159.0.156)
  144.  
  145. Log in as "anonymous" and look in the directory "topsys/public/papers". You'll
  146. find a README describing the contents and compressed postscript versions
  147. of the papers.
  148.  
  149. You'll also find a demo-version of the tools compiled for a Sun SPARC.
  150. (file "topsys/public/misc/DEMO.tar.Z) These demos can be used to get a 
  151. quick overview of the functionality of TOPSYS.
  152.  
  153. The installation guides for TOPSYS can also be found in the public-
  154. directory. Check these documents if you have any doubts as to whether
  155. TOPSYS can be used with your hardware configuration.
  156.  
  157. How do I get TOPSYS?
  158. --------------------
  159. In order to get binaries and/or sources for TOPSYS, you must fill out an
  160. order form and a license agreement. A copy of these documents can be found
  161. on our ftp-server (topsys.informatik.tu-muenchen.de (131.159.0.156), 
  162. file 'topsys/public/license.txt' or 'topsys/public/license.ps.Z'). Send a signed 
  163. copy of the license agreement to
  164.  
  165.                    Dr. Thomas Bemmerl
  166.                    Lehrstuhl fuer Rechnertechnik und Rechnerorganisation
  167.                    (Prof. Dr. A. Bode)
  168.                    Technische Universitaet Muenchen
  169.                    Arcisstrasse 21, Postfach 202420
  170.                    8000 Muenchen 2
  171.                    GERMANY
  172.  
  173. In exchange, we'll send you the password which will enable you to download
  174. the software from our ftp server. After receiving the password:
  175.  
  176.    - ftp to topsys.informatik.tu-muenchen.de (131.159.0.156).
  177.    - Log in as anonymous
  178.    - type 'site group topsys'
  179.    - type 'site gpass <password>'
  180.    - cd topsys/nonpublic
  181.  
  182. You'll find a README file describing the contents of the directory.
  183.  
  184. (Note: In order to download the TOPSYS/X and MMK/X software from our ftp-server
  185. you need a version of 'ftp' that understands the 'site' commands. If you
  186. do not have this version, you can retrieve it from our ftp-server:
  187.  
  188.   - ftp to topsys.informatik.tu-muenchen.de (131.159.0.156).
  189.   - Log in as anonymous
  190.   - cd topsys/public/misc/ftp
  191.   - You'll find a README, the ftp-binary for the SPARC and the sources
  192.     for the new ftp-version)
  193.  
  194. If you have any further questions, please send e-mail to:
  195.  
  196. bemmerl@informatik.tu-muenchen.de (Dr. Thomas Bemmerl)
  197.  
  198.