home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / parallel / 1804 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  23.9 KB

  1. Path: sparky!uunet!usc!elroy.jpl.nasa.gov!swrinde!gatech!hubcap!fpst
  2. From: lycmit@x1sun6.ccl.itri.org.tw (Yin-Chih Lin)
  3. Newsgroups: comp.parallel
  4. Subject: Could I compete the low-end CM5 with multiple SPARCstations? (Summary)
  5. Message-ID: <1992Jul27.140928.26067@hubcap.clemson.edu>
  6. Date: 24 Jul 92 17:35:40 GMT
  7. Sender: fpst@hubcap.clemson.edu (Steve Stevenson)
  8. Organization: Clemson University
  9. Lines: 583
  10. Approved: parallel@hubcap.clemson.edu
  11.  
  12. Greetings:
  13.  
  14. Pardon me for using the net bandwidth again. I have received many replies
  15. about the subject. So I suppose maybe it will be fine to summarize these
  16. responses and repost again. (I apologize if someone don't think so).
  17.  
  18. Most of notes imply that it is *almost impossible* to challenge the
  19. CM5 with the Sparcstations without extra facilities (vector processors,
  20. high-speed net, good s/w).
  21.  
  22. However, it might be *not true* in my case. I know another team in 
  23. ITRI/CCL has developed the VP processors for SPARCstations (I haven't
  24. inquired the actual spec. and performace of this processor). I also
  25. belileve there are vendors provide the FDDI add-on cards for SBus.
  26. The only hurt is the *software*. It is true that my organization
  27. is impossible to sanctify such project ( especially when there is
  28. one IBM ES-9000/820 machine will be available from National High Speed
  29. Computer Center in my country. I don't know *why* they select IBM).
  30.  
  31. But I also got some directions from the receiving messages. Some of
  32. them (PVM, p4) are positive encourages for me to look for what I like 
  33. with the current facilities.
  34.  
  35. Anyway, I would be glad to hear any comments about the subject in any
  36. time. Please feel free to email me if you have further directions.
  37.  
  38. Thanks go to following people (according the order in my mail box, 
  39. date to July 24, 12:00 - London time plus 8 hours)
  40.     
  41.     Peter Su        psu@cs.duke.edu
  42.     Dirk Grunwald        grunwald@foobar.cs.colorado.edu
  43.     Jon Mellott        jon@alpha.ee.ufl.edu
  44.     Jerry Callen        jcallen@Think.COM
  45.     K. J. Chang        kjchang@hpl.hp.com
  46.     Steve Roy        ssr@ama.caltech.edu
  47.     Scott Townsend        fsset@bach.lerc.nasa.gov
  48.     Rowan Hughes        csrdh@marlin.jcu.edu.au
  49.     Mark Homewood        fred@meiko.com
  50.     Matthias Schumann    schumanm@informatik.tu-muenchen.de
  51.     Mike Davis        davis@ee.udel.edu
  52.     Michael Kolatis        kolatis@cs.utk.edu
  53.     Dave            dave@sep.stanford.edu
  54.     Henrik Klagges        henrik@tazdevil.llnl.gov
  55.     (anonymous)        vu0208@bingsuns.cc.binghamton.edu
  56.     Bob Felderman        feldy@isi.edu
  57.     Ian L. Kaplan        ian@MasPar.COM
  58.     Bill Maniatty        maniattb@cs.rpi.edu
  59.     Keith Bierman        Keith.Bierman@Eng.Sun.COM
  60.     Paul Whiting         Paul.G.Whiting@mel.dit.csiro.au
  61.  
  62. Here are the original message and replies:
  63.  
  64. ------------------------------ ( original ) --------------------------------
  65.  
  66. We have many Sun's SPARCstations (from 1, 1+, IPC, to 2, 670MP and 
  67. SPARCstation 10 in the near future), and the new-version multi-thread
  68. OS (SunOS 5.0) will be installed on these computers.
  69.  
  70. I find that the Think Machines Corp.'s latest MPP machine CM-5 is also
  71. adopted the SPARC processors (22 MIPS per processor) as its nodes.
  72. According the "Parallel Processing" Oct. 1991 issue, the price of 32-node
  73. CM5 model will sell at about $1.4 million.
  74.  
  75. I am curious, if I connect 32 SPARCstation 10 model 30 (33MHz, SuperSPARC
  76. module with 86.1 MIPS - Sun Micro adverted!?) computers (loosely-coupled
  77. MIMD multicomputers?) either by Ethernet, ISDN or FDDI with the multi-
  78. thread OS and might use facilities from Linda-like distributed data
  79. structures. Is it possible for me to obtain the reasonable performance
  80. when compared with the 32-node TMC CM5 (SIMD machine)?
  81.  
  82. I will be highly appreciated for receiving any comments. Please direct
  83. your opinion (or abuse) to me by email. so the news bandwidth won't be
  84. wasted (except this one!).
  85.  
  86. Thanks,
  87.  
  88. P.S. I would also like to know, is there any one config their SPARCstations
  89. to a message-passing MIMD multicomputers rather than just merely LAN-
  90. based networking workstations?
  91.  
  92. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  93. Yin-Chih Lin                            Industrial Technology Research
  94. email: lycmit@x1sun6.ccl.itri.org.tw    Institute  (ITRI)
  95. phone: 886-35-917331
  96. fax:   886-35-917503                    Computer & Comm. Research Labs.(CCL)
  97. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  98.  
  99.  
  100. ------------------------------ ( reply #1 ) --------------------------------
  101.  
  102. From: Peter Su <psu@cs.duke.edu>
  103.  
  104. The answer depends on two things:
  105.  
  106. 1) Would your code be able to take advantage of the CM-5 vector units?
  107. 2) Does your code need to do a lot of communication/synchronization.
  108.  
  109. If you have code that breaks up into big, independent chunks which do
  110. not vectorize easily, and you have libraries to manage workstaion
  111. clusters, then I can't see why the CM-5 would be much better.
  112.  
  113. Oh, the CM-5 probably has more usable memory per node, since data
  114. processing nodes don't run the full OS.
  115.  
  116. Pete
  117.  
  118. ------------------------------ ( reply #2 ) --------------------------------
  119.  
  120. From: Dirk Grunwald <grunwald@cs.colorado.edu> 
  121.  
  122. The CM-5 also has 200Mf vector processors and a very fast network.
  123. most importantly, it has good software.
  124.  
  125. ------------------------------ ( reply #3 ) --------------------------------
  126.  
  127. From: Jon Mellott <jon@alpha.ee.ufl.edu>
  128.  
  129. It depends a lot on the type of tasks that you are doing. If your tasks 
  130. are characterized by lots of communication between processes/processors, 
  131. then the CM-5 will probably eat you alive. Also, the CM-5 does have 
  132. the option of a vector processor for each processor module, so you 
  133. could potentially be chewed up there also. 
  134.  
  135. BTW, if your intent is to do something like this, then you might 
  136. consider going to something like the SS10 model 54 (four processors). 
  137. You'd be money ahead on a per processor basis since you wouldn't have 
  138. to buy as many pizza boxes per processor. Also, if your code is 
  139. amenable to multi-threading then you might be able to derive a big 
  140. benefit from running on a multiprocessor machine, especially from an 
  141. inter-thread communications standpoint. 
  142.  
  143. Lemme see, the SS10 model 54 is listing at something like $50K, so 
  144. for a million bucks you could get twenty of them. That'd give you 
  145. eighty processors. You could spend the savings on FDDI interfaces 
  146. so you don't get butchered by ethernet latencies. 
  147.  
  148. BTW, this sort of thing has been described before in the literature. 
  149. I don't recall where, but it has been done before. 
  150.  
  151. Good luck,
  152. Jon Mellott
  153. High Speed Digital Architecture Laboratory
  154. (jon@alpha.ee.ufl.edu)
  155.  
  156. ------------------------------ ( reply #4 ) --------------------------------
  157.  
  158. From: Jerry Callen <jcallen@Think.COM>
  159.  
  160. [Claimer: I work for Thinking Machines.]
  161.  
  162. There is a lot more to a CM-5 than SPARCs and memory.
  163.  
  164. Specifically, there are two high-bandwidth, low-latency networks. The
  165. "control network" can perform a number of combining operations (max,
  166. add, or, xor), broadcasting and synchronization functions. The "data
  167. network" allows point-to-point communications between multiple nodes
  168. SIMULTANEOUSLY at very high bandwidths (>5MB/sec/node). This gives a
  169. 32 node machine a (very conservatively rated) aggregate bandwidth of
  170. 160MB/sec. You just cannot get this kind of bandwidth out of Ethernet
  171. or even FDDI. Also, the network interface is mapped into user memory
  172. space, so you don't have to go through operating system layers to get
  173. at it.
  174.  
  175. There are also 4 vector units on each node; each vector unit has a
  176. dedicated bank of memory, yielding very high memory bandwidth. Each
  177. vector unit can do 32MFLOPS (peak, but I have seen codes get >75% of
  178. this).
  179.  
  180. Also, a point of clarification: the CM-5 is NOT a "SIMD machine." While
  181. the networks provide excellent support for a data-parallel programming
  182. model, TMC supports a message-passing programming model as well.
  183.  
  184. Call TMC at (617) 234-1000 and ask for a CM-5 Technical Summary if you
  185. would like more information.
  186.  
  187. -- Jerry Callen
  188.    jcallen@world.std.com           (preferred)
  189.    jcallen@think.com               (OK, too)
  190.    {uunet,harvard}!think!jcallen   (if you must)
  191.  
  192. ------------------------------ ( reply #5 ) -------------------------------- 
  193.  
  194. From: K. J. Chang <kjchang@hplabsz.hpl.hp.com> 
  195.  
  196. Of course! That's why there are at least 20 new RISC-based workstations 
  197. being designed here at Silicon Valley. Mainframe or Supercomputer vendors
  198. do not release their SPCEfp92 or SPECint92 because their products are
  199. not cost-effective.
  200.  
  201. You may want to read Chap. 2 of "Computer Architecture A Quantitative
  202. Approach" (John Hennessy and David Patterson), especially Figure 2.25
  203. which tells you that those expensive computers' MFLOPS are in the range
  204. of 8.3 to 24.4 only.
  205.  
  206. -- 
  207. K J Chang, Hewlett-Packard ICBD R & D,                      (())_-_(())
  208. Palo Alto, CA 94304                                          | (* *) | 
  209. Internet: kjchang@hpl.hp.com           a UCLA Bruin  -->    {  \_@_/  }
  210. voice mail: (415)857-4604                                     `-----' 
  211.  
  212. ------------------------------ ( reply #6 ) -------------------------------- 
  213.  
  214. From: Steve Roy <ssr@ama.caltech.edu>
  215.  
  216. There are three main differences that insure that a network of
  217. workstations will not compete with the CM5.
  218.  
  219. The first difference is a hardware one: The Sparc in the CM5 is really
  220. just a controller/scheduler for custom vector/memory processors.  Each
  221. sparc controls 4 of these processors.  These vector boards are much
  222. much faster than the sparc for number crunching, the main point of
  223. this sort of machine.  The fact that it has Sparcs in it is sort of
  224. irrelevant for number crunching considerations.
  225.  
  226. The second difference is the speed of the communications: the CM5 has
  227. a very fast and sophisticated network that allows arbitrary
  228. permutation communication to proceed at not less than 5MByte/sec per
  229. processor.  This is the high bandwidth network; there is also a lower
  230. bandwidth but also lower latency network that is used primarily for
  231. fast syncronizations between processors.  There is a third network for
  232. diagnostics.  The networks are redundant so the machine can continue
  233. to work given any single point failure, an important consideration for
  234. a massively parallel system.
  235.  
  236. The third difference is the integrated and powerful software that
  237. allows easy parallel coding and debugging.  The debugger is X-based
  238. and allows you to click on (for example) an array name and display its
  239. contents either as numbers or as a contour plot.  The first compiler
  240. is an F90 variant, there will later be ports of C* and presumably
  241. *Lisp. 
  242.  
  243. It was a good question tho.  I hope you post a summary to the net.
  244.  
  245. Steve Roy.-- 
  246. ----------------------------------------------------------------------
  247. Steve Roy                     |  Life.  Don't talk to me about life.
  248. ssr@ama.caltech.edu           |
  249.                               |
  250.  
  251. ------------------------------ ( reply #7) -------------------------------- 
  252.  
  253. From: Scott Townsend <fsset@bach.lerc.nasa.gov>
  254.  
  255. While the individual processors will be comparable to those in the CM5,
  256. as a group your clustered processors will approximate the CM5 only if your
  257. parallel application does almost zero communications.
  258.  
  259. We've run some experiments here with a cluster of RS6000's.  On applications
  260. which require very little communication relative to the computation rate,
  261. things run very well.  As soon as you get into more typical parallel
  262. applications, things slow down REAL fast!
  263.  
  264. The main reason for this is latency.  Local networks are not designed for
  265. very low latency.  Unless the interconnect in a parallel processor has _very_
  266. low latency compared to CPU speed, you spend all your time waiting for
  267. messages instead of computing.
  268.  
  269.  
  270. -- 
  271. Scott Townsend,  Sverdrup Technology Inc.  NASA Lewis Research Center Group
  272. fsset@bach.lerc.nasa.gov
  273.  
  274. ------------------------------ ( reply #8) --------------------------------
  275.  
  276. From: Rowan Hughes <csrdh@marlin.jcu.edu.au>
  277.  
  278. You'd need to connect them together with at least FDDI. The bandwidth between
  279. nodes is the biggest problem with MPP machines. 1000Mb/s would be better.
  280. Also, you probably won't be able to use more nodes than 16, since the
  281. search/latency overheads become prohibitive on a single commnication rail, ie
  282. you've got no secondary search engine.
  283.  
  284. At the moment the CM-5 is just a bunch of Sparc stations in one box, the vector
  285. cpu's haven't been fabricated yet (and probably never will be).  The $1.4M is 
  286. really just for a bit of software.
  287.  
  288. -- 
  289. Rowan Hughes                                James Cook University
  290. Marine Modelling Unit                       Townsville, Australia.
  291. Dept. Civil and Systems Engineering         csrdh@marlin.jcu.edu.au
  292.  
  293. ------------------------------ ( reply #9) --------------------------------
  294.  
  295. From: Mark Homewood <fred@meiko.co.uk> 
  296.  
  297. Besides designing FPU's for SPARC Meiko manufactuers machines based around
  298. something like what you have described. We buy commodity boards or workatation
  299. components and produce (hopefully) cost effective parallel supercomputers.
  300. We do find it necessary to add some extra communication bandwidth and
  301. reduced latency. Clearly a 32node TMC is out to lunch, we do a similar size
  302. machine for a fraction of the price. The major difference is that ours can be
  303. used as a network of Sun as well, and at the same time.
  304.  
  305. There is some public domain software which lets you use your machines as a
  306. parallel machine. This is called PVM (Parallel Virtual Machine), try an
  307. anonymous ftp to <research.att.com> in dir <netlib/pvm>. There is a Readme
  308. and index. You can compile and configure for your network.
  309.  
  310. Though as one of your repliers states, latency is the thing. This is what 
  311. Meiko (and TMC, though over-priced) are selling.
  312.  
  313. Fred
  314.  
  315. Meiko Limited
  316.  
  317. fred@meiko.com 
  318.  
  319. ------------------------------ ( reply #10) -------------------------------
  320.  
  321. From: Matthias Schumann <schumanm@informatik.tu-muenchen.de>
  322.  
  323. Hi,
  324.  
  325. here at the Technical University Munich an Environtment for parallel
  326. Programming called MMK was developed, that runs on Intel iPSC 2 / 860 
  327. MIMD-Supercomputers. 
  328. There is antother version called MMKx, which offers the same functions
  329. (task creation, deletion /  communication / semaphores, synchronization /
  330. .....) on a Network of Sun-Workstations connected over an Ethernet.
  331.  
  332. The question about the CM5 is application depended, i would say. Code
  333. that is written especially for SIMD machines will run faster on the 
  334. CM. If you got general purpose code the perormance of the sun network
  335. will increase but if it could reach the CMs performance i got no idea,
  336. even though i got no information about the inter Processor communication
  337. network in the CM5.
  338.  
  339. Ciao 
  340.          Matt
  341.  
  342. --
  343. | Matthias Schumann   Department of Computer Science/SAB   TU Muenchen |
  344. | schumanm@informatik.tu-muenchen.de                       Arcisstr.21 |
  345. | Phone: +49 89 2105 2036                              8000 Muenchen 2 |
  346.  
  347. ------------------------------ ( reply #11) -------------------------------
  348.  
  349. From: Mike Davis <davis@ee.udel.edu>
  350.  
  351. I would be interested in any responses you get on this subject.  I'am involved
  352. in a project looking into running distributed simulations on a group of FDDI
  353. connected SPARCstation10's running Linda.  Since the closest thing we have
  354. to compare to is an older 16 processor Sequent, I can't help with your CM5
  355. questions..
  356.  
  357. thanks
  358. mike
  359.  
  360. davis@ee.udel.edu
  361.  
  362. ------------------------------ ( reply #12) -------------------------------
  363.  
  364. From: Michael Kolatis <kolatis@cs.utk.edu>
  365.  
  366. Let's see, from what I know so far, one node of a TMC CM-5
  367. will have a SPARC chip that performs about 5 Mflops.  Thus, 
  368. with 32 nodes, you would expect a peak of 160 Mflops.
  369.  
  370. Now, a SPARCstation 10 with 4 processors is supposed to perform
  371. at 19.7 Mflops per processor (i.e. almost 80 Mflops).  Thus,
  372. 32 * 80 = 2560 Mflops = 2.56 Gflops.
  373.  
  374. However, each node of a CM-5 will eventually include 4 vector
  375. processors (TMC calls them "floating point accelerators") which
  376. will increase the node power to 128 Mflops per node (which makes
  377. a 32 node CM-5 capable of 4 Gflops).
  378.  
  379. Thus, theoretically, with the communication speed losses involved
  380. with the SPARC 10's & the lack of a parallel programming language for
  381. them the SPARC's would lose (also, note that if a SPARC 10 does have
  382. 4 processors, your connection would have 128 processors--not 32).
  383.  
  384. However, hooking the SPARC 10's together using PVM(Parallel Virtual
  385. Machine) as parallel software would be very interesting...
  386. and certainly makes the efforts toward massively parallel
  387. computing very viable.
  388.  
  389. Michael Kolatis
  390. UTenn
  391. Joint Institute for Computational Science
  392.  
  393. ------------------------------ ( reply #13) -------------------------------
  394.  
  395. From: Dave <dave@sep.stanford.edu>
  396.  
  397. Unfortunately not, each CM-5 node also has 4 custom vector units running
  398. at 120MFlop peak each. That, and the high bandwidth network are what you are
  399. really paying for with a CM-5.
  400.  
  401. ------------------------------ ( reply #14) -------------------------------
  402.  
  403. From: Henrik Klagges <henrik@tazdevil.llnl.gov>
  404.  
  405. I think it is a good idea. At LLNL we have a cluster of RS6000, connected
  406. via a very fast network, with good results.
  407.  
  408. --
  409.  
  410. Cheers, Henrik
  411. MPCI at LLNL
  412. IBM Research
  413.  
  414. ------------------------------ ( reply #15) -------------------------------
  415.  
  416. From: (anonymous) <vu0208@bingsuns.cc.binghamton.edu>
  417.  
  418. If you want to do what you have said in your post, you might create a
  419. loosely-coupled loosely-performed-MIMD!! Why? becaz the CM-5 has 2
  420. extra things that you wont have: (1) A fast communication network
  421. rather than yours FDDI/Ethernet/ISDN etc.. (2) Their node is haveing a
  422. dedicated a 22-Mips RISC microprocessor with four vector pipes
  423. providing a total of 128 MFlops peak speed!! (3) They are capable of
  424. playing dual role of the machine at the same time SIM and MIMD.
  425.  
  426. So I guess by just connecting 32 Sparcstations you wont hit the 129
  427. MFlops performance, however it may be at least 1/4 of 16-node CM-5.
  428.  
  429. Let's see whta you get after you are done with your peoposed project.
  430.  
  431. Keep me posted, i will appreciate.
  432.  
  433. Thanks
  434.  
  435. ------------------------------ ( reply #16) -------------------------------
  436.  
  437. From: Bob Felderman <feldy@isi.edu>
  438.  
  439. I suspect not. If you could, then TMC would quickly go out of business.
  440. My guess is that their interconnection network is MUCH better than 
  441. any of your choices.
  442. For one thing, your choices were mostly shared-medium channels. If your
  443. taks requires significant communication, you'll get killed by the
  444. Ethernet or FDDI etc. If your taks are mostly independent, you'll
  445. probably do just fine.
  446.  
  447.  
  448. Bob Felderman
  449. USC/Information Sciences Institute
  450. 4676 Admiralty Way
  451. Marina del Rey, CA 90292-6695
  452. (310) 822-1511 x222
  453. (310) 823-6714 (fax)
  454.  
  455. feldy@isi.edu
  456.  
  457. ------------------------------ ( reply #17) -------------------------------
  458.  
  459. From: Ian L. Kaplan <ian@MasPar.COM>
  460.  
  461.   Whether you can get comparable performance out of an network of 32
  462. Spark Stations that can be obtained form a 32 processor CM-5 depends
  463. on the application.  If you have an application with little or no
  464. communication (some Monte Carlo simulations fall into this catagory)
  465. then the answer is yes.  The more interprocessor communication the
  466. more the CM-5 will win.  They have put a lot of effort into designing
  467. their communication network and it is much faster than anything you
  468. are likely to find connecting workstations.  Another issue is software
  469. overhead in handling communication.  I don't know what TMC has done in
  470. this area (we are one of their competitors, so they don't tell us
  471. these things), but I imagine that they have worked to reduce this
  472. overhead.  This is not as important in SMP Solaris, so it is probably
  473. not as tightly tuned.
  474.  
  475.   Of course what you should really do is buy a MasPar machine, which
  476. will give you more processing power per dollar than either TMC or Sun
  477. can provide.
  478.  
  479.                           Ian Kaplan
  480.               ian@maspar.com
  481.  
  482. ------------------------------ ( reply #18) -------------------------------
  483.  
  484. From: Bill Maniatty <maniattb@cs.rpi.edu>
  485.  
  486. I'd be skeptical of getting the same level of performance.  I think the
  487. expense of the networked connections (latency in particular), would force
  488. you to use a larger granularity of task decomposition.  I haven't played with
  489. a CM-5 so I would not really know for sure, but that is my gut reaction.
  490. You might also get a different resource contention pattern because of the
  491. different Operating System/Compiler technology.  I don't think they are
  492. really equivalent, each is appropriate for a different sort of task.
  493.  
  494. Bill
  495. -- 
  496. |
  497. |    maniattb@cs.rpi.edu - in real life Bill Maniatty
  498. |
  499.  
  500. ------------------------------ ( reply #19) -------------------------------
  501.  
  502. From: Keith Bierman <Keith.Bierman@Eng.Sun.COM>
  503.  
  504. the CM-5 has much faster interprocessor communication (fast custom hw,
  505. special sw) you won't come close to their performance for most codes.
  506.  
  507. Many people use networks of workstations for distributed processing.
  508. They use Express, Strand, PVM and a bevy of research efforts. Wander
  509. through comp.parallel, or a local university library (if they have a
  510. good collection of conference papers and technical reports).
  511.  
  512. ----------------------------- ( reply #20) -------------------------------
  513.  
  514. From: Paul Whiting <pgw@mel.dit.csiro.au>
  515.  
  516. G'day,
  517.  
  518. yes this is possible to do using the macros from Argonne National Lab in the US.
  519.  
  520. I will forward you another piece of mail about them and how to obtain them.
  521.  
  522. regards,
  523.  
  524. ---------------------------------------------------------------------
  525. Paul Whiting                | CSIRO - DIT
  526. Computer Scientist            | 723 Swanston Street
  527. High Performance Computing Program      | Carlton 3053, Australia
  528. ---------------------------------------------------------------------
  529. E-mail: pgw@mel.dit.csiro.au          Phone: + 61 3 282 2666    
  530.  
  531. There's no problem a good surf can't fix.
  532. ---------------------------------------------------------------------
  533.  
  534. (****************************** p4 info **********************************)
  535.  
  536.                       p4
  537.  
  538.  
  539. p4 is a library of macros and subroutines developed at Argonne National
  540. Laboratory for programming a variety of parallel machines.  Its predecessor
  541. was the m4-based "Argonne macros" system described in the Holt, Rinehart, and
  542. Winston book "Portable Programs for Parallel Processors, by Lusk, Overbeek, et
  543. al., from which p4 takes its name.  The current p4 system maintains the same
  544. basic computational models described there (monitors for the shared-memory
  545. model, message-passing for the distributed-memory model, and support for
  546. combining the two models) while significantly increasing ease and flexibility
  547. of use.
  548.  
  549. The current release is version 0.2.  New features added since version 0.1
  550. include: 
  551.  
  552.   + xdr for communication in a heterogeneous network
  553.  
  554.   + asynchronous communication of large messages
  555.  
  556.   + global operations (broadcast, global sum, max, etc.)
  557.   
  558.   + both master-slave and SPMD models for message-passing programs
  559.  
  560.   + an improved and simplified Fortran interface
  561.  
  562.   + improved error handling
  563.  
  564.   + an optional secure server
  565.  
  566.   + ports to more machines
  567.  
  568. p4 is intended to be portable, simple to install and use, and efficient.  It
  569. can be used to program networks of workstations, advanced parallel
  570. supercomputers like the Intel Touchstone Delta and the Alliant Campus
  571. HiPPI-based system, and single shared-memory multiprocessors.  It has
  572. currently been installed on the following list of machines: Sequent Symmetry,
  573. Encore Multimax, Alliant FX/8, FX/800, and FX/2800, Cray X/MP, Sun, NeXT, DEC,
  574. Silicon Graphics, and IBM RS6000 workstations, Stardent Titan, BBN GP-1000 and
  575. TC-2000, Intel IPSC/860, Intel Touchstone Delta, and Alliant Campus.  It will
  576. soon be ported to the CM-5 and to the Intel Paragon.  It is not difficult to
  577. port to new systems.
  578.  
  579. Work in progress also includes use of monitors in Fortran and shared mem~~~~~~~~ory
  580. among multiple processes on multiprocessor workstations.  A useful companion
  581. system is the upshot logging and X-based trace examination facility.
  582.  
  583. You can obtain the complete distribution of p4 by anonymous ftp from
  584. info.mcs.anl.gov.  Take the file p4.tar.Z from the directory pub/p4.  The
  585. distribution contains all source code, installation instructions, a reference
  586. manual, and a collection of examples in both C and Fortran.  The files
  587. alog.tar.Z and upshot.tar.Z contain logging and display facilities that can be
  588. used with both p4 and other systems.
  589.  
  590. To ask questions about p4, report bugs, contribute examples, etc., send mail
  591. to p4@mcs.anl.gov.
  592.  
  593.                                                    Rusty Lusk
  594.                                                    lusk@mcs.anl.gov
  595.