HDTenEightyP/NetNews huggingface dataset:
From: kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner)
Subject: How many vector registers are useful?
Reply-To: kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner)
Organization: University of Kaiserslautern, Germany
Date: Mon, 25 Jan 1993 13:11:46 GMT
Keywords: architecture, question

Hello,

On discussing various merrits of different vector machines we came about
the issue of the register architectures.

There are on one side the cray and convex with 8 vector registers a 64 or
128 words, and on the other side,

The Fujitsu machines with their reconfigurable register file of 32 or
64kb, which is 4k or 8k words, being grouped from 256 register a 16/32
words to 8 registers a 512/1024 words.

Now there is the question: is such a large register file useful at all ?

Some thoughts:

A register has an optimizing effect only when the value in it can be used
several times, at least twice, to avoid loading the value again from
memory.  We all know that this is to a great extent possible on scalar
machines.

But how is this on vector machines ? The register creates a speedup only
when it can hold an entire vector, which can be used again later. This
requires a register long enough to do so. That means vectors of e.g. a
length of 5000 can not be held anyway, every machine must load, process,
and store it in pieces, and only a lot of memory bandwidth helps.

When configured as a few long vectors the Fujitsu vector registers may
help, but then comes the second question: Are there any statistics on the
reusing of vectors? I know about such things for scalar registers, where
people found that 32 is plenty enough, and only 8 help a lot. But in these
cases registers are used for loop indexes, addresses etc., which can not
be compared to the use of vector registers.

So: what can be gained with such a big vector register file ? Or is it
only of limited help ? Can the register file be traded against bandwith to
load and store from memory ?

Reinhard Kirchner
Univ. of Kaiserslautern, Germany
kirchner@informatik.uni-kl.de
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.sys.super
From: eugene@wilbur.nas.nasa.gov (Eugene N. Miya)
Subject: economics meets technology: was SSI
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Thu, 28 Jan 93 18:37:04 GMT

More than one poster noted:
>a machine on the floor

I have always wondered where the thresholds of success are.
More than one company actually delivered 1-2 machines in the field.
A few companies made tens of deliveries, and even Alliant delivered
500 machines or so during its time.  Some still living vendors have yet to
break 100 machines while others have over 1000 delivered.
It is perhaps our perspective of time since it might be that all these
businesses fail in the long run (century or more even).

--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.sys.super,comp.arch,comp.compilers
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: How many vector registers are useful?
Reply-To: hrubin@pop.stat.purdue.edu (Herman Rubin)
Organization: Purdue University Statistics Department
Date: Thu, 28 Jan 1993 13:35:00 GMT
Keywords: architecture, vector

kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:
> A register has an optimizing effect only when the value in it can be used
> several times, ...

jlg@cochiti.lanl.gov (J. Giles) writes:
>[Another effect] (also true of scalars) is when the value is
>an intermediate.

Suppose one considers a not too outlandish problem, namely, that of
producing a vector of non-uniform random variables (exponential, normal,
gamma, beta, etc.).  It is possible to vectorize the reasonably efficient
acceptance-rejection and acceptance-replacement methods available, at
least if there is a reasonable use of control vectors, and a typical such
procedure will use about a half-dozen registers.  Many of these procedures
need division, and if division has to be stepped, it will add another
register or so.

If only one vector process can be done at a time, so far so good.  But
many vector machines can parallelize the vector processes, so we have a
cause for proliferation.  Even if only load and store can be parallelized
with vector computation, we can add a few more.  So it would not surprise
me if a few dozen would not be a good idea.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.sys.super,comp.parallel
From: knut@uni-paderborn.de (Knut Menzel)
Subject: Correction: Re: World's Most Powerful Computing Sites
Reply-To: knut@uni-paderborn.de
Organization: University of Paderborn
Date: 27 Jan 1993 09:21:47 GMT

In article <1993Jan20.211032.11929@hubcap.clemson.edu>, richard@meiko.com (Richard Cownie) writes:
|> knut@uni-paderborn.de (Knut Menzel) writes:
|> : 
|> : 	4.4 Gflops - (1992)
|> : 	Paderborn Center for Parallel Computing
|> : 	pcpc@uni-paderborn.de
|> : 	1) Parsytec SuperCluster, 320 Inmos T800, 900 Mflops
|> : 	2) Parsytec GC Giga Cube, 1024 Inmos T805, 4.4 Gflops
                                             ^^^^
                                             It's new
