HDTenEightyP/NetNews huggingface dataset:
From: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
Subject: [l/m 3/17/92] WPI Benchmark Suite (1.1)	(19/28) c.be.FAQ
Keywords: who, what, where, when, why, how
Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
Date: Thu, 19 Nov 92 12:25:15 GMT
Reply-To: mach@cs.wpi.edu

19 	WPI Benchmark 					<This panel>
20	Equivalence
21	TPC
22
23
24
25	Ridiculously short benchmarks
26	Other miscellaneous benchmarks
27
28	References
1	Introduction to the FAQ chain and netiquette
2	Benchmarking concepts
3	PERFECT Club/Suite
4
5	Performance Metrics
6
7	Music to benchmark by
8	Benchmark types
9	Linpack
10
11	NIST source and .orgs
12	Benchmark Environments
13	SLALOM
14
15	12 Ways to Fool the Masses with Benchmarks
16	SPEC
17	Benchmark invalidation methods
18

The WPI Benchmark Suite, version 1.1, is now available for download
via anonymous ftp.  The WPI Benchmark Suite, developed with the support
of the Research Institute of the Open Software Foundation, is a series
of programs designed to investigate operating system performance of Unix
and Unix-like operating systems.  We have used the Benchmark Suite
extensively to study the performance of various versions of the Mach
operating system.

The Benchmark Suite consists of six programs, each of which is designed
to mimic the operating system resource usage of a user application.
Each program can be run independently, and reports the execution time
for the measured portion of the benchmark, as well as other resource
usage.

The programs are in the public domain, and may be downloaded via
anonymous ftp from wpi.wpi.edu (130.215.24.1) in the "/benchmarks"
directory.  Get the file WPI_Benchmark_Suite_1.1.readme and either
BenchmarkSuite1.1.tar.Z or BenchmarkSuite1.1.lzh.

In addition to the benchmarks, there are two technical reports available
on-line, describing the benchmarks and giving some sample results of
running them.  The technical reports are in the files benchmarks_tr1.ps
and benchmarks_tr2.ps.  The files are in PostScript format.

If ftp is not available at your site, please send a message requesting
the Suite by e-mail. This is a much slower process, so please ftp the 
benchmarks if you can.

If you download the benchmarks, please send mail to mach@cs.wpi.edu
to have your named placed on our mailing list for information about
future releases.  In addition, we are interested in your comments
about the benchmarks and in hearing about your experiences in using
them.


 Mach Research Group
 Computer Science Department                Internet:  mach@cs.wpi.edu
 Worcester Polytechnic Institute            Telephone: (508) 831-5357
 Worcester, MA 01609 USA                    FAX:       (508) 831-5776 

                   ^ A  
                s / \ r                
               m /   \ c              
              h /     \ h            
             t /       \ i          
            i /         \ t        
           r /           \ e      
          o /             \ c    
         g /               \ t  
        l /                 \ u
       A /                   \ r
        <_____________________> e   
                Language
 
Xref: sparky comp.benchmarks:1739 comp.arch:10926
From: borasky@ogicse.ogi.edu (M. Edward Borasky)
Newsgroups: comp.benchmarks,comp.arch
Subject: Re: Who wants faster machines
Date: 19 Nov 92 18:54:54 GMT
Article-I.D.: ogicse.46144
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

In article <1992Nov18.162956.2990@ncar.ucar.edu> pack@acd.ucar.edu (Daniel Packman) writes:
>...  For us, however, we find present algorithms still
>limited by the speed of processors available.  With faster machines,
>still more complex calculations become possible.  I cannot forsee a
>faster machine that will be perceived by scientific institutions as
>irrelevant.
1. Although we are limited by processor speed, we are even more limited
   by the algorithms.  A graph of speed in weather prediction as a function
   of time shows much more impressive jumps when better algorithms were
   debugged and adopted than you see when older algorithms were moved to
   faster computers.

2. Although we cannot forsee faster machines that are irrelevant, we
   can EASILY forsee fast machiens that are irrelevant because of the
   cost of their hardware, operating systems, compilers and application
   codes.
Newsgroups: comp.benchmarks
From: dennisk@aplcenmp.apl.jhu.edu (Dennis M. Kavanagh)
Subject: Performance Analyzers for RS6000??
Organization: Johns Hopkins Continuing Professional Programs
Date: Fri, 20 Nov 1992 22:30:43 GMT


