HDTenEightyP/NetNews huggingface dataset:
From: stripes@pix.com (Josh Osborne)
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Organization: Pix Technologies -- The company with no adult supervision
Date: Thu, 19 Nov 1992 18:40:44 GMT

In article <37043@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
[...]
>	You need to separate multi-tasking from multi-user.  Single-user
>machines (and this includes most desktop Unix boxes) don't have the activity
>levels for the example you gave to have any relevance.  It's rare that more
>than one or two files are being accessed in any given second or even minute.
>Also, in a single-user environment, average response time becomes the over-
>riding factor over total throughput.

Not true.  Think about a C compiler running on a VM system with a small amount
of RAM.  The swap "file" (or partition) will be accessed quite a bit, and the
source file, and the output file (be it a .s, or .o), and on some systems the
compiler executable.  That's true for both single-user and multi-user systems
(and single-user systems may be under-RAMed more offen...).

[...]
-- 
           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: pic@mlb.dmt.csiro.au (Peter Corke)
Newsgroups: comp.benchmarks
Subject: Wanted: SPECmark ratings for VAX and Sparcstation
Date: 17 Nov 92 22:34:27 GMT
Organization: CSIRO Division of Manufacturing Technology, Melbourne, Australia

I'm interested in comparing the performance of some algorithms reported
in the literature which ran on VAX 11/780 with some results I've gotten on
a SparcStation II.  I need some kind of measure of the machines' relative 
performance, and am considering using some benchmark to assist in assessing 
the relative performance.  The algorithms basically perform symbolic manipulation.

I'm aware of the various arguments about benchmarks and their accuracy, but I
feel this approach should at least give me some qualitative information.
I understand that the SPEC benchmark is somewhat more broad than benchmarks I 
have source of such as Dhrystone and Whetstone, though this may be naive.
I don't want to get into downloading and running the SPEC benchmark myself.

The question:  where can I find a summary of benchmark results for the machines
I mentioned?  


		Peter
-- 
Peter Corke,                           PHONE: +61 3 487-9259
Senior Research Scientist              INTERNET: pic@mlb.dmt.csiro.au
CSIRO Div. Manufacturing Technology    ACSNET or CSNET:pic@mimir.dmt.oz.au
Locked Bag 9, Preston, Australia. 3072 
Newsgroups: comp.benchmarks
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: DEC ALPHA Performance Claims
Organization: Metaflow Technologies Inc.
Date: Thu, 19 Nov 1992 01:35:25 GMT

In article <willmore.722118562@help.cc.iastate.edu>, willmore@iastate.edu (David Willmore) writes:
|> I don't expect that will be much of a problem with the Alpha.  From the way the 
|> archetecture is designed, it looks like the most optimization and ordering takes
|> place on-chip.  The compiler orders things in a fairly general way which the CPU
|> schedules.  I wouldn't say that Alpha eliminates all code ordering problems, but
|> it should be less effected than other archetectures.  At least I hope so.
-- 

Are you sure you're talking about the 21064 implementation of Alpha?  I
believe it's a very vanilla superscalar implementation (kind of an
oxymoron at this point, huh?).  It doesn't do any of that far-out,
register-renaming, out-of-order stuff, as far as I know.  Now, I do
know of another architecture that will do all this stuff, but I don't
want to be too self-serving here...     8-)

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.benchmarks
From: rwirthli@nyx.cs.du.edu (Ralph Wirthlin)
Subject: AIM Suite III Benchmarks
Keywords: benchmarks aim
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Wed, 18 Nov 92 19:18:44 GMT


Hi,
  We are looking for any comments, experiences, etc. with AIM Technologies
AIM Suite III Benchmarking programs.  They claim to be an industry and
government standard.  I just want to verify that.
  What we are looking for is a way to simulate a "typical user" on a 
UNIX system.  This could include things such as spreadsheets, database
usage, email, etc.  Does anyone have any idea where I might find
or pointers on how to create such a benchmark.
  Any help would be greatly appreciated.

                              Thanks,

                              Ralph
From: ifenton@crc.ac.uk (I. Fenton)
Newsgroups: comp.benchmarks
Subject: SPEC : questions, copyright, summary - a database of spec's ?
Date: 16 Nov 92 14:39:48 GMT
Organization: MRC Human Genome Resource Centre

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...

is it legal ?  am i infringing SPEC's copyright ?  

