HDTenEightyP/NetNews huggingface dataset:
From: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
Subject: [l/m 4/9/92] SLALOM				(13/28) c.be FAQ
Keywords: who, what, where, when, why, how
Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
Date: Mon, 12 Oct 92 11:25:16 GMT
Reply-To: eugene@amelia.nas.nasa.gov (Eugene N. Miya)

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

%A J. Gustafson
%A D. Rover
%A S. Elbert
%A M. Carter
%T SLALOM: The First Scalable Supercomputer Benchmark
%J Supercomputing Review
%D November 1990
%P 56-61

%A John Gustafson
%A Diane Rover
%A Stephen Elbert
%A Michael Carter
%T The Design of a Scalable, Fixed-Time Computer Benchmark
%R IS-5049/UC-32
%I Ames Lab, Iowa State University
%D 1990

And other sources.

Archive-directory: tantalus.al.iastate.edu:/pub/Slalom/ [129.186.200.15]
Tantalus.al.iastate.edu has the SLALOM sources in various languages and other
things including the latest reported results in
pub/Slalom/Reports/CurrentReport.

                   ^ A  
                s / \ r                
               m /   \ c              
              h /     \ h            
             t /       \ i          
            i /         \ t        
           r /           \ e      
          o /             \ c    
         g /               \ t  
        l /                 \ u
       A /                   \ r
        <_____________________> e   
                Language
From: jwreilly@mipos2.intel.com (Jeffrey Reilly)
Newsgroups: comp.benchmarks
Subject: Re: SPEC92 Results for 386/33MHz
Date: 16 Oct 92 15:12:49 GMT
Organization: Intel Corporation, Santa Clara, CA USA

In article <Oct14.221316.24261@yuma.ACNS.ColoState.EDU> shafer@CS.ColoState.EDU (spencer shafer) writes:
>Has anyone seen the SPECfp92 and SPECint92 results for a 
>386/33MHz platform?  Would like to know just for sense of
>relation to previous SPEC suite results.
>
From tests run by Intel:

33MHz Intel386 DX CPU
64KB Write Back Cache
8 MB RAM
Using SVR4.0, Metaware 2.4b and Absoft3.1.4

SPECint92 = 8.35
SPECfp92 = 3.0

Jeff

Jeff Reilly			Performance Benchmarking And Analysis
jwreilly@mipos2.intel.com	Intel Corporation
(408) 765 - 5909		Santa Clara, California
From: jwreilly@mipos2.intel.com (Jeffrey Reilly)
Newsgroups: comp.benchmarks
Subject: Re: SPEC (was Re: wanted: benchmark results for DEC alpha)
Summary: SPEC
Date: 13 Oct 92 15:59:26 GMT
Organization: Intel Corporation, Santa Clara, CA USA

In article <1992Oct12.194333.5676@ornl.gov> de5@ORNL.GOV (Dave Sill) writes:
>In article <1992Oct12.175359.18023@odin.corp.sgi.com>, mash@mash.wpd.sgi.com (John R. Mashey) writes:
>>
>>7) From past experience & simulation, we know that changing R4000 scache
>>from 256KB to 1MB makes little (5%?) difference on SPEC; however, we think
>>it makes a noticable difference for a lot of real applications, which spend
>>more time inside the OS, doing context-switching, I/O, etc.
>
>This challenges SPEC's claim that the SPEC Suites consist of real applications,
>or at least implies that the "real applications" in the SPEC Suites aren't real
>enough.  Certainly, no matter how many and varied the SPEC applications are,
>there will be plenty of applications with widely different performance
>characteristics.  I thought the intent of the SPEC suites was to choose real,
>large benchmarks that would, on average, represent the average application
>pretty closely.  You seem to be saying they haven't succeeded.

I believe that the distinction between "real" CPU-intensive applications (spice,
gcc, etc) and "real" system intensive applications (SPEC SDM, databease, etc) is
probably what was being mentioned here.

SPEC's goal is to use application-oriented tests. And, of course, "average" and
"real" are always words subject to interpretation. (Though I wouldn't necessarily
include "large" as a criteria.)

>>BOTTOM LINE: whenever anyone publishes SPEC numbers, do a careful comparison
>>across the board, not just on the mean numbers, to get some diea of what's
>>going on.  In particular, always watch out for "peaks", like what happened
>>to SPEC89's matrix300 (although perhaps not so extreme).
>>However, *expect* that performance ratios on individual benchmarks
>>will vary widely among these machines, and that if you pick your benchmarks,
>>you'll probably be able to prove superiority of anything you like,
>>among machines whose means are similar. 
>Good advice.