Does anyone have suggestions for Performance Analyzers running under RS6000??
I will summarize if warranted by number/quality of inputs...
Thank you...

Xref: sparky comp.benchmarks:1710 comp.arch.storage:781
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: DEC ALPHA Performance Claims
Organization: Digital Equipment Corporation
Date: 16 NOV 92 12:51:33    


In article <4248@bcstec.ca.boeing.com>, silverm@bcstec.ca.boeing.com (Jeff Silverman) writes...
> 
>1) Newer implementations of the alpha may need or take advantage of new ways
>of ordering instructions.  This in turn means that different alpha 
>implementations may need or take advantage of different executables or object
>modules, each compiled for its own processor.  Or maybe the processors will
>take a performance hit in the name of portability.  Who can say?
> 
Optimal instruction scheduling for newer processors may indeed be different.
Old binaries will run correctly, but probably somewhat slower. New binaries
should in most cases run well on old machines, unless the scheduling rules
are at odds. This phenomenon is not unique to Alpha or even RISC. The same
holds true even for the x86, where existing binaries are not optimal for the
Pentium.

/d
From: wjs@re3sc139h.gmr.com
Newsgroups: comp.benchmarks
Subject: REQ: SPEC Ratings for TI 320C40 Chip
Date: 18 Nov 92 13:42:32 GMT
Distribution: usa
Organization: GM/EDS Research Labs.

Does anyone have any SPEC rating information for the Texas Inst.
320C40 chip ?  Actually, any benchmark data would be appreciated.

Please respond by direct email.

	   Thanks in advance !

	   Walt Stuart   wjs@re3sc139h.gmr.com

	   GM/EDS Research Labs
	   Warren, Mi
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.benchmarks
Subject: Re: DEC ALPHA Performance Claims
Date: 22 Nov 92 00:16:30 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

silverm@bcstec.ca.boeing.com (Jeff Silverman) writes:
>A lot of them are number crunchers, and they work in FORTRAN.  Why FORTRAN?
>Because it's fast (FORTRAN tends to be faster than C because you don't have
>to build argument lists on the stack - whether this is important or not,
>I'm not sure - I like to program in "C").

	A minor point: using C doesn't mean that your arguments have to be on
the stack.  With ANSI C and use of prototypes, a compiler can automatically
registerize your parameters (and a nice hefty speed boost this gives, too),
even on architectures like the 680x0, where you have address and data
registers.  On most RISC's it should be even easier, and prototypes might
not be required except in the case of varargs functions.

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Xref: sparky comp.benchmarks:1703 comp.arch:10788
From: silverm@bcstec.ca.boeing.com (Jeff Silverman)
Newsgroups: comp.benchmarks,comp.arch
Subject: Re: DEC ALPHA Performance Claims
Date: 16 Nov 92 06:36:50 GMT
Followup-To: comp.benchmarks
Organization: Boeing Computer Services, Seattle

There is a lot of discussion on this thread about hardware vs. software speed
up.  I suspect that the question is moot.  One of the features, attributes, 
whatever of the Alpha is that the compiler is supposed to sort instructions
so that the hardware pipeline works optimally.  This means that, for all
intents and purposes, the compiler and the CPU are closely coupled in a
new and unique way.  It also has some rather interesting side effects:

1) Newer implementations of the alpha may need or take advantage of new ways
of ordering instructions.  This in turn means that different alpha 
implementations may need or take advantage of different executables or object
modules, each compiled for its own processor.  Or maybe the processors will
take a performance hit in the name of portability.  Who can say?

2) It will be interesting to see if third party vendors come out with language
processors (I.e. compilers) for the Alpha, if the compiler and the CPUs are
so intimately familiar with one another.

I don't know enough about the Alpha to answer these questions - and it may
be the case that the questions won't be answerable until somebody tries.
One test will be to measure how long it takes for somebody to announce an
Ada for the Alpha.  We'll see.

Jeff Silverman, Boeing.

Newsgroups: comp.benchmarks
From: gof@casbah.acns.nwu.edu (Gerald Fountain)
Subject: Re: SPEC : questions, copyright, summary - a database of spec's ?
Organization: Northwestern University, Evanston Illinois.
Date: Tue, 17 Nov 1992 19:16:10 GMT