how should i report them ?  i assume that i would include supplementary
info along with each benchmark result, such as cpu (with mhz rating), 
cache size (?), memory (is it relevant?), compiler used?  i assume that
it is necessary to chop the results up into specint92, specfp92, and 
specthruput, (and also spec89marks, if relevant).  i would probably also
separate the multi-cpu from the single-cpu results.

i have read the FAQ pertaining to spec-stuff.  perhaps i am trying to create
a store of spec-marks that could be attached to a FAQ, although this is not
my intention.  it is intented to be stand-alone (!) from a faq.  do you think
anyone from spec would be upset.  and no, i can't be bothered to go and
ask them myself.  any comments welcomed (flame-proof suit on...) mainly be
postings, email also.

thanks...

=============================================================================
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    |
=============================================================================
Xref: sparky comp.benchmarks:1695 comp.arch.storage:775
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: DEC ALPHA Performance Claims
Organization: The Backbone Cabal
Date: Thu, 19 Nov 1992 00:57:10 GMT

In article <1992Nov18.012919.2493@cs.uow.edu.au> pdg@cs.uow.edu.au (Peter Gray) writes:
> 
> Which nicely ties in with my opinion of the "Specmark race"
> which is "who cares?".

There _are_ a fair amount of people who want to run applications that
need more resources than what is currently available.  I have heard
the argument that most people really don't need much more speed since
the 8088 came out.  (6502's worked just fine... :-)  What usually
happens is that new software comes out that can make effective use of
the additional speed, and after using a faster box for only a short
period of time, the old machine no longer seems acceptable.

However, the real reason that IBM, HP and DEC are all frantically
trying to out-do each other in the max SPEC* race is because if you
want to break into a market, you gotta have something unique about
what you are doing and making things faster is easier than making
things dirt cheap.  Also, people who want the fast thing available
will by a box that doesn't have a large install base, but people tend
to not buy new cheap boxes unless there are a lot of people already
using it.  


> 
> Why buy a machine that runs some weird UNIX,

(yes, but SUN is fixing that problem.  they are going to SYSV like the
rest of the world... :-> )


> Why buy a machine that runs some weird UNIX, has less applications
> and costs more than a SUN, even if its twice as fast.
> What we really want is cheap machines. SUN seems very good
> at providing not the fastest but the cheapest and most
> compatible. This seems like a winning strategy to me.
> Its certainly winning here.
> 


well, let me rephrase what you said this way:

| Why buy a machine that runs some weird O/S (instead of DOS/WINDOS),
| has less applications and costs more than a PC, even if its twice as
| fast.  What we really want is cheap machines.  PC's seems very good
| at providing not the fastest but the cheapest and most compatible.
| This seems like a winning strategy to me.
| Its certainly winning most everywhere else.


This I see has the fatal problem with just providing the cheapest unix
boxes around.  You end up having to compete against PC's and that's
hard to do.  


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...)


-wayne
From: clarke@meandyou.Eng.Sun.COM (Kevin Clarke)
Newsgroups: comp.benchmarks
Subject: Re: Who wants faster machines  was  DEC ALPHA Performance Claims
Date: 18 Nov 92 22:09:25 GMT
Reply-To: clarke@meandyou.Eng.Sun.COM
Organization: Sun Microsystems
NNTP-Posting-Host: meandyou

In article 1664@cis.uab.edu, hyatt@cis.uab.edu (Robert Hyatt) writes:
>In article <1992Nov18.162956.2990@ncar.ucar.edu> pack@acd.ucar.edu (Daniel Packman) writes:
>I agree.  Even if I were to stop doing "number crunching" on my workstation,
>I still care about how quickly it can pop up the mailtool, or pop up a
>new window, or run a document thru LaTeX or compile a program.  Once it can
>do any of these (or similar) functions in "zero" time (which could be defined
>as less than .25 seconds) then anything faster wouldn't affect me.  For now,
>SS1 speeds are fair, but not great.  I have an SS2 (40mhz) with a local 400
>meg disk and it is better.  However, as X grows and increases it's function-
>ality more, it will become too slow.  My old Sun 3/50 seemed quite fast
>five years ago.  Now, you can't give 'em away.  In essence, any appreciable
>delay is noticable and anything that can be done to reduce it will have a


	Most of what you find in this domain is that the software is slow.
	Throwing cycles at this problem set is probably a bad answer, although
	it has been the most frequent answer.

	Tune the code and the "mips" will fall out.

	KC