|> : -- Knut Menzel
|> 
|> This seems to imply a figure of over 4MFLOPS per T800.  Last time
|> I programmed one, it was a real struggle to achieve over 1MFLOPS
|> even for inner loops of vector routines.  Not that 4MFLOPS is
|> necessarily a lie, you might manage it if you're adding two 32-bit
|> zeros (and never storing the result).  But it's certainly stretching
|> the truth a long way: there are lies, damned lies, and statistics.

Sorry, it is the T805 (30 MHz) and the given peak (!) performance is
about 4.4 MFlops. However, I assume everybody knows about peak performance 
and its real value. In addition my opinion is that most of the given
performance values in the presented list are peak values.

-- Knut Menzel
--------------------------------------------------------------------------
 Knut Menzel                          University of Paderborn
 email:   knut@uni-paderborn.de       Department of Computer Science FB17
          ...!uunet!unido!pbinfo!knut Warburger Str. 100
 Tel:     +49 5251 603325             D-4790 Paderborn
 Telefax: +49 5251 603853
--------------------------------------------------------------------------


Newsgroups: comp.sys.super
From: Patrick F. McGehearty <patrick@convex.COM>
Subject: Re: World's Most Powerful Computing Sites
Originator: patrick@wagner.convex.com
Date: Mon, 25 Jan 1993 15:51:23 GMT
Reply-To: patrick@convex.COM (Patrick F. McGehearty)
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <8699@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
...
>  But than we get at the standard question: what should
>you use?

I rather like using Dongarra's Linpack report (either the Best Effort
with n=1000, or for some systems, the Rmax from Table 3 with n selected
by the vendor.  These benchmarks measure actual solution of real problem,
under almost ideal conditions.  They also are widely available and regularly
updated.  Jack makes serious efforts to keep the vendors honest.  There are
very few application/machine combinations which will show higher Gflop
ratings than that provided by these numbers, so that benchmark can be
considered the realistic attainable peak for 64-bit floating point
operations.  Be careful when quoting a higher 32-bit peak to note the 64-bit
performance also.

Of course, any careful evaluation of super architecture needs to take
into account peak achievable megaflops (Linpack), memory bandwidth
(McCalpin's Stream), sustainable I/O bandwidth (to disk and high speed
network) as a proportion of peak megaflops, and ease of achieving
significant fractions of these peaks on real application codes.

We have already discussed Gflops and memory megabytes/sec.
Any opinions on the amount of I/O bandwidth necessary to support/sustain
a useful Gflop in a production environment?  My intuition is that 10
Mbytes/second is a bit skimpy, while 100 Mbytes/second is ample.  Is that
the right range?  Anyone have actual application performance requirements?

By the way, I mean actual, delivered data to an application, not peak
hardware specs of the fastest bus on the system.  Specmanship is really
common in quoting I/O performance, just as peak Mflops is common.  Alertness
on the part of you users, writers, and reviewers is necessary to keep us
vendors from playing spiraling artifical, meaningless number games.
Newsgroups: comp.sys.super
From: richard@meiko.com (Richard Cownie)
Subject: Re: World's Most Powerful Computing Sites
Organization: Meiko Scientific Corp.
Date: Thu, 21 Jan 1993 16:51:59 GMT

fineberg@wilbur.nas.nasa.gov (Samuel A. Fineberg) writes:
: In article <1993Jan20.211032.11929@hubcap.clemson.edu>, richard@meiko.com (Richard Cownie) writes:
: |> This seems to imply a figure of over 4MFLOPS per T800.  Last time
: |> I programmed one, it was a real struggle to achieve over 1MFLOPS
: |> even for inner loops of vector routines.  Not that 4MFLOPS is
: |> necessarily a lie, you might manage it if you're adding two 32-bit
: |> zeros (and never storing the result).  But it's certainly stretching
: |> the truth a long way: there are lies, damned lies, and statistics.
: |> 
: |> -- 
: |> Richard Cownie (a.k.a. Tich), Meiko Scientific Corp 
: |> email: richard@meiko.com
: |> phone: 617-890-7676
: |> fax:   617-890-5042       
: |> 
: Its certainly no less realistic than those for the i860.
: 
: Sam