In article <1992Nov16.143948.27382@crc.ac.uk> ifenton@crc.ac.uk (I. Fenton) writes:
>i have been reading this group for a while now, and am interested in most
>benchmarks (i like a good laugh <grin>), and inparticular the supposedly
>independent ones such as SPEC and TPC-x (x=A,B, etc).  so, maybe i am
>sticking my neck out, but here goes...
>
>i would like to complie a list of all (!) SPECmark ratings, both INT & FP,
>even THRUput, if possible.  basically i would like to be able to produce a 
>list that i could post every-so-often when a new spec-mark for a new machine
>appears.  this would be of interest when the dec-alpha marks came out, to
>give an example.  this however, raises a coupla questions...
>

This sounds great.  I think this would be a great idea.  I would vote that you
include the component scores in the SPEC ratings as well.  They sometimes show
some interesting features (HP 700 series has *very* high MATRIX operations it
would seem!).



>=============================================================================
>IAIN FENTON                             | All errors of spelling, grammar &
>Institute of Medical Genetics           | fact are due to a missing <Del> key
>University of Wales College of Medicine |====================================
>Heath Park                              | "No man should marry until he has
>Cardiff  CF4 4XN                        |  studied anatomy and dissected at
>U.K.                                    |  least one woman" - de Balzac
>=============================================================================
>Voice = +44 - 222 - 744049   | In 1912, Jack Johnson, the first black world
>Fax   = +44 - 222 - 747603   | heavyweight boxing champion, was refused
>Email = fenton@uk.ac.cardiff | permission to board the Titanic because of
>   (or) wmgif@uk.ac.cardiff  | his colour.
>   (or) ifenton@uk.ac.crc    |
>=============================================================================
>


-- 
Jerry Fountain                       
Northwestern University                        gof@stokes.chem-eng.nwu.edu
Department of Chemical Engineering             (708) 491-3555 (Office)
2145 Sheridan Road, Evanston, IL  60208        (708) 491-3728 (FAX)
Newsgroups: comp.benchmarks,comp.arch.storage
From: milton@teal.csn.org (Milton Scritsmier)
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Organization: Colorado SuperNet, Inc.
Date: Thu, 19 Nov 1992 07:03:56 GMT

In article <sc77t04@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>
>John, you ignore the fact that almost all decent SCSI drives these
>days do remapping by sector slipping.  Thus you have at most a single
>sector time cost for remapped blocks.  Yes, some of the older drives
>remapped blocks to the end of the drive, but this is very rare
>these days.  The overhead in the embedded drive controller is pretty
>minimal for the lookup, although not non-existent.

In its current drives, HP remaps entire tracks, even for one sector
errors (each zone has a certain number of spare tracks). This was
a conscious design choice made after studying various methods. Some
of the reasons they gave were that media errors often overlap sector
boundaries, and that many disk operations often do not cross track
boundaries. In addition, head switching times to get to a slipped
sector pushed onto another track or to a spare at the end of a cylinder
often are several milliseconds. This is a significant fraction of a
seek, especially if you have to switch back to the original track to
pick up more data vs. seeking to a track where all the data is.

No doubt sector slipping gives the best overall performance in general,
but with today's emphasis on capacity as well as performane, sector
slipping wastes too much media. In addition, the media has improved
to the point where a hundred errors on a 1 gig disk is high. 


Newsgroups: comp.benchmarks,comp.arch
From: hart@waterloo.hp.com (Tony Hart)
Subject: Re: DEC ALPHA Performance Claims
Date: Fri, 20 Nov 1992 02:37:38 GMT
Organization: HP Panacom Div Waterloo ON Canada
X-Newsreader: TIN [version 1.1.4 PL6]

Wayne Schlitt (wayne@backbone.uucp) wrote:
: Finally, I would like to point out that HP _is_ trying to compete at
: the very low end like SUN is.  They are tending to push X-terminals as
: the cheapest platform for those users that want snappy windows/graphics,
: but really don't use much cpu power.  (I am not sure if they are being
: that successful at it, but...)

Apparently DEC thinks so - they've publicly admitted that they hope to copy
HP's strategy. :-)

Reference: _Electronic_News_, 11/9/92, pg 14., "DEC to Emulate HP RISC/X 
Terminal Tactic"

Tony Hart,
Panacom Automation Division,
Hewlett-Packard (Canada) Ltd.