---
+=============================================================================+
| Standard Disclaimer: "To err is human, | clarke@Eng.sun.com		      |
|			to moo bovine."  | {hplabs, ucbvax, decwrl}!sun!clarke|
+=============================================================================+
Newsgroups: comp.benchmarks,comp.arch
From: renglish@cello.hpl.hp.com (Bob English)
Subject: Re: Who wants faster machines  was  DEC ALPHA Performance Claims
Date: Mon, 23 Nov 1992 17:57:56 GMT
Organization: Hewlett Packard Labs

jesup@cbmvax.commodore.com (Randell Jesup) writes:
: 	As I've said before: as soon as you produce more powerful machines,
: operations that were considered "too expensive" now become required.  We
: software people can absorb just about any likely amount of CPU power and
: thirst for more...

Put another way:

New software will be written on new hardware, and tuned based its
performance on new hardware.  Those who attempt to run it on old
hardware will be disappointed.

--bob--
Not a chess grandmaster.
Newsgroups: comp.benchmarks,comp.arch
From: pdg@cs.uow.edu.au (Peter Gray)
Subject: Re: DEC ALPHA Performance Claims
Organization: Dept of Computer Science, Wollongong University, Australia
Date: Wed, 18 Nov 1992 01:29:19 GMT

goykhman_a@apollo.hp.com (Alex Goykhman) writes:
>    I have the numbers in front of me, but I am not sure I can post them
>    to the net.  Speaking of specmarks, DEC's high-end (200Mhz) appears to be 
>    ~25% faster than that of HP's.  Not exactly an earth-shattering event, 
>    especially considering that DEC did not release graphics-related 
>    performance benchmarks for ALPHA...  In a word, I expected more from ALPHA.

>    That said, SUN has the slowest workstations on the market, yet they ship
>    more boxes than either of the above.


Which nicely ties in with my opinion of the "Specmark race"
which is "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. If DEC/HP/IBM are spending large amounts of money
developing faster desktop machines they are not serving
the needs of the company, profit. They should be aiming at
increased sales by targeting the biggest market. There are
people who want/need speed but there's not many. How many
banks need 100 Mips on peoples desktops?

Why buy a machine that runs some weird UNIX, has less applications
and costs more than a SUN, even if its twice as fast.
What we really want is cheap machines. SUN seems very good
at providing not the fastest but the cheapest and most
compatible. This seems like a winning strategy to me.
Its certainly winning here.

pdg

Peter Gray                    Internet: pdg@cs.uow.EDU.AU
Professional Officer          UUCP:     ...!munnari!cs.uow.EDU.AU!pdg  
Dept of Computer Science      MHSnet:   pdg@cs.uow.oz.au
University of Wollongong      Phone: +61 42 213770                       
N.S.W.  2500  Australia       Fax :  +61 42 213262
Organization: Middle East Technical University - Computer Center
Date: Tuesday, 17 Nov 1992 14:46:05 TUR
From: <E59393@TRMETU.BITNET>
Newsgroups: comp.benchmarks
Subject:    Performance Evoluation of Parallel Computers

Hi,
 I am currently working on Performance Evoluation of Parallel Comp. If you have
 some material concerning to this topic please e-mail it to me . Are there any
ftp sites having material on this topic. Please write their addresses to me
if you happen to know. Any kind of help is appreciated.Thanks in advance
                                                       Dogan Cibiceli
