Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!usc!apple!uokmax!munnari.oz.au!sirius.ucs.adelaide.edu.au!augean!sibyl!ian
From: ian@sibyl.eleceng.ua.OZ (Ian Dall)
Newsgroups: comp.arch
Subject: Re: RISC vs CISC simple load benchmark; amazing ! [Not really]
Message-ID: <675@sibyl.eleceng.ua.OZ>
Date: 13 Jun 90 04:36:58 GMT
References: <8019@mirsa.inria.fr> <39319@mips.mips.COM>
Reply-To: ian@sibyl.OZ (Ian Dall)
Organization: Engineering, Uni of Adelaide, Australia
Lines: 47

In article <39319@mips.mips.COM> mash@mips.COM (John Mashey) writes:
>In article <8019@mirsa.inria.fr> jlf@mirsa.inria.fr (Jean-Louis Faraut) writes:
>>Here is my version of the Joy's program :
>>========================================
>>#!/bin/sh
>>echo 99k65536vvvvvp8op | dc 
>>========================================
>
>Well, unfortunately, there is un unfortunate bug in this benchmark,
>in that the behavior of this program in no way resembles most code
>typically run on general-purpose UNIX sytems, and you absolutely do NOT
>want to use it to help choose computers unless your workload happens to
>be multiple-precisions arithmetic doing lots of ulitplies and divides.

True, and undoubtedly why the sparc faired so badly. What I think is
more interesting is that the 5810 slows down faster than the Vax with
increasing number of processes.

VAX 8650 (8 mips CISC)     Ultrix 1.2 Joy
                user  0.02  0.02  0.05  0.11   0.21   0.48

DEC 5810 (18.7 mips RISC/MIPS)     Ultrix 3.0 Joy
                user  0.01  0.01  0.08  0.10   0.11   0.46

user/VAX              2.00  2.00  0.63  1.10   1.91   1.04 average=1.45

The 1 process case is a reasonable approximation to the ratio of the
rated speeds (especially given the resolution of the measurement). The
32 process case shows the 5810 in a poor light.  Does this have
anything to do with the frequency of multiply instructions or is it a
feature of frequent context switches? Cache flushes maybe?

>Specifically, most RISC designers, after studying many programs, decided
>that integer multiply (and especially divide) were used less frequently
>than many other operations, and there is substantial data that backs this
>up from many vendors.

I can't help thinking that average speed (over an instruction mix) is,
(like most statistics) an inadequate measure. The trouble is, if you have
a multiply intensive application, it is a pain if it runs dramatically
slower than you would expect for a machine of that class. In a sense, one
would like to know the worst case "speed" as well as the "average" speed
of a machine (lots of hand waving here).

-- 
Ian Dall     life (n). A sexually transmitted disease which afflicts
                       some people more severely than others.