Standard Disclaimer:
All opinions expressed are my own and do not represent an official statement of
the Hewlett-Packard Company.
Xref: sparky comp.benchmarks:1766 comp.arch:11034
From: bds@mbunix.mitre.org (Smith)
Newsgroups: comp.benchmarks,comp.arch
Subject: Re: Who wants faster machines?
Date: 23 Nov 92 19:03:12 GMT
Organization: The MITRE Corporation, Bedford, MA

In article <1992Nov19.220352.15000@nas.nasa.gov> eugene@wilbur.nas.nasa.gov (Eugene N. Miya) writes:
>>In article <1992Nov18.012919.2493@cs.uow.edu.au> pdg@cs.uow.edu.au
>(Peter Gray) writes:
>>>"who cares?". At our site we have ~100 SUN's.
>>>No HP, no DEC, no RS6000. How many of our SUN users want
>>>a faster machine? About 2. For the rest 10 Mips (SS1 type speed)
>>>is plenty....  How many banks need 100 Mips on peoples desktops?
>
>This is a joke right?
>You don't happen to be relatives of the engineers who told John Watson
>that there wasn't a market for computers?
>Should we stop all work on "Grand Challenge problems?"
>I know John McCarthy posted that it is foolish to do research on turbulence.


Sometimes people simply miss the point.  Perhaps it's a cultural
thing, I don't know.  I've been involved with groups who were never
happy with the performance of their computers, regardless whether or
not their machines got the job done.  I've also been involved with
groups who saw computers as simply tools to solve a problem.  In an
application like word processing, where the machine sits quietly in a
wait state most of the time, there is little reason for a 150 MIP
chip.  I know of a system where a 6 MIP box is clearly underutilized,
yet there is a proposal to replace it with an Alpha box.

At the other end of the spectrum are those problems that would take
supercomputers years to solve, and here the need for more performance
is paramount.  But in the grand scheme of things, these problems are
fairly rare.  

IBM-PCs and Macs are great machines, not because they can outrun a
Cray (or an Alpha, or a PA-RISC) but because they provide the solution
to a need.  We've all heard the story of how Apple used a Cray to
design the Mac, while Cray used a Mac to design their machines.


Barry Smith
Newsgroups: comp.benchmarks,comp.arch.storage
From: wolff@zen.et.tudelft.nl (Rogier Wolff)
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Sun, 15 Nov 1992 23:48:41 GMT

jbass@igor.tamri.com (John Bass) writes:

>Caching all writes is also highly productive ... editor writes out
>C source, to be read by C compiler which writes object module read
>by linker which writes the executable to read by system loader when
>the user tests. The cycle repeats, deleting ALL files created by the
>cycle .... if you hold the I/O long enough ... it really isn't I/O
>after all.

I was looking at the Linux sources a few days ago, and found that 
indeed if a file is deleted before it's blocks are written to disk,
the blocks in the buffer are "un-dirtied", and thus never written
to disk. 

This in contrast to DOS where the hyperdisk disk-cache program
doesn't have the knowledge that the OS has: I can copy about 1Mb 
of data to floppy, and delete them well before hyperdisk finishes
writing the data to the floppy. All data gets written unnecessarily
to the disk.

Anyway, it takes a well written OS to actually benefit from this.


					Roger.
-- 
****   a 486 in V86 mode is like a VW buggy with a 6 litre V12 motor.  ****
EMail:  wolff@duteca.et.tudelft.nl   ** Tel  +31-15-783644 or +31-15-142371
Newsgroups: comp.benchmarks
From: stripes@pix.com (Josh Osborne)
Subject: Re: DEC ALPHA Performance Claims
Organization: Pix Technologies -- The company with no adult supervision
Date: Tue, 17 Nov 1992 03:38:54 GMT

In article <4248@bcstec.ca.boeing.com> silverm@bcstec.ca.boeing.com (Jeff Silverman) writes:
[...]
>1) Newer implementations of the alpha may need or take advantage of new ways
>of ordering instructions.  This in turn means that different alpha 
>implementations may need or take advantage of different executables or object
>modules, each compiled for its own processor.  Or maybe the processors will
>take a performance hit in the name of portability.  Who can say?

That's not true of only the Alpha ('tho thay may make no atttempt to lessen
the blow).  One way to solve this problem is to use something like OSF's
ANDF.  I don't know if it is a good way (it has lots of other advantages and
disadvantages), but it should work.
[...]
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
From: vb@hpfcso.FC.HP.COM (John Van Boxtel)
Date: Fri, 20 Nov 1992 23:55:51 GMT
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.benchmarks