I have to disagree with you there.  I know of *some* applications where
the i860 can achieve a good fraction of claimed peak speed, e.g. on
a double-precision matrix multiply you can do over 35MFLOPS, against
a peak rate claimed as 40MFLOPS (or sometimes 60MFLOPS, because you can do
2 adds for each multiply).  In any case, it's well over 50% of peak.

If a T800 transputer can achieve 50% of 4.4MFLOPS on a matrix multiply,
or indeed *anything* useful, I'd be interested to hear about it.

Performance on big compiled Fortran programs is another kettle of fish,
and here I'd agree that peak performance figures are not much help.
-- 
Richard Cownie (a.k.a. Tich), Meiko Scientific Corp 
email: richard@meiko.com
phone: 617-890-7676
fax:   617-890-5042       
Newsgroups: comp.sys.super
From: fineberg@wilbur.nas.nasa.gov (Samuel A. Fineberg)
Subject: Re: World's Most Powerful Computing Sites
Organization: CSC, NASA Ames Research Center, NAS Division
Date: Fri, 22 Jan 93 01:58:27 GMT
Reply-To: fineberg@nas.nasa.gov

In article <1993Jan21.165159.10149@meiko.com>, richard@meiko.com (Richard Cownie) writes:
|> fineberg@wilbur.nas.nasa.gov (Samuel A. Fineberg) writes:
|> : In article <1993Jan20.211032.11929@hubcap.clemson.edu>, richard@meiko.com (Richard Cownie) writes:
|> : |> This seems to imply a figure of over 4MFLOPS per T800.  Last time
|> : |> I programmed one, it was a real struggle to achieve over 1MFLOPS
|> : |> even for inner loops of vector routines.  Not that 4MFLOPS is
|> : |> necessarily a lie, you might manage it if you're adding two 32-bit
|> : |> zeros (and never storing the result).  But it's certainly stretching
|> : |> the truth a long way: there are lies, damned lies, and statistics.
|> : |> 
|> : |> -- 
|> : |> Richard Cownie (a.k.a. Tich), Meiko Scientific Corp 
|> : |> email: richard@meiko.com
|> : |> phone: 617-890-7676
|> : |> fax:   617-890-5042       
|> : |> 
|> : Its certainly no less realistic than those for the i860.
|> : 
|> : Sam
|> 
|> I have to disagree with you there.  I know of *some* applications where
|> the i860 can achieve a good fraction of claimed peak speed, e.g. on
|> a double-precision matrix multiply you can do over 35MFLOPS, against
|> a peak rate claimed as 40MFLOPS (or sometimes 60MFLOPS, because you can do
|> 2 adds for each multiply).  In any case, it's well over 50% of peak.
|> 
|> If a T800 transputer can achieve 50% of 4.4MFLOPS on a matrix multiply,
|> or indeed *anything* useful, I'd be interested to hear about it.
|> 
|> Performance on big compiled Fortran programs is another kettle of fish,
|> and here I'd agree that peak performance figures are not much help.
|> -- 
|> Richard Cownie (a.k.a. Tich), Meiko Scientific Corp 
|> email: richard@meiko.com
|> phone: 617-890-7676
|> fax:   617-890-5042       

I don't know too many people that write assembly code, and that is what you
need to do to get 35 MFLOPs.  As far as I'm concerned, assembly coded
benchnmarks are useless.  And if you can't get more than 60% of peak on an
assembly coded matrix multiply, that is bad (when Intel quotes peak speeds
on its system it uses the 60MFLOPs number, or 75 for the Paragon). The best I
have ever seen on an i860 was 10-15Mflops, and that was because the compiler
had stuck in some special vector subroutines in my code where it recognized
a daxpy operation.  I don't know what the transputer is capable of, but I would
be surprised if it can't do 75-90% of peak for a useless assembly coded 
benchmark.

Sam
Newsgroups: comp.sys.super,comp.arch,comp.compilers
From: hyatt@cis.uab.edu (Robert Hyatt)
Subject: Re: How many vector registers are useful?
Reply-To: hyatt@cis.uab.edu (Robert Hyatt)
Organization: University of Alabama at Birmingham
Date: Wed, 27 Jan 1993 01:57:12 GMT
Keywords: architecture, vector

