Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!europa.asd.contel.com!gatech!hubcap!fpst From: thomasf@ius3.ius.cs.cmu.edu (Thomas Fahringer) Newsgroups: comp.parallel Subject: Intel IPSC/860 performance ? Message-ID: <1991Jun24.122022.19173@hubcap.clemson.edu> Date: 24 Jun 91 09:59:12 GMT Sender: fpst@hubcap.clemson.edu (Steve Stevenson) Organization: Carnegie-Mellon University, CS/RI Lines: 45 Approved: parallel@hubcap.clemson.edu I am parallelizing a couple of applications on the Intel IPSC/860. Now I want to do some performance analysis and prediction. For this reason I am desperately looking for some trustable performance formulas and information about the Intel IPSC/860 for following purposes: 1. the time it takes to transfer a message of n (varying) bytes from a source to a destination node (single and multiple hops). 2. slow down factor of a transfer operation (according to point 1.) due to channel contention. 3. communication primitives behavior for different message sizes and different number of hops to go between source and destination node. I am mainly interested in following communication primitives: - blocking sequential (csend/creceive) - blocking full duplex (csend/creceive) - non-blocking receive, blocking send - blocking receive, non-blocking send - fully non-blocking Which communication primitive should I prefer ? 4. any formula describing the slow down behavior of an array access within a FORTRAN DO-loop induced by cache misses. I am interested in any kind of cache influnce in my computation on the IPSC/860. I am well aware of cache technology, but have no information about the Intel IPSC/860 cache architecture, strategies, etc. 5. Is there anyone out there who has measured performance of all the standard and intrinsic operations on the Intel IPSC/860 ? 6. Is there another bboard containing more information about the Intel IPSC/860 than this one. 7. If someone already collected a couple of IPSC 860 summaries, please forward them to me. I post a summary if anyone requests. Eternal thankful, Tom