In comp.benchmarks, olson@anchor.esd.sgi.com (Dave Olson) writes:

> In <BxyBML.2pq@csn.org> milton@teal.csn.org (Milton Scritsmier) writes:
> | In its current drives, HP remaps entire tracks, even for one sector
> | errors (each zone has a certain number of spare tracks). This was
> 
> That was not a great decision, if true.  I've not chased down
> just how HP does their bad block handling, as we haven't done
> serious eval of their drive (politics as much as anything else,
> even if it is a different division of HP from the workstations).

HP choose the track sparing technique because HP believes it is
a superior technique.  Perhaps SGI's OEM drive selection was a bad decision :-)

> 
> | a conscious design choice made after studying various methods. Some
> | of the reasons they gave were that media errors often overlap sector
> | boundaries, and that many disk operations often do not cross track
> | boundaries. In addition, head switching times to get to a slipped
> 
> Sector slipping means that there *is* no head switch time, by definition
> (unless the sector slipped was the last one on the track, which is
> relatively rare).

It is unclear whether you are talking about slip sector per track
or per cylinder.  Slip sector per track is worse for capacity and
sequential performance.  Slip sector per cylinder requires a complex
analysis to see the advantages and disadvantages.  Which kind of slip
sector are you talking about?

> 
> | sector pushed onto another track or to a spare at the end of a cylinder
> | often are several milliseconds. This is a significant fraction of a
> | seek, especially if you have to switch back to the original track to
> | pick up more data vs. seeking to a track where all the data is.
> 
> Additionally, almost all SCSI drives offset sector numbers from
> track to track to allow for the head switch time.  There is
> still the latency issue, but at least you don't miss a rev.

It is because of skewing that slip sector (per track or cylinder) costs
sequential performance.

> 
> You *never* have to switch back to the original track if you
> sector slip.
> 
> | No doubt sector slipping gives the best overall performance in general,
> | but with today's emphasis on capacity as well as performane, sector
> | slipping wastes too much media. In addition, the media has improved
> | to the point where a hundred errors on a 1 gig disk is high. 
> 
> You obviously don't understand sector wlipping.  It wastes no
> media at all.  100 errors on a 1GB disk is not at all uncommon.

Perhaps you can further explain this comment.  Why is it that sector
slipping does not waste any space?

          John A. Van Boxtel    vb@fc.hp.com
          Member of Technical Staff
          Workstation System Group
          Hewlett Packard

P.S  I did HP disk drives in a previous life.
Newsgroups: comp.benchmarks,comp.arch
From: eugene@wilbur.nas.nasa.gov (Eugene N. Miya)
Subject: Re: Who wants faster machines?
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Thu, 19 Nov 92 22:03:52 GMT

>In article <1992Nov18.012919.2493@cs.uow.edu.au> pdg@cs.uow.edu.au
(Peter Gray) writes:
>>"who cares?". At our site we have ~100 SUN's.
>>No HP, no DEC, no RS6000. How many of our SUN users want
>>a faster machine? About 2. For the rest 10 Mips (SS1 type speed)
>>is plenty....  How many banks need 100 Mips on peoples desktops?

This is a joke right?
You don't happen to be relatives of the engineers who told John Watson
that there wasn't a market for computers?
Should we stop all work on "Grand Challenge problems?"
I know John McCarthy posted that it is foolish to do research on turbulence.
Do you mean we should tell people to stop doing things like modeling
the AIDS virus?  Slower machines are enough?  Or the 23 other kinds of
modelling and analysis problems......

This person is a CS major?  Faculty?  Boy have we got problems.
To answer the number of banks: a lot, I had a discussion of econometric
modelling at the Hackers Conference with Jordan Hayes who works for a
brokerage firm, now.  They take their computing seriously.  It's a foolish
bank who does not take their computing seriously these days.

Confusing.....

In article <1992Nov18.162956.2990@ncar.ucar.edu> pack@acd.ucar.edu
(Daniel Packman) writes:
>As has been said, who cares if the payroll program that runs overnight
>takes 8 hours or 8 minutes?  Indeed, in certain situations speed is
>not that important.  For us,

--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Associate Editor, Software and Publication Reviews
  Scientific Programming
  {uunet,mailrus,other gateways}!ames!eugene
Seeking Books to buy:	Bongard, Pattern Recognition
			3 down 1 to go.
Newsgroups: comp.benchmarks,comp.arch.storage