In article <93-01-195@comp.compilers> jlg@cochiti.lanl.gov (J. Giles) writes:
>Vectors and scalars are not really all that different.  Unless you have
>overlap between the vectors they really behave just like large scalars.

Good point.  If you program in assembler on a Cray, you also use registers
to pre-fetch memory operands before you need 'em.  In this regard, re-use
makes things even better, but even if you only do the equivalent of i++ in
C, you can win big if you don't run out of registers.... ie, load i n
clocks before it is needed, then s1 s1+1, then store it and don't use s1
for n clocks.  the result is a three clock i++, as fast as it can be done
on a Cray.  (n varies by cpu type.... and by memory type.  can at least
span the interval 14 clocks to 24 clocks and even up to 50 clocks on some
Cray-2 processors I have used.)

Same holds true for vectors.  You don't necessarily have to have high
reuse to win, just enough registers to keep data flowing (a) from memory
(b) to memory and (c) between functional units....
--
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: tridge@nimbus.anu.edu.au (Andrew Tridgell)
Newsgroups: comp.sys.super
Subject: Re: LIST OF SITES - NEW RATINGS
Date: 27 Jan 1993 09:56:26 GMT
Organization: Australian National University, Canberra
Distribution: inet
NNTP-Posting-Host: 150.203.15.21

>Since many of those sites included [not very interesting] peak MFLOPS
>ratings for Intel Paragon and TMC CM-5 machines, but Dongarra's latest
>[January 13, 1993] Linpack report STILL has no Linpack numbers for the
>Paragons and CM-5s (even in Table 3, where one can make the matrices
>as large as they wish!), would some owner of these machines please
>give us the Linpack results for those two systems?

I haven't tried linpack itself but I have coded some vector and matrix
routines. On a CM-5 with vector units I have achieved 75MFlops per node
for vector*matrix, matrix*vector and matrix*matrix routines. I have
achieved 45MFlops for an outer product of two vectors. These are all for
double precision numbers. I believe the quoted peak performance is
128MFlops per node. I am not a experienced CM5 programmer (these were my
first vector unit routines) and expect that much better results could be
obtained by someone with more experience. In particular I suspect that
the pipelining of instructions could give me a big improvement.

I coded these routines in CDPEAC and tested with vector lengths of
around 100 and matrices of approx 100*100. 

On a related issue - has anyone got any code to copy data from scalar
memory to the DP stack or heap on the CM5 at better than 16Mb per
second? I really need to copy data much faster than that.  This is
really only an issue if you are programming using the CMMD message
passing library. 


Andrew


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Andrew Tridgell                 CSLab, Research School of Physical Sciences
Andrew.Tridgell@anu.edu.au      Australian National University (x3064)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.sys.super
Subject: Re: World's Most Powerful Computing Sites
Date: 22 Jan 93 22:08:24 GMT
Organization: CWI, Amsterdam

In article <1993Jan22.015827.26653@nas.nasa.gov> fineberg@nas.nasa.gov writes:
 > I don't know too many people that write assembly code, and that is what you
 > need to do to get 35 MFLOPs.  As far as I'm concerned, assembly coded
 > benchnmarks are useless.  And if you can't get more than 60% of peak on an
 > assembly coded matrix multiply, that is bad (when Intel quotes peak speeds
 > on its system it uses the 60MFLOPs number, or 75 for the Paragon).
But as I read it the T800 does not even come near 50% of peak for an
assembly coded matrix multiply.  The article you responded to mentioned
great problems in even getting 25%.
 >                   I don't know what the transputer is capable of, but I would
 > be surprised if it can't do 75-90% of peak for a useless assembly coded 
 > benchmark.
If the peak value is correct a useless assembly coded benchpark should get
much closer to 100% (not really 100% because you always need program startup).
I have reached over 95% on a 25 nsec CDC Cyber 750 (over 38 MFLOPS).  But
of course you could not use the results, they were not even stored anywhere.
And of course the input values were all zero.  That is why useless benchmarks
are just that.  (It is of course still worse if even with a useless benchmark
you can not reach 75% of peak as I recorded in another article.)
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: bownes@peterpan.crd.ge.com (Keptin Komrade Dr. Bobwrench III)
Newsgroups: comp.sys.super
Subject: Re: SSI in deep weeds - anyone know what's going on?
Date: 28 Jan 93 15:51:40 GMT
Organization: School of Corrective Phrenology