Amen

Jeff
SPEC CINT92/CFP92 Release Manager

Jeff Reilly			| "There is something fascinating about
Intel Corporation		| science. One gets such wholesale returns
jwreilly@mipos2.intel.com	| of conjecture out of such a trifling
(408) 765 - 5909		| investment of fact" - M. Twain
Newsgroups: comp.benchmarks
From: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
Subject: [l/m 3/23/92] Linpack				c.be FAQ
Keywords: who, what, where, when, why, how
Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
Date: Fri, 9 Oct 92 11:25:08 GMT
Reply-To: eugene@amelia.nas.nasa.gov (Eugene N. Miya)

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

The LINPACK benchmark is a very simple LU decomposition of a dense linear
system (Gaussian elimination) by Jack Dongarra the developer of the
LINPACK library and the netlib numerical software server.

Ref: Dongarra's article in CACM on Netlib.
And ACM SIGARCH Computer Architecture News and SIGNUM Newsletter.

Advantages:
Simple fairly portable FORTRAN.  One of the shorter benchamrks.
It is small enough to be carried on disk or in Jack's laptop without
consuming too much porting time.
A good attempt at experiment control, has stringent execution requirements.

Dongarra also records the compiler options used to invoke the Fortran
compilers.  Record keeping is good.  Reports are quickly available
electronically and published with some frequency in Supercomputing Review.

Disadvantages:
Diminishing parallelism during the decomposition (as in all Gaussian
elimination).  It is perhaps too simple.  Execution time is on the shorter
side.  It cannot characterize less numeric applications.

NETLIB benchmark index (Linpack benchmark)
netlib@ornl.gov
	send index from benchmark
includes linpack (100x100,300x300,1000x1000).

What is interesting about these sizes is that they are not
the powers of 2 which characterize many benchmarks.  Powers of 2
can bias in favor of some architectures and bias against other
architectures.

                   ^ A  
                s / \ r                
               m /   \ c              
              h /     \ h            
             t /       \ i          
            i /         \ t        
           r /           \ e      
          o /             \ c    
         g /               \ t  
        l /                 \ u
       A /                   \ r
        <_____________________> e   
                Language
 
Newsgroups: comp.benchmarks
From: chuck@ernest.mit.edu (Chuck Parsons)
Subject: Re: wanted: benchmark results for DEC alpha
News-Software: VAX/VMS VNEWS 1.4-b1  
Keywords: Dec alpha
Organization: MIT Lab for Nuclear Science
Date: Mon, 12 Oct 1992 01:39:00 GMT

