Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!spool.mu.edu!news.cs.indiana.edu!ariel.unm.edu!spectre.unm.edu!john From: john@spectre.unm.edu (John Prentice) Newsgroups: comp.sys.super Subject: Re: Massively Parallel LINPACK on the Intel Touchstone Delta machine Message-ID: <1991Jun06.032918.158@ariel.unm.edu> Date: 6 Jun 91 03:29:18 GMT Article-I.D.: ariel.1991Jun06.032918.158 References: <1991Jun3.233741.8570@elroy.jpl.nasa.gov> <1991Jun5.120653.7852@hubcap.clemson.edu> <1991Jun05.185818.1071@convex.com> Organization: Dept. of Math & Stat, University of New Mexico, Albuquerque Lines: 32 In article <1991Jun05.185818.1071@convex.com> patrick@convex.COM (Patrick F. McGehearty) writes: >the most out of a machine under ideal circumstances. The requirement >that it also run on some other machine is intended to avoid machine >specific system calls. Does this benchmark idea sound interesting to >anyone else? Yes and no. Yes, because your idea would level the playing field and give people a feeling for what one might expect if you weren't able or willing to exploit the special aspects of a system. No, because one also wants to know just how much can be milked from a supercomputer. Perhaps what we need is both sets of benchmarks. I must admit however, I would like to see LINPACK benchmarks which tackle matrices of a size more on the order of 10,000 to 100,000. I can trivially invert a 1000 x 1000 in a few seconds on my Sparc. Telling me how fast I can do it on a supercomputer doesn't really tell me much about how a system performs on the kinds of problems I need it for. Allowing the benchmarker to scale the problem to his or her physical memory would seem to me to be a prescription for getting alot of results that can't be compared to each other. What I would prefer is to just fix the dimension, but fix it big. That would give a standard benchmark, but more importantly, from the perspective of a prospective user, it tells me how well the system can handle real problems, not ones choosen to scale nicely to a particular architecture. John -- John K. Prentice john@spectre.unm.edu (Internet) Computational Physics Group Amparo Corporation, Albuquerque, NM