Interesting that IBM cited a lack of a machine as a reason to stop funding.
Last I heard there was one on the floor up and running and parts ready to 
put #2 together.

-- 
Bob Bownes, aka iii - "Fork twice to avoid zombies"
Warning: This may contain opinions. They belong to me, not to Aule-Tek, 
Sun Microsystems, General Electric or anyone else. But you can rent them. 
Newsgroups: comp.sys.super
From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin)
Subject: Re: i860 performance (was: Re: World's Most Powerful Computing Sites)
Organization: College of Marine Studies, U. Del.
Date: Fri, 22 Jan 1993 22:03:31 GMT

In article <C19s04.3yF@pgroup.com> lfm@pgroup.com (Larry Meadows) writes:
>>The problem is that peak mflops performance doesn't give the whole story --
>memory bandwidth is much more important.  Perhaps machines should be
>rated by how long it takes to do a vector add, or some such measure; then
>"super-vector" performance occurs when values can be left in vector registers.

This was the motivation for my "stream" benchmark.  I have not added any
new results lately, but the code, documentation, and lots of results are
in the anonymous ftp area of perelandra.cms.udel.edu in bench/stream/.

Some tidbits:

	 Memory Bandwidth results from STREAM_S and STREAM_D 
	 John D. McCalpin --- mccalpin@perelandra.cms.udel.edu

                    Bytes          Bandwidth (MB/s)    
Machine             /word      Copy     SSCAL       Sum     SAXPY   
---------------     -----  --------  --------  --------  --------   
Cray YMP/C90 16 cpu     8  105497.4  104656.4  101736.1  103812.8   
Cray YMP/C90  1 cpu     8    6965.4    6965.4    9378.7    9500.7   
Cray Y/MP 8 cpu         8   19291.6   19294.2   26588.9   26802.2   
Cray Y/MP 1 cpu         8    2426.4    2426.2    3454.4    3396.9   
CM-200  8k 10 MHz       8    5251.4    5251.3    5931.4    5653.2   
CM-2    8k 7 MHz        8    3224.5    3224.5    3657.4    3494.8   
NEC SX3/44 1 cpu        8   16941.0   15640.7   22436.5   21972.2   
NEC SX3/12 1 cpu        8    8302.2    7670.9    9712.8    9712.9   
ETA-10E                 8    2974.7    3010.5    4357.5    4214.8   
IBM 3090J/VF 1 cpu      8     251.9     250.1     288.5     264.6   
Convex C3420 2 cpu      8     289.1     273.1     302.7     300.3   
Convex C3410 1 cpu      8     177.6     172.5     179.0     178.4   
Convex C3220 2 cpu      8     334.3     333.0     337.3     336.5   
Convex C3210 1 cpu      8     180.1     179.4     181.4     180.8   
MIPS RC6280             8      53.5      58.2      56.5      56.5   
IBM RS6000-950          8     193.9     177.8     195.9     192.0   
HP 9000/730             8      53.3      48.0      55.4      55.4   
HP 9000/720             8      43.6      40.0      45.0      42.3   
---------------     -----  --------  --------  --------  --------   
-- 
--
John D. McCalpin                        mccalpin@perelandra.cms.udel.edu
Assistant Professor                     mccalpin@brahms.udel.edu
College of Marine Studies, U. Del.      John.McCalpin@mvs.udel.edu
From: gunter@tartarus.uwa.edu.au (Gunter Ahrendt)
Newsgroups: comp.sys.super
Subject: LIST OF SITES - NEW RATINGS
Date: 22 Jan 1993 02:07:44 GMT
Organization: The University of Western Australia
Distribution: inet
NNTP-Posting-Host: tartarus.uwa.edu.au
X-Newsreader: NN version 6.4.19 #1

Well, i'm happy that most people find some interest in the list, i guess we all
agree that the rating system isn't very good, so i do want to change this to a
standard benchmark figure, does somebody have the Dongarra (sp.) benchmark
figures? Or is there another (LINPACK) that someone has figure for?

If i can find some standard rating to cover most machines, i'll adjust my list,
so please, send me.
Newsgroups: comp.sys.super