Xref: utzoo comp.arch:21712 comp.benchmarks:490 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!modus!gear!cadlab!martelli From: martelli@cadlab.sublink.ORG (Alex Martelli) Newsgroups: comp.arch,comp.benchmarks Subject: (Fortran) I/O on Hp9000/700 (Was: Snake) Message-ID: <730@cadlab.sublink.ORG> Date: 27 Mar 91 12:25:31 GMT References: <69465@brunix.UUCP> <32580004@hpcuhe.cup.hp.com> <26MAR91.07524930@uc780.umd.edu> Organization: CAD.LAB, Bologna, Italia Lines: 49 (Regarding the new HP/9000/700, it was asked on comp.arch...): :How's I/O on this thing? Would use as a fileserver be a shameful :waste? I have a 'toy' program that exactly duplicates the (Fortran) I/O operations during the 'save' operation for a 3-D model in CAD.LAB's "GBG ShapeMaker" application program; it is just a few hundreds LOCs, including the parsing of a file subsuming the structure (...NOT the contents!-) of the 3-D model itself; making it available is a bit more difficult than this would suggest, since it does use bits and pieces from our in-house subroutine and macro libraries, but I believe we could work out some sort of non-disclosure/fair-use agreement to put the program in the hands of somebody wanting to use it for such purposes as enhancing subsystem architecture and Fortran runtime libraries, as opposed to competitors wishing ill to CAD.LAB products... Anyway, said program, on a specific 3D model, ran for 40 CPU seconds on our HP 9000/835, and the same binary executable code ran for 12 CPU seconds on a NON-yet-production version of a 9000/720 that HP was so kind as to lend us last week for evaluation purposes. Recompiling and relinking on the 720, however, pushed the runtime of the program on the 720 itself to 48 CPU seconds! Talk about compilers/runtime libraries tuned for the new machine...:-) Joking aside, I must assume that the I/O portion of the Fortran library must have been suffering from some kind of temporary aberration, who knows, maybe it was compiled for profiling or debugging in the version we were using. Other non-I/O tests did show performance improvements when recompiled/relinked on the 720 as opposed to just moving over the 835's binary executable, e.g. the 256x256 2D complex fourier transform benchmark that I published in the past ran for 2.3 CPU seconds in the 'native' version as opposed to 2.9 for the 835 version (versus 9.6 on the 835 itself). Summing up, apart from the (hopefully temporary!) aberration on the Fortran I/O library, the 720 does show a performance improvement over the previous models that is quite considerable for fully I/O bound applications (12secs vs 40, 3.3 times faster) as well as for apps with high computational content (2.9 secs vs 9.6, also 3.3 times faster), using in both cases a binary executable built on an HP835 for uniformity of comparison. As to whether it would be a shameful waste to use it as a file server, well, I guess it depends on whether you run Andrew on FDDI or NFS on Ethernet... (flames>/dev/null:-). -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).