E-mail : E59393 at TRMETU.BITNET
Newsgroups: comp.benchmarks
From: pd@sei.cmu.edu (Patrick Donohoe)
Subject: Hartstone Benchmark, version 1.1
Organization: Software Engineering Institute
Date: Thu, 19 Nov 1992 17:01:37 GMT

                   The Hartstone Benchmark, Version 1.1
                   ====================================

   The Hartstone benchmark is a set of timing requirements for testing a
   system's ability to handle hard real-time applications.  It is specified
   as a set of processes with well-defined workloads and timing constraints.
   The name Hartstone derives from HArd Real Time and the fact that the work-
   loads are based on the well-known Whetstone benchmark.  "Hard" real-time
   applications must meet their deadlines to satisfy system requirements;
   this contrasts with "soft" real-time applications where a statistical
   distribution of response times is acceptable.

   Five test series, of increasing complexity, have been proposed for Hart-
   stone and the first of these, the Periodic Harmonic (PH) series, has been
   implemented in the Ada programming language at the Software Engineering
   Institute (SEI).  Known as version 1.0 of Hartstone, it has been available
   publicly for the past two years.  Version 1.1 of the benchmark is now
   available.  This new version corrects some minor errors in the 1.0 release.
   It has also been restructured to enable users to use a debugger as an inter-
   active interface for preliminary tuning of Hartstone parameters and for
   performing multiple Hartstone experiments.  This eliminates the need for
   repeated compile-link-download cycles when tuning and running Hartstone.
   It also facilitates experimentation with non-harmonic task sets, i.e. the
   Periodic Non-Harmonic (PH) test series.

   Electronic mail requests for Hartstone should be sent to the following
   Internet address:

                        hartstone-info@sei.cmu.edu

   For people without Internet access, the address to send requests to is:

                        REST Transition Services
                        Software Engineering Institute
                        Carnegie Mellon University
                        Pittsburgh, PA 15213-3890
                        Phone: (412) 268-7787

   Hartstone source code may also be retrieved from the PIWG bulletin board at

                             (412) 268-7020



Patrick Donohoe,  Software Engineering Institute,    pd@sei.cmu.edu
Carnegie Mellon University, Pittsburgh, PA 15213.    (412) 268-7616
Newsgroups: comp.benchmarks,comp.arch
From: hyatt@cis.uab.edu (Robert Hyatt)
Subject: Re: Who wants faster machines  was  DEC ALPHA Performance Claims
Organization: University of Alabama at Birmingham
Date: Wed, 18 Nov 1992 17:53:49 GMT

In article <1992Nov18.162956.2990@ncar.ucar.edu> pack@acd.ucar.edu (Daniel Packman) writes:
>In article <1992Nov18.012919.2493@cs.uow.edu.au> pdg@cs.uow.edu.au (Peter Gray) writes:
>>
>>Which nicely ties in with my opinion of the "Specmark race"
>>which is "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?
>>
>
>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, 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.
>
>
>

I agree.  Even if I were to stop doing "number crunching" on my workstation,
I still care about how quickly it can pop up the mailtool, or pop up a
new window, or run a document thru LaTeX or compile a program.  Once it can
do any of these (or similar) functions in "zero" time (which could be defined
as less than .25 seconds) then anything faster wouldn't affect me.  For now,
SS1 speeds are fair, but not great.  I have an SS2 (40mhz) with a local 400
meg disk and it is better.  However, as X grows and increases it's function-
ality more, it will become too slow.  My old Sun 3/50 seemed quite fast
five years ago.  Now, you can't give 'em away.  In essence, any appreciable
delay is noticable and anything that can be done to reduce it will have a
BIG market.  When you start cracking .1 sec intervals, then you really are
talking to the true number crunchers and not the majority of workstation
users.  But there are still Cray's for 'em ........

Bob

-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
Xref: sparky comp.benchmarks:1720 comp.arch:10850
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.benchmarks,comp.arch
Subject: Re: DEC ALPHA Performance Claims
Keywords: compilers, Alpha
Date: 17 Nov 92 00:49:25 GMT
Followup-To: comp.benchmarks
Organization: Digital Equipment Corporation

In article <4248@bcstec.ca.boeing.com>, silverm@bcstec.ca.boeing.com (Jeff Silverman) writes...
> [text deleted]
>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.

Ada is in field test.  Third party compilers are underway, on both VMS
and OSF/1.

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation
From: moss@cs.cmu.edu (Eliot Moss)
Newsgroups: comp.benchmarks
Subject: Re: DEC ALPHA Performance Claims
Date: 17 Nov 92 13:59:51 GMT
Article-I.D.: CRAFTY.MOSS.92Nov17085951
Reply-To: moss@cs.cmu.edu
Followup-To: comp.benchmarks
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)

>>>>> On 16 Nov 92 06:36:50 GMT, silverm@bcstec.ca.boeing.com (Jeff Silverman)
>>>>> said:

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

I disagree. This is not new to the Alpha, but came into its own with RISC
chips, and was really there in some ways all along. Instruction scheduling and
register allocation (and good compilers in general) are very important in
obtaining good performance from modern processors. What may be new in the last
ten years or so is the extent to which the hardware designers are now relying
on good software to use the hardware to best advantage, rather than simply
looking at static and dynamic instruction usage distributions to see what
should be sped up more, etc.
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu
Newsgroups: comp.benchmarks