eugene@eos.arc.nasa.gov (Eugene Miya) (11/21/90)
I hope it is okay that I defer responding to what Rafael and the DG
fellow mentioned about setting a reference machine aside. I have certainly
thought about those issues in the past and I will get to them (honest)
actually part of the reason appears below.
I don't think I will have time to post again this week (I am actively
trying to benchmark, at XXX, XXXX, XXXXXX, XXXXXX, and X-X 8^) due to the short
week and that I am away from my office.
Instead, let me present some issues having to do with metrics, how to take
a simple one, some of the intrusive forces which act on them, and
show some results. This is an intentionally naive survey.
There's lots of metrics: FLOPS (the joke was "When does a FLOPS become a
success?" [humor out of the way]) and its variants MFLOPS, GFLOPS, TFLOPS,
and I just saw EFLOPS in SC'90), but also MIPS (BIPS or GIPS),
counts of specific arbitrary units of work:
Whet|Dhry|NFS|IO|LHYNE|KHORNER|iHnsert your own STONES
RhollingStones......(at NBSLIB)
But also vaguer things like "Logical Inferences Per Second." (LIPS)
If you see a good measure of the latter, I want to talk to you.
I have no qualms of the Megas, Gigas, Teras, Etas, peta-prefixes.
I have no qualms about the "Second." I, and many others, do have
problems counting intructions, floating-operations (while ignoring
other instructions). Yes, it must be admitted early, "the only real
measure is how fast you get your solution done." If that is all you
see, and all you care about is buying machines, stop reading here
and go to the next post.
If you have continued, I hope, it is because you are interested in
other purposes of benchmarking to understand how to make machines faster.
I have come to some conclusions that raw timing and limited counts are
the most useful measures. Yes, they are too simple, but I have to try
and build a framework from the bottom up to understand benchmarking.
It is possible to definite any number of metrics, and write any number of
programs (I have a paper under review which one co-worker likes my
line "Any program can be a benchmark, but good benchmarks are hard to find.").
Sure, "A metric is defined by a function d() which maps elements on a space
X...," goes on to prove d maps to the positive real numbers, "triangle
inequality," I want to toss that aside.
I'd like to use a different, more empirical approach.
As a former mathematician, one of the common techniques of proof by
induction typically begins: If X exists, then there must be a smallest
representative of X. X here is a benchmark. We's like it to be
representative or something we do (computation). So I began s search for
"the smallest benchmark." Smallest has lots of advantages: carry it anywhere,
solves the portability problem (simplicity problem, sort of), ignoring
the database of results and changing time, no card images to carry, etc.
The smallest (fewest characters) of any benchmark I know is in APL.
Pardon my APL
256 (APL iota) ...(I have it written precisely somewhere)
Basically create a vector of elements 1..256 and sum them (Gaussian sum).
255 additions. Time this.
Also illustrates the very first example of optimization I know:
when Karl F. Gauss "found" n(n+1)/2. This optimization in a compiler
was reported to me by a person in the APL community who wishes to remain
anonymous, because he did this optimization prank, yes he did it as a prank,
on a user who used the above benchmark (doing a multiply, divide and one add
instead of 255 adds).
This is the shortest Unix benchmark I know:
echo 99k2vp8opq | /bin/time dc > /dev/null
Time the arbitrary precision desk calculator in Unix to compute
99 digits of the square root of 2. ("CPU benchmark") Now you learned
something. Try it. Suspend or move to another window and you, too can
run a benchmark {Pause exercise for reader. Users without
BSD style Job control can escape to the shell using '!sh' or '!csh'
non-Unix users, so sorry} I thought about collecting
timings (see a problem ahead). It's found in Musbus
among other places. We used it for some folk at Bell Labs when we
first got an X-MP/12 (actually Cray-1M).
Examples:
VAX-11/780 (convenient):
csh> echo 99k2vp8opq | /bin/time dc > /dev/null
5.8 real 5.3 user 0.2 sys
csh> uptime
1:28am up 2 days, 18:29, 2 users, load average: 0.20, 0.06, 0.06
SGI Iris 4D/60 (just me):
echo 99k2vp8opq | /bin/time dc > /dev/null
real 1.9
user 1.2
sys 0.2
Cray Y-MP/8128 (heavily loaded):
echo 99k2vp8opq | /bin/time dc > /dev/null
seconds clocks
elapsed 0.62413 104021600
user 0.36663 61104464
sys 0.03782 6302641
A large 32-bit mainframe (in use, maybe 12 users):
echo 99k2vp8opq | /bin/time dc > /dev/null
real 0.5
user 0.3
sys 0.0
You see some of the problems benchmarkers have to go thru (like formatting).
This took about 5 minutes of mousing around. It would have been much worse
if I had to deal with different operating systems, different timing
techniques, and different languages. These are all called
"CPU-memory" intensive measurements. They certainly minimize I/O
but they ignore any potential paging, etc. You can knock these
programs (too small, too simple, too easily optimized [Gauss himself]).
They are easily transported black boxes. They can be run so fast
their actual execution time (or the execution time of any benchmark)
improves too well to be a good measurement tool (converging on 0.0 seconds).
You may think I am presenting a straw man, but I am trying to show you that
"play" is an important part of benchmarking. We cannot explain how the
different machines above behaved. We took timings, but they can raise more
questions (*Why is the mainframe so close to the Cray? Sure, the Cray is
a fast word-oriented, floating-point engine. How do you get bytes? mask out
portions of the word (expensive). I think it is important that students
of benchmarking have experience on machines with some architectural
diversity, so that they can see some hardware (and software) artifacts
{this is over simple}. If students don't, if they stay on VAXen, IBM
PCs or the smaller mainframes, they will form some very bised views.
e.g., I am concerned about benchmarking data flow machines. *)
So suppose you are very fed up with the above "dc" benchmark
(I think from Bell Labs). You go off and naively write you own.
Let's suppose you have heard the term MFLOPS or MIPS as a metric:
Millions of floating point operations per second or millions of
instructions per second. If you constrain yourself to high-level languages
(at least in these days), again, you should have a smallest and simplest.
You know what a Million is. Suppose you wrote Fortran and timed:
C This is called a Pre-test initialization condition
X=1.0
Y=1.0
Then timed just:
Z=X+Y
/* for C programmers*/
float x=1.0, y=1.0, z;
and
z = x + y; /* 8^) */
Rmember let's be naive a moment, we don't know about registers,
caches (I'm going to run on a Cray, to those unfamiliar with Crays
it is an exercise for the reader to determine cache size), virtual memory,
etc...... If I run a million of these, that's a MFLOPs right?
[Additive linear models.] Using an integer real time clock I get:
1
STOP (called by $MAIN )
CP: 0.001s, Wallclock: 0.002s, 4.3% of 8-CPU Machine
HWM mem: 98502, HWM stack: 2048, Stack overflows: 0
That's 1 clock period. This is a 6.0 nanosecond machine. If I substitute
a floating point second clock, I get
2.8800000000002E-6
STOP (called by $MAIN )
CP: 0.001s, Wallclock: 0.003s, 3.2% of 8-CPU Machine
HWM mem: 98505, HWM stack: 2048, Stack overflows: 0
That's not 6.0 nanoseconds. Consider the following, if I had timed that
on a VAX (VMS or Unix) the time would have been zero (or very close,
it will not always be zero unless you synchronize your clock calls).
We assume several things are invariant: variable names, data types,
spaces are insignifcant to performance (this is not always the case).
If we had a 780 we would have to resort to some tricks to make a significant
"tick." If I have 1 MFLOP machine why can't I run the following in 1 second
(assuming an unloaded machine) [Fortran version]:
X = 0.0
10 X = X + 1.0
IF(X.LE.1000000.0) GO TO 10
C equivalent C is left as another reader exercise
That's a million floating-point additions (operations). Right? Oh, so
you see the comparison, is that an FLOP? Many people don't think of that.
Suppose it is. We cut the 1000000 to say 500000. We see that portions of
of measurement can interfere (I will make a distinction later between
intrusion and interference). Remember we are trying to keep this small.
Did you know some architectures can execute A*B+C very fast (nearly as fast
as a single + or *)? Why aren't we assuming time(+) == time (*)?
I have seen one FP measurement based on a machine which I cannot name
for non-disclosure, they gave a sample line of code which included
not only +,* to get fastest speed, but also trig functions (I have that
some where). That was the way to attain maximum speed on that machine.
There is another interference problem with that loop. A smart compiler
might eliminate the expression by a compile time evaluation. Such
loops are common when some programs repeat some unit of work many times
so that their low-resolution clocks can record some time (you then divide
by the number of repetitions to get an average rate [ignores an initial
page fault]. So some of this stuff is subtle,and it's why we need
to start thinking about measurement equivalence.
As a preview of advanced (play) issues to come, I offer:
It helps to have cycle time clocks, but non-intrusive (or minimally
intrusive) hardware monitoring tools will be needed. The real estate
is very expensive. Again, the Y-MP and the X-MP are good for this.
Can I post an hpm(1) man page without violating CRI's copyright? I
suspect not. But I think I can post simple output, to give you an idea
what it does, and we can get into details later. This is an output
for a simple FORTRAN program:
STOP (called by $MAIN )
CP: 0.001s, Wallclock: 0.002s, 4.1% of 8-CPU Machine
HWM mem: 97697, HWM stack: 2048, Stack overflows: 0
Group 0: CPU seconds : 0.00 CP executing : 193512
Million inst/sec (MIPS) : 44.30 Instructions : 51437
Avg. clock periods/inst : 3.76
% CP holding issue : 42.81 CP holding issue : 82845
Inst.buffer fetches/sec : 0.77M Inst.buf. fetches: 897
Floating adds/sec : 0.21M F.P. adds : 246
Floating multiplies/sec : 0.23M F.P. multiplies : 267
Floating reciprocal/sec : 0.05M F.P. reciprocals : 54
I/O mem. references/sec : 0.00M I/O references : 0
CPU mem. references/sec : 14.72M CPU references : 17092
Floating ops/CPU second : 0.49M
For a C program of equivalent functionality:
Group 0: CPU seconds : 0.00 CP executing : 35317
Million inst/sec (MIPS) : 46.83 Instructions : 9923
Avg. clock periods/inst : 3.56
% CP holding issue : 43.34 CP holding issue : 15308
Inst.buffer fetches/sec : 0.66M Inst.buf. fetches: 140
Floating adds/sec : 0.00M F.P. adds : 1
Floating multiplies/sec : 0.00M F.P. multiplies : 0
Floating reciprocal/sec : 0.00M F.P. reciprocals : 0
I/O mem. references/sec : 0.00M I/O references : 0
CPU mem. references/sec : 17.20M CPU references : 3645
Floating ops/CPU second : 0.00M
ls -l on the executables:
-rwxr-xr-x 1 eugene xxx 717264 Nov 20 23:55 xxx
-rwxr-xr-x 1 eugene xxx 108128 Nov 20 23:56 xx
You would probably be shocked what these programs do for so much storage.
I should compile VAX and SUN equivalents. (I will tell in time.)
VAX:
-rwxr-xr-x 1 eugene 25600 Nov 21 02:29 xxx
-rwxr-xr-x 1 eugene 4096 Nov 21 02:31 xx
SUN
/* can't get the fortran compiler on my sun, NFS down*/
-rwxr-xr-x 1 eugene 24576 Nov 21 02:39 xx
If you don't see the concept, it doesn't exist --Arthur Pyster
paraphasing Gerge Orwell.
We need more tools like the HPM. Software alone will not help the performance
measurement problem. Students MUST have exposure to tools of this type.
We need to develop frames of reference and calibration tools to better
understand our benchmarks and what they are doing. Then you too
can do a `man hpm`.
Let me investigate more specific, less naive details next week.
Whole bunch of issues to cover.
--e.n. miya, NASA Ames Research Center, eugene@eos.arc.nasa.gov
{uunet,mailrus,most gateways}!ames!eugene
AMERICA: CHANGE IT OR LOSE IT.
It's 3 AM and I need to get at least 2 sleep periods.
Resident cynic, Rock of Ages Home for Retired Hackerswunder@orac.HP.COM (Walter Underwood) (11/22/90)
This is the shortest Unix benchmark I know:
echo 99k2vp8opq | /bin/time dc > /dev/null
Interesting. A friend of mine was using a very similar benchmark at
least seven years ago. Originally, it was:
echo 2^5000 | /bin/time bc > /dev/null
but that includes significant amounts of time in printing the large
number, so the benchmark was changed to:
echo 2^5000/2^5000 | /bin/time bc
which prints "1".
Last time I looked at the guts of bc, this should be mostly following
pointer chains and doing arithmetic with small integers. It uses base
100, kept in indvidual bytes, I think.
wunder
PS: On a somewhat busy 50 MHz 60030 machine (HP9000/375, HP-UX 7.0):
$ echo 2^5000/2^5000 | /bin/time bc
1
real 14.4
user 9.4
sys 0.1crispin@csd.uwo.ca (Crispin Cowan) (11/23/90)
In article <19040001@orac.HP.COM> wunder@orac.HP.COM (Walter Underwood) writes: [shortest benchmark] > echo 2^5000/2^5000 | /bin/time bc > >which prints "1". >On a somewhat busy 50 MHz 60030 machine (HP9000/375, HP-UX 7.0): > >$ echo 2^5000/2^5000 | /bin/time bc >1 > >real 14.4 >user 9.4 >sys 0.1 While this is a short benchmark, and is much better than the naive one posted to com.arch a while ago (which was massively dominated by divide instructions), it also isn't very indicitive. Some examples of user CPU time on various machines: machine bc as above latex my thesis build gcc uVAX 3200 20.5 300 1500 Sequent S27 26.7 200 NA Sun 3/50 42.9 NA 1800 Sun 3/110 39.3 NA 1400 Sun 3/60 29.8 NA 1100 The numbers track across the Sun 3's, as expected (same CPU, same code). However, it does kinda over-estimate the VAX, both with respect to the Sequent (386, 16 MHz), and the Suns. Anyone know what the VAX is doing to get superior performance on bc, and inferior on these other applications? Crispin ----- Crispin Cowan, CS grad student, University of Western Ontario Work: MC28-C, x3342 crispin@csd.uwo.ca 890 Elias St., London, Ontario, N5W 3P2, 432-7823 ---> Support the GST: Canada's first fair tax <---
tif@doorstop.austin.ibm.com (Paul Chamberlain) (11/27/90)
In article <19040001@orac.HP.COM> wunder@orac.HP.COM (Walter Underwood) writes: >PS: On a somewhat busy 50 MHz 60030 machine (HP9000/375, HP-UX 7.0): > >$ echo 2^5000/2^5000 | /bin/time bc >1 > >real 14.4 >user 9.4 >sys 0.1 On a mostly idle IBM Risc System/6000 (I think it's a 730 running gold) 1 real 3.5 user 3.5 sys 0.0 Just an informal number for the Enquiring Minds... Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmchs!auschs!doorstop.austin.ibm.com!tif
karplus@ararat.ucsc.edu (Kevin Karplus) (11/29/90)
Wasting more bandwidth on a trivial benchmark.
Running my Sparcstation SLC on
echo 2^5000/2^5000 | /bin/time bc
yielded
44.5 real 43.4 user 0.1 sys zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/29/90)
>Wasting more bandwidth on a trivial benchmark. >Running my Sparcstation SLC on > echo 2^5000/2^5000 | /bin/time bc >yielded > 44.5 real 43.4 user 0.1 sys That's about (45.9) what it yields on a 3/50. I suspect that this isn't a very good benchmark :-). -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us
meissner@osf.org (Michael Meissner) (11/30/90)
In article <NHZ_D+?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: | Path: paperboy!snorkelwacker.mit.edu!apple!usc!samsung!b-tech!zeeff | From: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) | Newsgroups: comp.benchmarks | Date: 29 Nov 90 14:56:22 GMT | References: <19040001@orac.HP.COM> <4344@awdprime.UUCP> <9516@darkstar.ucsc.edu> | Organization: Branch Technology | Lines: 11 | | >Wasting more bandwidth on a trivial benchmark. | >Running my Sparcstation SLC on | > echo 2^5000/2^5000 | /bin/time bc | >yielded | > 44.5 real 43.4 user 0.1 sys | | That's about (45.9) what it yields on a 3/50. I suspect that this | isn't a very good benchmark :-). On a DECstation 2100, you get: 13.4 real 12.6 user 0.2 sys I suspect the reason Sparcstation's get such lousy time compared other equivalent systems, is the fact that the hardware does not do integer multiply and divide, and it makes a Sun3 competitive in those cases. Checking the 4.3-tahoe sources, shows that there is no floating point code in bc, and everything is done via integers. Most integer multiplies in real world code are because of array references, and amenable to using shift/add combinations if constant, or strength reduction if not. However, as I noted in comp.lang.misc, some compilers (like GCC) lose sight of the fact that a multiplication is taking place if it has transformed the multiply internally into a function call, so strength reduction does not get invoked. While I'm on the subject of strength reduction, I noted that when I worked on GCC for the 88k, that strength reduction was rarely a win. This is because the 88k has a reasonably fast integer multiply instruction (4 clocks), and it has funcitonal units that operate in parallel. Futhermore, strength reduction tends to require one additional register, which means if you are close to running out of registers in the inner loop, something now has to live on the stack in that previously lived in a register. Dhrystone 2.1 in fact, showed up this problem (I guess it's useful after all :-). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
juan@burdell.gatech.edu (Juan Orlandini) (11/30/90)
In article <MEISSNER.90Nov29155219@curley.osf.org> meissner@osf.org (Michael Meissner) writes: >In article <NHZ_D+?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > >| >Wasting more bandwidth on a trivial benchmark. >| >Running my Sparcstation SLC on >| > echo 2^5000/2^5000 | /bin/time bc >| >yielded >| > 44.5 real 43.4 user 0.1 sys >| >| That's about (45.9) what it yields on a 3/50. I suspect that this >| isn't a very good benchmark :-). > >On a DECstation 2100, you get: > > 13.4 real 12.6 user 0.2 sys On my sparcstation 1 I got: 16.0 real 15.2 user 0.1 sys I think something is amiss with Jon's machine. Juan ======================================================================= Juan Orlandini /// "Whe have not inherited this /// Super User At Large /// earth from our parents, but /// College of Computing \\\/// rather borrowed it from our \\\/// juan@cc.gatech.edu \XX/ children." -- Unknown \XX/ =======================================================================
juan@burdell.gatech.edu (Juan Orlandini) (11/30/90)
In article <513@mephisto.edu> juan@cc.gatech.edu (Juan Orlandini) writes: |In article <MEISSNER.90Nov29155219@curley.osf.org> meissner@osf.org (Michael Meissner) writes: |>In article <NHZ_D+?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: |> |>| >Wasting more bandwidth on a trivial benchmark. |>| >Running my Sparcstation SLC on |>| > echo 2^5000/2^5000 | /bin/time bc |>| >yielded |>| > 44.5 real 43.4 user 0.1 sys |>| |>| That's about (45.9) what it yields on a 3/50. I suspect that this |>| isn't a very good benchmark :-). |> |>On a DECstation 2100, you get: |> |> 13.4 real 12.6 user 0.2 sys | |On my sparcstation 1 I got: | 16.0 real 15.2 user 0.1 sys | |I think something is amiss with Jon's machine. | |Juan an as an addendum, on the one SLC we have in the department: 15.4 real 15.1 user 0.1 sys Something is definetly(sp?) wrong with Jon's machine. Juan ======================================================================= Juan Orlandini /// "Whe have not inherited this /// Super User At Large /// earth from our parents, but /// College of Computing \\\/// rather borrowed it from our \\\/// juan@cc.gatech.edu \XX/ children." -- Unknown \XX/ =======================================================================
casper@fwi.uva.nl (Casper H.S. Dik) (11/30/90)
meissner@osf.org (Michael Meissner) writes: >In article <NHZ_D+?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >| >Wasting more bandwidth on a trivial benchmark. >| >Running my Sparcstation SLC on >| > echo 2^5000/2^5000 | /bin/time bc >| >yielded >| > 44.5 real 43.4 user 0.1 sys >| >| That's about (45.9) what it yields on a 3/50. I suspect that this >| isn't a very good benchmark :-). >On a DECstation 2100, you get: > 13.4 real 12.6 user 0.2 sys >I suspect the reason Sparcstation's get such lousy time compared other >equivalent systems, is the fact that the hardware does not do integer >multiply and divide, and it makes a Sun3 competitive in those cases. >Checking the 4.3-tahoe sources, shows that there is no floating point >code in bc, and everything is done via integers. Funny, when someone posts wrong results of a benchmark, someone else finds a plausible explanation. My numbers are (all systems running SunOS 4.1): SS 1+ 12.6 real 12.0 user 0.1 sys SLC 15.4 real 15.1 user 0.1 sys (!) Sun 4/370 12.3 real 11.2 user 0.3 sys Sun 4/470 9.1 real 8.3 user 0.0 sys Sun 3/60 31.0 real 29.9 user 0.4 sys Sun 3/80 38.3 real 28.6 user 0.6 sys Casper -- NOTE: Some machine instructions | Casper H.S. Dik must be executed on the CPU. | casper@fwi.uva.nl (a manual page on the Gould PowerNode) | NIC: !cd151
de5@ornl.gov (Dave Sill) (11/30/90)
In article <NHZ_D+?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > >Wasting more bandwidth on a trivial benchmark. > > echo 2^5000/2^5000 | /bin/time bc I can't resist. Summarizing the results posted so far, and adding a few of my own: IBM RS/6000 320 4.4 de5 DECstation 5000/200 6.0 de5 DECsystem 5810 6.2 de5 Cray XMP (Unicos) 8.6 de5 SPARCstation 1+ 12.2 de5 DECstation 2100 12.8 de5 DECstation 2100 13.4 juan SPARCstation SLC 15.4 meissner SPARCstation 1 16.0 juan SPARCstation SLC 44.5 zeeff Sun 3/50 45.9 zeeff MicroVAX ? 75.7 de5 All of mine were done on lightly to not at all loaded systems, and were the best of 3-4 consecutive runs. The first run, without exception, took significantly longer than any subsequent runs. Disappointing Cray result, but the IBM was impressive. -- Dave Sill (de5@ornl.gov) Martin Marietta Energy Systems Workstation Support
dwf@hope.lanl.gov (David W. Forslund) (11/30/90)
>Wasting more bandwidth on a trivial benchmark. > > echo 2^5000/2^5000 | /bin/time bc Sparcstation 2GX: 7.0 sec user time. -- David Forslund Advanced Computing Laboratory MS B287 Los Alamos National Laboratory Los Alamos, NM 87545 Voice:(505) 665-1907 FAX: (505) 665-4939 EMAIL: dwf@lanl.gov
ethan@thinc.UUCP (Ethan Lish of THINC) (11/30/90)
In article <NHZ_D+?@b-tech.uucp>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > >Wasting more bandwidth on a trivial benchmark. > >Running my Sparcstation SLC on > > echo 2^5000/2^5000 | /bin/time bc > >yielded > > 44.5 real 43.4 user 0.1 sys > > That's about (45.9) what it yields on a 3/50. I suspect that this > isn't a very good benchmark :-). > > -- > Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us Greetings - This _benchmark_ does *NOT* have a legitimate value! Here are the numbers for my INTeL 80286 Box w/ SCO Xenix 45.8 real 45.1 user 0.2 sys NOW, You can't tell me that these numbers quantify the magnitude of the performance variance between a Sparcstation and a PC! Bye, Ethan -- "A compulsion for perfection, choking out the importance of finishing" in The Devouring Fungus by Karla Jennings Ethan Lish __________ 1.301.652.0651 __________ {uunet,anagld}!thinc!ethan Tomorrow's Horizons, Inc. 4807 Bethesda Ave, #330, Bethesda, MD 20814-5299
dvl@hpcupt1.cup.hp.com (Doug Larson) (12/01/90)
HP9000 series 870: real 5.5 user 5.5 sys 0.0 Doug Larson Hewlett Packard Unix Kernel Lab Disclaimer: Nothing I say, do, or think should be construed to be the official position of HP
meissner@osf.org (Michael Meissner) (12/01/90)
In article <1990Nov30.132116.13462@cs.utk.edu> de5@ornl.gov (Dave Sill) writes: | Summarizing the results posted so far, and adding a few of my own: ... | SPARCstation SLC 15.4 meissner Ummm, I posted results for a DECstation 2100. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
philip@beeblebrox.dle.dg.com (Philip Gladstone) (12/01/90)
This is the output from my machine (88k at 25 Mhz):
echo 2^5000/2^5000 | /bin/time bc
1
real 8.1
user 8.0
sys 0.0
Is someone collecting these numbers?
--
Philip Gladstone Dev Lab Europe, Data General, Cambridge, UK
Listen three eyes, don't you try and outweird me, I get
stranger things that you free with my breakfast cereal.kmk@assari.tut.fi (Kai 'Kaizzu' Kein{nen) (12/01/90)
On 30 Nov 90 13:21:16 GMT, de5@ornl.gov (Dave Sill) said: Dave> In article <NHZ_D+?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > >Wasting more bandwidth on a trivial benchmark. > > echo 2^5000/2^5000 | /bin/time bc Dave> I can't resist. Me neither... Dave> Summarizing the results posted so far, and adding a few of my own: Dave> IBM RS/6000 320 4.4 de5 Dave> DECstation 5000/200 6.0 de5 Dave> DECsystem 5810 6.2 de5 Dave> Cray XMP (Unicos) 8.6 de5 [...] vtlehtori:~ 306 % echo 2^5000/2^5000 | /bin/time bc 1 real 2.8 user 2.8 sys 0.0 vtlehtori:~ 307 % uname -A vtlehtori vtlehtori 4_51 UMIPS mips RC6280 ATT_V3_0 vtlehtori:~ 308 % (consistently in 5 tests) Dave> Disappointing Cray result, but the IBM was impressive. I *knew* they were slow... :) Some mips R3000 processor results: real user sys MIPS RC3280: 7.0 6.0 0.2 (1 R3000) Stardent 3000: 6.0 5.8 0.1 (4 R3000s) Silicon Graphics 4D/380SX: 5.2 5.2 0.0 (8 R3000s) -- ------------------------------------------------------ - Kai 'Kaizzu' Kein{nen < - > kmk@tut.fi - - Tampere University of Technology, Computing Center - ------------------------------------------------------
NEUMANN@awiwuw11.wu-wien.ac.at (Gustaf Neumann) (12/02/90)
Some more figures of the bc test:
DecStation 3100, Ultrix 3.1
9.8 real 9.6 user 0.1 sys
DecStation 3100, Ultrix 4.0
9.7 real 9.4 user 0.1 sys
DecStation 5000/200, Ultrix 4.0
6.0 real 6.0 user 0.0 sys
HP9000/835 (HP-UX 7.0)
20.6 real 18.0 user 0.1 sys
No idea, why our 835 looks so bad. Any explanations for the
different results on SLCs?
Here is the updated bc hit-pararde (user time):
IBM RS/6000 720 3.5 tif
IBM RS/6000 320 4.4 de5
DECstation 5000/200 6.0 de5
DECstation 5000/200 (U 4.0) 6.0 neumann
DECsystem 5810 6.2 de5
Sparcstation 2GX 7.0 dwf
Sun 4/470 (sos 4.1) 8.3 casper
Cray XMP (Unicos) 8.6 de5
DECstation3100 (U 4.0) 9.4 neumann
HP9000/375 (HP-UX 7.0) 9.4 wunder
DECstation3100 (U 3.1) 9.6 neumann
Sun 4/370 (sos 4.1) 11.2 casper
SPARCstation 1+ (sos 4.1) 12.0 casper
SPARCstation 1+ 12.2 de5
DECstation 2100 12.8 de5
DECstation 2100 12.6 meissner
SLC (sos 4.1) 15.1 casper
SLC 15.1 juan
Sparcstation 1 15.2 juan
HP9000/835 (HP-UX 7.0) 18.0 neumann
MicroVAX 3200 20.5 crispin
Sequent S27 26.7 crispin
Sun 3/80 (sos 4.1) 28.6 casper
Sun 3/60 29.8 crispin
Sun 3/60 (sos 4.1) 29.9 casper
Sun 3/110 39.3 crispin
SPARCstation SLC 43.4 zeeff
SPARCstation SLC 43.4 karplus
80286 (xenix) 45.1 ethan
Sun 3/50 42.9 crispin
Sun 3/50 45.9 zeeff
MicroVAX ? 75.7 de5
-------------------------------------------------------------------
Gustaf Neumann neumann@dec4.wu-wien.ac.at, neumann@awiwuw11.bitnet
Vienna University of Economics and Business Administration
Augasse 2-6, A-1090 Vienna, Austria
Tel: +43 (222) 31-336 x4533 Fax 347-555zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (12/02/90)
>|In article <MEISSNER.90Nov29155219@curley.osf.org> meissner@osf.org (Michael Meissner) writes: >|>In article <NHZ_D+?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >|> >|>| >Running my Sparcstation SLC on >|>| > 44.5 real 43.4 user 0.1 sys >|>| That's about (45.9) what it yields on a 3/50. I suspect that this >|>| isn't a very good benchmark :-). >| >|I think something is amiss with Jon's machine. >| >an as an addendum, on the one SLC we have in the department: > > 15.4 real 15.1 user 0.1 sys > >Something is definetly(sp?) wrong with Jon's machine. My (Jon's) machine is the 3/50. Maybe I should have Sun service take a look at my excess speed problem :-)? -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us
turner@sp64.csrd.uiuc.edu (Steve Turner) (12/02/90)
This looks like just too much fun to pass up. Hope I'm not violating
my non-disclosure agreement... (.5x ;-)
Alliant FX/2800 (28 i860's with local cache disabled, sharing 256M)
3.6 real 3.5 user 0.0 sys
BTW - the load at the time included 5 heavyweight (~10M resident)
processes and a few sundry shells, compiles, and editors.
--
Steve Turner (on the Si prairie - UIUC CSRD)
ARPANET: turner@csrd.uiuc.edu
Phone: (217) 244-7293 or (217) 367-0882
I went walking in the wasted city / Started thinking about entropy
Smelled the wind from the ruined river / Went home to watch TV
-- Warren Zevonjsadler@misty.boeing.com (Jim Sadler) (12/03/90)
/ misty:comp.benchmarks / NEUMANN@awiwuw11.wu-wien.ac.at (Gustaf Neumann) / 10:21 am Dec 1, 1990 / >HP9000/835 (HP-UX 7.0) > 20.6 real 18.0 user 0.1 sys > >No idea, why our 835 looks so bad. Any explanations for the The following is from a HP9000-835CHXSE HP-UX 7.0 misty.jsadler /users/jsadler$ uptime 9:35pm up 6 days, 13:14, 1 user, load average: 0.02, 0.04, 0.15 misty.jsadler /users/jsadler$ echo 2^5000/2^5000 | /bin/time bc 1 real 19.2 user 18.1 sys 0.1 misty.jsadler /users/jsadler$ echo 2^5000/2^5000 | /bin/time bc 1 real 18.6 user 18.2 sys 0.0 misty.jsadler /users/jsadler$ echo 2^5000/2^5000 | /bin/time bc 1 real 18.3 user 18.1 sys 0.0 misty.jsadler /users/jsadler$ echo 2^5000/2^5000 | /bin/time bc 1 real 18.2 user 18.1 sys 0.0 misty.jsadler /users/jsadler$ uptime 9:37pm up 6 days, 13:16, 1 user, load average: 0.68, 0.26, 0.22 misty.jsadler /users/jsadler$ echo 2^5000/2^5000 | /bin/time bc 1 real 18.3 user 18.1 sys 0.0 Now is the 10% that big of a deal. There must be something appropriate to say about the number of posting about a "simple benchmark". jim sadler 206-234-9009 email uunet!bcstec!jsadler | jsadler@misty.boeing.com This service is brought to you by the computing mafia of Boeing (BCS). Oh ya None of the above is an opinion of The Boeing Co.
buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) (12/05/90)
A Silicon Graphics 4D/20 IRIX 3.2.3 gave:
real 13.4
user 13.1
sys 0.1
but a more interesting test would be the following:
echo 2.1^5000/2^5000 | /bin/time bc
8840877025741739372995278738276746897465471931986497903162598183670954\
192449780889302845715668915405005692
real 2:17.9
user 2:12.6
sys 1.5
which is non-trivial and should give Maple, and other similar programs
a workout as well.
B Cing U
Buck
Loren Buchanan | buck@drax.gsfc.nasa.gov | #include <std_disclaimer.h>
CSC, 1100 West St. | ...!ames!dftsrv!drax!buck | typedef int by
Laurel, MD 20707 | (301) 497-2531 | void where_prohibited(by law){}
Phone tag, America's fastest growing business sport.doi@jrdmax.jrd.dec.com (Hitoshi Doi) (12/05/90)
Some more numbers.. DECsystem 5400 (J-ULTRIX v4.0) 7.6 VAX 6320 (J-ULTRIX v4.1) 15.1 VAX 6410 (ULTRIX v4.0) 12.8 MicroVAX 3900 (J-ULTRIX v4.0) 13.5 VAX 8800 (ULTRIX v4.0) 12.1 MicroVAX 2000 (J-ULTRIX v4.1) 74.1 IBM RS/6000 720 3.5 tif IBM RS/6000 320 4.4 de5 DECstation 5000/200 6.0 de5 DECstation 5000/200 (U 4.0) 6.0 neumann DECsystem 5810 6.2 de5 Sparcstation 2GX 7.0 dwf DECsystem 5400 (U 4.0) 7.6 doi Sun 4/470 (sos 4.1) 8.3 casper Cray XMP (Unicos) 8.6 de5 DECstation3100 (U 4.0) 9.4 neumann HP9000/375 (HP-UX 7.0) 9.4 wunder DECstation3100 (U 3.1) 9.6 neumann Sun 4/370 (sos 4.1) 11.2 casper SPARCstation 1+ (sos 4.1) 12.0 casper VAX 8800 (U 4.0) 12.1 doi SPARCstation 1+ 12.2 de5 DECstation 2100 12.8 de5 DECstation 2100 12.6 meissner VAX 6410 (U4.0) 12.8 doi MicroVAX 3900 (U 4.0) 13.5 doi SLC (sos 4.1) 15.1 casper SLC 15.1 juan VAX 6320 (U 4.1) 15.1 doi Sparcstation 1 15.2 juan HP9000/835 (HP-UX 7.0) 18.0 neumann MicroVAX 3200 20.5 crispin Sequent S27 26.7 crispin Sun 3/80 (sos 4.1) 28.6 casper Sun 3/60 29.8 crispin Sun 3/60 (sos 4.1) 29.9 casper Sun 3/110 39.3 crispin SPARCstation SLC 43.4 zeeff SPARCstation SLC 43.4 karplus 80286 (xenix) 45.1 ethan Sun 3/50 42.9 crispin Sun 3/50 45.9 zeeff MicroVAX 2000 (U 4.1) 74.1 doi MicroVAX ? 75.7 de5 -- Hitoshi Doi, International Systems Engineering doi@jrdmax.enet.dec.com Japan Research and Development Center decwrl!jrdmax.enet!doi Digital Equipment Corporation Japan
elm@sprite.Berkeley.EDU (ethan miller) (12/06/90)
Two more numbers, for Cray machines running Unicos:
Cray Y-MP (6ns clock): 5.0
Cray 2 (4.1ns clock): 8.8
The entire listing is now:
IBM RS/6000 720 3.5 tif
IBM RS/6000 320 4.4 de5
Cray Y-MP (Unicos, 6ns clk) 5.0 elm
DECstation 5000/200 6.0 de5
DECstation 5000/200 (U 4.0) 6.0 neumann
DECsystem 5810 6.2 de5
Sparcstation 2GX 7.0 dwf
DECsystem 5400 (U 4.0) 7.6 doi
Sun 4/470 (sos 4.1) 8.3 casper
Cray XMP (Unicos) 8.6 de5
Cray 2 (Unicos, 4.1ns clk) 8.8 elm
DECstation3100 (U 4.0) 9.4 neumann
HP9000/375 (HP-UX 7.0) 9.4 wunder
DECstation3100 (U 3.1) 9.6 neumann
Sun 4/370 (sos 4.1) 11.2 casper
SPARCstation 1+ (sos 4.1) 12.0 casper
VAX 8800 (U 4.0) 12.1 doi
SPARCstation 1+ 12.2 de5
DECstation 2100 12.8 de5
DECstation 2100 12.6 meissner
VAX 6410 (U4.0) 12.8 doi
MicroVAX 3900 (U 4.0) 13.5 doi
SLC (sos 4.1) 15.1 casper
SLC 15.1 juan
VAX 6320 (U 4.1) 15.1 doi
Sparcstation 1 15.2 juan
HP9000/835 (HP-UX 7.0) 18.0 neumann
MicroVAX 3200 20.5 crispin
Sequent S27 26.7 crispin
Sun 3/80 (sos 4.1) 28.6 casper
Sun 3/60 29.8 crispin
Sun 3/60 (sos 4.1) 29.9 casper
Sun 3/110 39.3 crispin
SPARCstation SLC 43.4 zeeff
SPARCstation SLC 43.4 karplus
80286 (xenix) 45.1 ethan
Sun 3/50 42.9 crispin
Sun 3/50 45.9 zeeff
MicroVAX 2000 (U 4.1) 74.1 doi
MicroVAX ? 75.7 de5
ethan
--
=================================
ethan miller--cs grad student elm@sprite.berkeley.edu
#include <std/disclaimer.h> {...}!ucbvax!sprite!elm
Witty signature line condemned due to major quake damage.adin@Math.UFL.EDU (Adin Burroughs) (12/06/90)
In article <1990Dec5.000522.11635@jrd.dec.com>, doi@jrdmax.jrd.dec.com (Hitoshi Doi) writes: |> Some more numbers.. [stuff deleted] |> |> -- |> Hitoshi Doi, International Systems Engineering doi@jrdmax.enet.dec.com |> Japan Research and Development Center decwrl!jrdmax.enet!doi |> Digital Equipment Corporation Japan Doews anyone have any #'s on the new A3000UX by Commodore? I know that it is shipping with beta SYSVR4 to dealers and universities... -Adin -- ----------------------------------------------------------------------------- | | | .Sig 1.1 under construction..... U of F, Gainesville, FL | | adin@math.ufl.edu | | adb@beach.cis.ufl.edu | | Iceman@maple%decnet.circa.ufl.edu | | 'Tis better to have loved and | | lost than to have never loved at all........ | -----------------------------------------------------------------------------
boehm@parc.xerox.com (Hans Boehm) (12/06/90)
In article <4092@dftsrv.gsfc.nasa.gov> buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) writes: >but a more interesting test would be the following: >echo 2.1^5000/2^5000 | /bin/time bc >8840877025741739372995278738276746897465471931986497903162598183670954\ >192449780889302845715668915405005692 >real 2:17.9 >user 2:12.6 >sys 1.5 >which is non-trivial and should give Maple, and other similar programs >a workout as well. >B Cing U >Buck It's still the case though that different evaluation strategies lead to widely differing results. Our calculator, which does ``exact'' real arithmetic with demand driven evaluation (and thus potentially a lot more work) takes 520 secs on a SS-1 to compute the result to about 30 digits to the right of the decimal point. (This is largely because I have to ask it to compute (2.1^5000) to the same precision. The number might be much smaller with a bc like interface.) However, it computes (2.1/2.0)^5000 to the same precision in 0.6 secs. It does this by computing a log and an exponential to the right precision. I dont know what dc does. Hans
prc@erbe.se (Robert Claeson) (12/06/90)
In article <90335.174813NEUMANN@awiwuw11.wu-wien.ac.at> NEUMANN@awiwuw11.wu-wien.ac.at (Gustaf Neumann) writes:
:Here is the updated bc hit-pararde (user time):
:
:IBM RS/6000 720 3.5 tif
:IBM RS/6000 320 4.4 de5
:DECstation 5000/200 6.0 de5
:DECstation 5000/200 (U 4.0) 6.0 neumann
:DECsystem 5810 6.2 de5
:Sparcstation 2GX 7.0 dwf
:Sun 4/470 (sos 4.1) 8.3 casper
:Cray XMP (Unicos) 8.6 de5
:DECstation3100 (U 4.0) 9.4 neumann
:HP9000/375 (HP-UX 7.0) 9.4 wunder
:DECstation3100 (U 3.1) 9.6 neumann
:Sun 4/370 (sos 4.1) 11.2 casper
:SPARCstation 1+ (sos 4.1) 12.0 casper
:SPARCstation 1+ 12.2 de5
:DECstation 2100 12.8 de5
:DECstation 2100 12.6 meissner
:SLC (sos 4.1) 15.1 casper
:SLC 15.1 juan
:Sparcstation 1 15.2 juan
:HP9000/835 (HP-UX 7.0) 18.0 neumann
:MicroVAX 3200 20.5 crispin
:Sequent S27 26.7 crispin
:Sun 3/80 (sos 4.1) 28.6 casper
:Sun 3/60 29.8 crispin
:Sun 3/60 (sos 4.1) 29.9 casper
:Sun 3/110 39.3 crispin
:SPARCstation SLC 43.4 zeeff
:SPARCstation SLC 43.4 karplus
:80286 (xenix) 45.1 ethan
:Sun 3/50 42.9 crispin
:Sun 3/50 45.9 zeeff
:MicroVAX ? 75.7 de5
I just got the following result:
DG AViiON AV200 (DG/UX 4.30) 12.6 prc
The AV100 should yield the same result, as it is essentially the same
machine but not as expandable as the AV200.
--
Robert Claeson |Reasonable mailers: rclaeson@erbe.se
ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se
Jakobsberg, Sweden | Perverse mailers: rclaeson%erbe.se@encore.com
Any opinions expressed herein definitely belongs to me and not to my employer.renglish@hplabsz.HPL.HP.COM (Bob English) (12/07/90)
A couple of people have raised points concerning the validity of this one-liner, what it measures, etc. First, many people have argued that there is too much "other stuff" going on to evaluate what the results of this test mean and extrapolate to other applications. I tried using the compile-only argument to bc and passing its output directly to dc. The difference was measurable only on the 825, and amounted to about 1% of the execution time. On the 845 and 870, the difference was not measurable. Second, many people have argued that bc(1) performance is not important, and that the wide acceptance of this benchmark might cause vendors to spend valuable time optimizing bc(1), when it might be better spent elsewhere. Despite what some people think, vendors make money by satis- fying their customers, not by misleading them into buying deficient pro- ducts. Engineers and programmers will often reject optimizations that address only a benchmark, unless that benchmark itself represents a serious customer use. In any case, I seriously doubt that bc will ever displace more widely recognized benchmarks as a focus of vendor activity. % echo 2^5000/2^5000 | /bin/time bc HP9000/825 23.9s user 0.1 system (24.2 real, unloaded system) HP9000/835 17.9s user 0.1 system (18.0 real, unloaded system) HP9000/845 9.9s user 0.0 system (10.0 real, unloaded system) HP9000/870 5.6s user 0.0 system (10.7 real, loaded system) --bob-- renglish@hplabs "If I were running the company, even the door handles would be cool."
hh@rhi.hi.is (Hjalmtyr Hafsteinsson) (12/07/90)
> echo 2^5000/2^5000 | /bin/time bc
Two more entries:
real user sys
IBM RS/6000 540 3.3 2.8 0.0 (impressive!)
HP 9000/840 1:26.5 37.6 2.2 (heavily loaded!)
and the latest bc hit-pararde (user time):
Fujitsu M780/10 UTS 1.8 toyama
IBM RS/6000 540 2.8 hh
MIPS RC6280 2.8 mgj
Alliant FX/2800 3.5 turner
IBM RS/6000 720 3.5 tif
AMDAHL 5870 (UTS) 4.3 xxdon
IBM RS/6000 320 4.4 de5
Cray Y-MP (Unicos, 6ns clk) 5.0 elm
SGI 320 (2 cpu) 5.2 xxdon
SGI 340 (4 cpu) 5.2 xxdon
Silicon Graphics 4D/380SX 5.2 kmk
HP 9000/870 5.5 doug
Stardent 3000 5.8 kmk
CRAY YMP4/64 5.9 xxdon
DECstation 5000/200 6.0 de5
DECstation 5000/200 (U 4.0) 6.0 neumann
MIPS M/2000 6.0 mark
MIPS RC3280 6.0 kmk
DECsystem 5810 6.2 de5
Sparcstation 2GX 7.0 dwf
DECsystem 5400 (U 4.0) 7.6 doi
CRAY XMP4/8 7.8 xxdon
88000 (25MHz) 8.0 philip
SGI 4D25 8.1 xxdon
Sun 4/470 (sos 4.1) 8.3 casper
Cray XMP (Unicos) 8.6 de5
Cray 2 (Unicos, 4.1ns clk) 8.8 elm
Compaq 486/25 ISC 2.2 9.1 sku
CONVEX C220 9.4 xxdon
DECstation3100 (U 4.0) 9.4 neumann
HP9000/375 (HP-UX 7.0) 9.4 wunder
DECstation3100 (U 3.1) 9.6 neumann
MIPS RS2030 10.0 mark
Sun 4/370 (sos 4.1) 11.2 casper
SPARCstation 1+ (sos 4.1) 12.0 casper
Compaq 386/33 ISC 2.2 12.1 sku
VAX 8800 (U 4.0) 12.1 doi
SPARCstation 1+ 12.2 de5
DECstation 2100 12.6 meissner
DECstation 2100 12.8 de5
VAX 6410 (U4.0) 12.8 doi
Silicon Graphics 4D/20 13.1 buck
MicroVAX 3900 (U 4.0) 13.5 doi
SLC (sos 4.1) 15.1 casper
SLC 15.1 juan
VAX 6320 (U 4.1) 15.1 doi
Sparcstation 1 15.2 juan
Compaq 386/25 ISC 2.2 16.1 sku
HP9000/835 (HP-UX 7.0) 18.0 neumann
MicroVAX 3200 20.5 crispin
Sequent S27 26.7 crispin
Sun 3/80 (sos 4.1) 28.6 casper
Sun 3/60 29.8 crispin
Sun 3/60 (sos 4.1) 29.9 casper
HP9000/840 37.6 hh
SGI 3030 37.8 xxdon
Sun 3/110 39.3 crispin
SPARCstation SLC 43.4 zeeff
SPARCstation SLC 43.4 karplus
80286 (xenix) 45.1 ethan
Sun 3/50 42.9 crispin
Sun 3/50 45.9 zeeff
MicroVAX 2000 (U 4.1) 74.1 doi
MicroVAX ? 75.7 de5
Zenith 386/20 ISC 2.2 84.6 sku
-----------------------------------------------------------------------------
Hjalmtyr Hafsteinsson hh@rhi.hi.is
Department of Computer Science, University of Icelandjcburt@ipsun.larc.nasa.gov (John Burton) (12/08/90)
In article <1990Dec5.210245.10262@agate.berkeley.edu> elm@sprite.Berkeley.EDU (ethan miller) writes: >Two more numbers, for Cray machines running Unicos: >Cray Y-MP (6ns clock): 5.0 >Cray 2 (4.1ns clock): 8.8 > >The entire listing is now: >IBM RS/6000 720 3.5 tif >IBM RS/6000 320 4.4 de5 >Cray Y-MP (Unicos, 6ns clk) 5.0 elm >DECstation 5000/200 6.0 de5 >DECstation 5000/200 (U 4.0) 6.0 neumann >DECsystem 5810 6.2 de5 >Sparcstation 2GX 7.0 dwf >DECsystem 5400 (U 4.0) 7.6 doi >Sun 4/470 (sos 4.1) 8.3 casper >Cray XMP (Unicos) 8.6 de5 >Cray 2 (Unicos, 4.1ns clk) 8.8 elm [...] > >ethan >-- >================================= >ethan miller--cs grad student elm@sprite.berkeley.edu >#include <std/disclaimer.h> {...}!ucbvax!sprite!elm >Witty signature line condemned due to major quake damage. Looks like the IBM RS/6000 is an extremely hot performer, according to these numbers (beats a Cray Y-MP ?). I read a review of the RS/6000 in the Dec. issue of Personal Workstation, which basically said the IBM RS/6000 is a screamer for single task/ single user number crunching applications (which agrees well with the above numbers). For multitask / multiuser applications it appears to be brain damaged, giving results similar to those obtained from 386 based systems. Guess this would indicate the common sense approach to benchmarking... test your system with a process load/mix that is representative of your environment, otherwise you might be unpleasantly surprised. just my 2 cents worth... John (jcburt@cs.wm.edu)
poole@chx400.switch.ch (Simon Poole) (12/08/90)
Just to show that 2 minutes work can make a difference....
Run at the ETH in Zuerich:
Sun 4/490
BSD 4.3 dc, SunOS 4.1 cc -O4
7.7 real 7.6 user 0.0 sys
linked with -Bstatic
7.2 real 7.1 user 0.0 sys
SPARCstation 1+
BSD 4.3 dc, SunOS 4.1 cc -O4
11.5 real 11.1 user 0.1 sys
-Bstatic
10.8 real 10.4 user 0.1 sys
--
------------------------------------------------------------------------
Simon Poole
poole@verw.switch.ch / poole@chx400.switch.ch / mcsun!chx400!poole
------------------------------------------------------------------------jpp@specialix.co.uk (John Pettitt) (12/10/90)
In article <90335.174813NEUMANN@awiwuw11.wu-wien.ac.at> NEUMANN@awiwuw11.wu-wien.ac.at (Gustaf Neumann) writes:
:Here is the updated bc hit-pararde (user time):
:
:IBM RS/6000 720 3.5 tif
:IBM RS/6000 320 4.4 de5
:DECstation 5000/200 6.0 de5
:DECstation 5000/200 (U 4.0) 6.0 neumann
:DECsystem 5810 6.2 de5
ALR 486/25(128K cache) SCO UNIX 6.2
:Sparcstation 2GX 7.0 dwf
:Sun 4/470 (sos 4.1) 8.3 casper
:Cray XMP (Unicos) 8.6 de5
ALR 386/33 SCO UNIX 11.1
It used to be (when all machines were CISC) that you could
walk up to a system and run your favorite `bc' benchmark
(mine was 512^512) and get a result that at least put you
in the right order of magnitude for the machine performance.
As you can see from my 486 result above this does seem to
hold true when you start to put RISC and Vector machines
into the mix.
Oh well, time to find a new `quick test'
--
John Pettitt, Specialix International,
Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781
Disclaimer: Me, say that ? Never, it's a forged posting !valdis@wizards.vt.edu (Valdis Kletnieks) (12/12/90)
In article <1990Dec5.000522.11635@jrd.dec.com>, doi@jrdmax.jrd.dec.com (Hitoshi Doi) writes: |> Some more numbers.. |> Here's a few more numbers: IBM 3090/300 (AIX/370 1.2): real 2.7, user 2.0, sys 0.0 IBM PS/2 mod 80 (20mz, AIX/PS2 1.2): real 1:52.7, user 37.9 sys 0.5 Valdis Kletnieks Computer Systems Engineer Virginia Tech