In article <1992Oct9.013429.29995@e2big.mko.dec.com>, pettengill@cvg.enet.dec.com ()       writes...
> 
>In article <1992Oct8.091026.9013@nntp.nta.no>, justin@scs.leeds.ac.uk (J M Ware) writes:
> 
>|>I'm looking for any pointers on where to find benchmark results for the new DEC
>|>wonder-chip 'alpha'.  Preferably ones done by someone other than DEC.  I have
>|>been quoted by someone that the new DEC alpha performed his Finite Element Code
>|>14 times faster than his DEC5000/200 -- is this likely?
> 
>I have no idea how one would benchmark a chip against a system.  Would you care to
>explain your methodology?  You can buy the 21064 chip today and do the benchmarks
>yourself.  ;-)
> 
>If we consider the DEC 5000 Model 200 to be a 20 somethingmark machine (I don't know
>the SPECmark (tm) for that system), then this would put that system into the 280 xmark
>class; that is not a reasonable number for the first machines to be announced.
>But I wouldn't be surprised that it is possible to build a system using the 21064
>that does perform at that level, assuming that you have lots of money or are willing
>to limit the scope of the system to the chip cache.  (It's possible to load the cache
>and begin executing code without any memory system; see the chip spec for details.) 
> 
>If you are interested in benchmarking an Alpha AXP (tm) system, that can be arranged for
>certain applications, the primary restriction at this time being that the source code
>be FORTRAN.  Sufficient testing has been completed with FORTRAN to believe that the
>results of such benchmark realistically reflect the performance of the released system,
>which includes hardware and software.  I would assume that the above code is written in
>FORTRAN, so that the figure cited by the `someone' is probably reasonable.  Of course,
>what is missing is the information on the hardware platform, compiler versions, the
>source code, and so on that are required to interpret the results.  However it is very
>unlikely that the figure cited is due to the compiler failing to generate correct code.
> 
   I have seen one set of benchmark results for some quite large 
fortran programs, Alpha came out more than twice as fast as an HP 720 snake.
It was a non-production machine with early compiliers so the ratio
should get bigger....


Sorry, I just don't have anymore details, I wasn't supposed to see these
results (but I did). What about those rumours that production Alphas will
ship in December?

Regards, Chuck 

Newsgroups: comp.benchmarks
From: wilson@moonshine.llnl.gov (Mike Wilson )
Newsgroups: comp.benchmarks
Subject: Re: SPEC (was Re: wanted: benchmark results for DEC alpha)
Date: 14 Oct 92 02:51:55 GMT
Organization: Magnetic Fusion Energy - LLNL

mash@mash.wpd.sgi.com (John R. Mashey) writes:

>If I can figure out how to post what I have in a useful form, I'll do it.
>(Right now, a lot of it is, and has to be, for any insight, in graphical
>form).  One good consistent set of data was having 20 data points of
>Crimsons versus IBM 500s, where SPECfp92 of Crimson was .9 of the 550,
>but the mean of the 20 FP-intensive applications was 1.2X Crimson over 550
>(with of course, a very wide variance, as we've said time and time again is
>waht to expect in FP-intense codes).  The codes included finite-element
>analysis, computational chemistry, and simulations [and names withheld,
>I don't even know them, just have the data points.]  

Is your data in postable graphic form?  It would be useful in any postscript/
scanned format you chose to present it in.

-mike
Newsgroups: comp.benchmarks
From: symons@elec.uq.oz.au (Anthony Symons)
Subject: benchmarks wanted
Summary: benchmarks wanted
Keywords: benchmarks
Organization: Prentice Centre, University of Queensland
Date: Fri, 9 Oct 1992 00:29:15 GMT

I am a PhD student at The University of Queensland.

I have read an excelent article in 'Computer Architecture News'
 vol 19 no4 june 1991 on benchmark variation. The author was

	Carl Ponder : Computer Research Group
	Lawrence Livermore National Laboratory 

I would like his EMAIL address, or an EMAIL address of someone at the
laboratory so I can get his address. 

Many thanks in advance,
Anthony Symons 	email symons@s1.elec.uq.oz.au
The University of Queensland
Newsgroups: comp.benchmarks
From: kincer@hagar.endicott.ibm.com (Mike Kincer)
Subject: GPC PLB 
Date: Mon, 12 Oct 92 21:41:04 GMT
Reply-To: kincer@owgvm6.vnet.ibm.com
Organization: IBM FSC Owego

I'm looking for GPC Picture Level Benchmark numbers for i860 based
graphics engines, Xstations, whatever.  Anybody have any performance
data to be shared?  Thanks. 

Mike                              __  __o         / "Everythin's IMHO,
Kincer@owgvm6.vnet.ibm.com       __   \<,        /    irrespective of my
~~~~~~~~~~~~~~~~~~~~~~~~~~    ______()/ ()______/      employer's"
Xref: sparky comp.org.eff.talk:6457 comp.admin.policy:1326 alt.censorship:8081 alt.comp.acad-freedom.talk:3186 alt.society.civil-liberty:6290
From: cdt@sw.stratus.com (C. D. Tavares)
Newsgroups: comp.org.eff.talk,comp.admin.policy,alt.censorship,alt.comp.acad-freedom.talk,alt.society.civil-liberty
Subject: Re: Supreme Court and U.S. Constitution (was Re: Banned Computer Material 1992)
Date: 15 Oct 92 21:40:03 GMT
Followup-To: comp.org.eff.talk
Organization: Stratus Computer, Inc.

In article <1992Oct14.200218.13330@dcatlas.dot.gov>, joet@dcatlas.dot.gov (Joe Trott) writes:
> The Constitution, like any other use of language, is subject to interpretation.
> There are limits, however, on the "range" over which this interpretation
> may be _reasonably_ made.  For example, changes in technology have made
> certain ideas obsolete, or significantly enhanced others.  Back when news
> traveled at the speed of a steamship or railroad locomotive, it was not
> unreasonable to involve groups of people (e.g. Congress) in certain types
> of decisions that are in today's faster world better left to _one_ man
> (i.e. the President).  Military and diplomatic decisions come to mind.

The Constitution was made amendable so that such changes which are REALLY
the result of general agreement among the citizenry COULD be made in a
proper fashion.  Instead, the government simply reconfigures itself 
without the advice or consent of the governed and dares anybody to do 
something about it.

Besides, your rationale is somewhat contrary.  The most egregious example
of a congressional power that has been subsumed by the president is the
power to declare war (by committing troops but "not actually declaring"
war).  Ignoring, for the moment, the fact that it is NEVER a great idea 
to leave such a power in the hands of one person, it is precisely in a
society with POOR communications that this idea is most attractive, since
there is no guarantee you will obtain a timely convocation of a large
deliberative body.
-- 

cdt@pdp.sw.stratus.com      --If you believe that I speak for my company,
OR cdt@vos.stratus.com        write today for my special Investors' Packet...
Newsgroups: comp.org.eff.talk,misc.int-property,alt.suit.att-bsdi,comp.unix.bsd
From: mnemonic@eff.org (Mike Godwin)
Subject: Re: Finding The Hacker Crackdown
Originator: mnemonic@eff.org
Organization: Electronic Frontier Foundation
Date: Tue, 13 Oct 1992 03:03:39 GMT

In article <1992Oct12.120058.5@cobra.dra.com> sean@cobra.dra.com writes:
>Finding _The Hacker Crackdown_.
>
>The bookstores certainly seem confused about where to put this one.  I
>checked the Library of Congress's records and got the ISBN, correct spelling
>of the author's name and the title of the book.  Normally that's enough
>to find any current book.

In Austin, Texas, the BookStop stocks it in the computer section. The B.
Dalton's in the Lechmere Galleria in Cambridge is planning to put it in
Science or Current Affairs.

Since the author of this book, Bruce Sterling, unaccountably says flattering
things about me, I was of course forced to buy several copies for close
relatives.  This may have resorted in a temporary shortage.


--Mike



-- 
Mike Godwin,    |"Liberty resides in the rights of that person
mnemonic@eff.org| whose views you find most odious."
(617) 864-0665  | 
EFF, Cambridge  |                           --John Stuart Mill
Newsgroups: comp.org.eff.talk,misc.int-property,alt.suit.att-bsdi,comp.unix.bsd
From: joslin_paul@ae.ge.com
Newsgroups: comp.org.eff.talk
Subject: Re: EFFector Online 3.06: Bruce Sterling
Date: 7 Oct 92 18:15:44 GMT
Reply-To: joslin_paul@ae.ge.com
Distribution: na
Organization: GE Aircraft Engines
Originator: joslin@c0223.ae.ge.com

learn@speedy.acns.nwu.edu (William J. Vajk) writes:

>It is not clear at all that private sector employment offers greater
>pay than government employment. Consider further the double dip taken
>by many who are career military men for twenty years (entitling them
>to full pension) and then work in another government capacity thus being 
>paid a double pension. 

Let's inject some facts into the rhetoric:

	1)  Military retirement pay is not a pension.  It is reduced pay
for a reduced level of service.  Any retired military person can be
recalled at the whim of the president.  True pensions offer vesting
after 5 years; with the military, it is twenty years or nothing.
In fact, the military pension sounds like a great deal - until you
realize that most people who serve never see a cent.
	2)  "Full" pension corresponds to about 37% of salary for 20
years of service last time I looked.  The amount is figured on base pay;
the allowances for food, housing and uniforms are not included.
	3)   Double government pensions have been outlawed for years; at
least since the early 80's, and possibly since the Carter years.  Those
military personnel who earn a government pension forfeit all of the
second pension over $6000/year.

>How many were instances of military men retiring
>and returning to the same job, same deskm in civilian clothing the
>following Monday?
	4) Because of (3), damned few.  And in the 80's, stringent laws
were enacted to prohibit retired military personnel from taking jobs
with contractors they had overseen, or jobs in which they had
substantial contact with their former coworkers.  In their wisdom,
Congress chose to apply these laws only to the executive branch.  
Apparently, military people are evil and greedy, while Congressmen and
their staffs are pure and public-minded.

It is easy to set the military up as the Great Satan, filled with evil,
venal men and women eager to sup at the public's expense.  The reality
is far different.
-- 
     Paul R. Joslin     | A federal government big enough to give you
joslin@c0223.ae.ge.com  | everything you want is a federal government big
   +1 513 583 3537      | enough to take everything you have.  
                        |		 Gerald R. Ford
From: Robert.Dyess@f6507.n124.z1.fidonet.org (Robert Dyess)
Newsgroups: comp.org.eff.talk
Subject: EFFector Online 3.06: Bruce Sterling
Date: 6 Oct 92 04:45:00 GMT

jkp@cs.HUT.FI

* In a message originally to All, Jyrki Kuoppala said:

BS> The single most stinging example of this syndrome is "Pengo," a member
BS> of the German hacker-group that broke into Internet computers while in
BS> the pay of the KGB. He told German police, and the judge at the trial of
BS> his co-conspirators, that he was inspired by NEUROMANCER and John
BS> Brunner's SHOCKWAVE RIDER.

JK> I don't know if Bruce is reading this, but anyway I would be
JK> interested in knowing people's viewpoint on this:

JK> Is it equally evil to work for U.S. government?

Considering my lack of expertise at sending messages on across Internet and 
the flaky FidoNet > Internet gateway we have, I will be amazed if this even 
reaches you. Nevertheless, here it is...

I personally believe it is evil to work for any government under these 
curcumstances since one cannot control how such information will be used. 
The "hacker" is just as responsible for the results of his actions as his 
employer.

Please respond with your views.

Robert Dyess  1:124/6507@fidonet.org  
 
 * Origin: *AmeriComm* in Dallas,TX 214/373-7314 - The info source. (1:124/6507)
From: jani.patokallio%acc1bbs@ssr.com (Jani Patokallio) 
Newsgroups: comp.org.eff.talk
Subject: Re: S893 - copying softwa
Date: 13 Oct 92 22:23:00 GMT
Distribution: world
Organization: Advanced Computer Concepts BBS, New Rochelle, NY 914-654-1981
Reply-To: jani.patokallio%acc1bbs@ssr.com (Jani Patokallio) 

In article <1asmu9INNkuf#early-bird.think.com> barmar@think.com (Barry
Margolin) writes:
-> In article <1992Oct6.090650.29502#netcom.com> tenney@netcom.com (Glenn S. Tenne
-> ) writes:
-> >It's my view that probably 80% (well, at least a majority!) of computer
-> >owners are now felons.  If you have one naughty copy of some software
-> >(say something selling for $400) and make a weekly backup of your
-> >hard disk, you are a felon in ten weeks.
-> 
-> Don't most software licenses specifically grant the right to make copies
-> for backup purposes?

Many have something along the lines of "One and one only copy of this
program may be made for backup purposes only".  Even more say "a backup
copy".  And of course some programs don't allow you to take a single copy.
But I doubt that a charge for taking 2 backups of a program would stick
in court...

---
 . AME 1.07 . 
                    
Newsgroups: comp.org.eff.talk
From: mnemonic@eff.org (Mike Godwin)
Subject: Re: Re- EFFector Online 3.06- B
Originator: mnemonic@eff.org
Organization: Electronic Frontier Foundation
Date: Wed, 7 Oct 1992 12:14:09 GMT

In article <1992Oct6.163623.6807@cae.prds.cdx.mot.com> dan@cae.prds.cdx.mot.com (Dan Breslau) writes:
>mnemonic@eff.org (Mike Godwin) writes:
>
>>Brad Hicks needs to remember that it is possible to have the same facts as
>>Hicks, yet disagree with him. Had Pengo, Hess, et al been truly motivated
>>by moral opposition to the United States policy, they wouldn't have asked
>>for money and drugs for their services.
>
>And you, Mike Godwin, either offer your services to the EFF for free, or
>else do not truly support their goals?

This argument has already been addressed, Dan. But since you raise the
issue again (not having read the thread perhaps?), I'll point out that, in
fact, I worked for EFF's goals before becoming an EFF employee. And I'll
point out also that I could be earning more money in another job.

>(I'm _not_ disagreeing with the rest of the article you wrote, just
>pointing out flawed logic here.)

It's only flawed if you missed the posting in which I addressed the issue.
If Pengo had quit a high-paying job in order to work for much less pay
offered by the KGB, I would grant that he had acted out of moral
conviction. The facts of the case do not support this claim, however.



--Mike




-- 
Mike Godwin,    |"Liberty resides in the rights of that person
mnemonic@eff.org| whose views you find most odious."
(617) 864-0665  | 
EFF, Cambridge  |                           --John Stuart Mill