HDTenEightyP/NetNews huggingface dataset:
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: integer distance or sqrt
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Fri, 20 Nov 92 15:17:57 GMT

In article <1992Nov16.110102.17077@imada.ou.dk> breese@monet.imada.ou.dk (Bjoern Reese) writes:
>In article <CLIFFC.92Nov15184340@miranda.rice.edu> cliffc@rice.edu (Cliff  
>Click) writes:
>> bbs.dennis@tsoft.sf-bay.org (Dennis Yelle) writes:
>
>I found it some years ago in a german magazine called "MC."
>It was dubbed "Heron's Algorithm." As you can see it is a
>16 bit implementation. Does anybody have further information
>about this algorithm? (like, how to extend it to 32 bits.)

This from ACM SIGAPL Quote Quad, Vol 16, no 4, 1986, from
"A Perfect Square Root Routine", by E.E. McDonnell:

"Heron, the Alexandrian scientist (possibly as early as the
second century B.C or as late as the third century A.D.) devised
a method for approximating square roots which is still in use today.
The method is an iterative one, and exploits the fact that any
particular estimate Y of the value of the square root R of a positive
number X, if it is not equal to R, may be improved by computing the
average of Y and X divided by Y, that is:
   Y =. (Y +  X%Y) %2

If the estimate Y is positive, the method will eventually converge to
the square root. ... The closer the initial estimate Y is to the eventual
root, the fewer will be the number of iterations required. Much has
been written on the subject of choosing best estimates... "

(And he goes on to describe how he did it for SHARP APL).

Bob




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 20 Nov 92 18:01:57 GMT
Organization: Department of Computer Science, U of Copenhagen

moss@cs.cmu.edu (Eliot Moss) writes:

>In fact, conditional
>instructions are easy to handle in a regular pipeline -- you just suppress the
>store in the last step, and you certainly know the outcome of the comparison
>by then. In a superscalar, where things get reordered, it is admittedly not
>quite so simple.

But neither are conditional branches. I would like to see a
superscalar architecture that handles conditional branches by a
mechanism that could not also be used (or simplifyed) for conditional
moves or arithmetic. If need a conditional instruction on an ARM or
Alpha, you certainly will need a conditional branch on "normal" RISCs.
Looking for conditional branches in the pipeline is no easier than
looking for conditional instructions in general, especially on the
ARM, where the first 4 bits determine (uniformly) if the instruction
is conditional.

	Torben Mogensen (torbenm@diku.dk)
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: DEC Alpha AXP System Performance
Organization: Digital Equipment Corporation
Date: 17 NOV 92 10:34:09    


In article <1992Nov16.131126.785@irfu.se>, bt@irfu.se (Bo Thide') writes...
> 
>Don't forget that the 735 is both faster and less expensive than the
>DEC 3000/500 AXP:
> 
>9000/735: 80   SPECint92,   150.6 SPECfp92  at $35k
>500AXP:   74.3 SPECint92,   126.0 SPECfp92  at $39k
> 
to complete your table:

9000/755     80   SPECint92,   150.6 SPECfp92  at $59k
3000/400 AXP 65.3 SPECint92, 112.2 SPECfp92 at $15K

Cost per seat and price/perf are important too. You also have to look at
configurations, expandability etc. 735 and 3000/400 are desktop. 755 and
3000/500 are deskside.
Newsgroups: comp.arch
From: yankus@IMD.Sterling.COM (Mike Yankus)
Subject: Re: DEC Alpha AXP System INTEGER Performance
Organization: Sterling Software, IMD
Date: Wed, 18 Nov 1992 18:03:57 GMT
X-Md4-Signature: bc41fb57ce4a15127f640a3d032f48da

In article <1992Nov16.231949.1214@ryn.mro4.dec.com> Blair.Phillips@cao.mts.dec.com writes:
>
> ...
>Most real programs will use the runtime libraries for string manipulation, and
>anyone serious about speed won't access single bytes very often, even on a VAX,
>so trading off the byte access against cycle time is beneficial in almost all
>cases except artificial benchmarks (e.g. Dhrystone).

You are forgetting about a large volume of programs which mainly do
nothing but character manipulation.  These include editors, compilers,
mail handling, and the very programs which do the posting and reading
of News.  I would consider a machine which does not have efficient
character handling capability a step backwards of about 30 years.
Is this really the case with the Alpha?
-- 
Mike Yankus	             UUCP:     uunet!sparky!yankus
PRC Inc.                     INTERNET: yankus@sparky.IMD.Sterling.COM
1410 Wall St.                Phone:    (402) 291-8300 
Bellevue, NE. 68005-3687     FAX:      (402) 291-4362

Newsgroups: comp.arch,comp.benchmarks
From: bt@irfu.se (Bo Thide')
Subject: Re: Lisp performance (on Sparc SS2, SS10-30, HP720)
Date: Mon, 16 Nov 1992 12:52:34 GMT
Organization: Swedish Institute of Space Physics, Uppsala, Sweden

In article <1e824rINNlpu@iraul1.ira.uka.de> wolpers@i11s10.ira.uka.de (Andreas Wolpers) writes:
>Hello everybody,
>
>I'm having a minor problem on which I would welcome any comments:
>Since I'll have some money to spend real soon now, I've been pondering
>whether we should switch from Sun to HP. The usual benchmark results
>suggest that a change might result in faster execution of our pet
>program, a large "theorem prover" written in Lisp.
>
>From the SpecInt92 results, one should expect a performance increase
>of about a factor of 2 when switching from a SS2 to either s SS10-30
>or HP720. Unfortunately, on both machines turned out to but just
>30% faster than a SS2 when running our system (for which ps NEVER
>shows a resident set under 3-4 MB, not even on an 8MB machine).
>
>Any explanations at hand? Did we encounter a bottleneck between
>CPU and memory, or what? What performace should I expect from
>a SS10-41 or SS10-52 (which have a larger cache, but still not 
>large enough to hold the Lisp's resident set. And if I'm not
>mistaken, the large cache results in a longer time spent for
>non-cache memory accesses (6 cycles instead of 3)). What 
>performace should I expect from a HP735?
>
>I can buy enough memory so that disk speed is no criterion.
>Should I wait for machines with 8MB of cache? Should I shoot myself?
>Should I give YOU the money? :-)
>
>Sigh,
>
>Andreas
>-- 
>Andreas Wolpers
>e-mail: wolpers@ira.uka.de
>phone:  49-721-608-3977
>fax:    49-721-697760

The HP9000/720 has been replaced by the much faster 735.  In REDUCE (a
Lisp-based symbolics algebra package) there is a benchmark for timing a
certain set of REDUCE/Lisp operations.  The following timigs have been
obtained:


 SYSTEM NAME      TYPE        PROCESSOR    OS         LISP     TIME
                                                               (sec)

Cray              Y-MP C90    Cray         UNICOS     PSL       0.97
Cray              X-MP        Cray         UNICOS     PSL       1.28
HP 9000            720        HP/RISC      HP-UX      PSL       1.7
SparcStation         2        Sparc        Sun/OS 4   PSL       2.9

It is believed that the 735 will be the first workstation to break the 1
second barrier and even beat the Cray Y-MP C90 in this test.

Bo
-- 
   ^   Bo Thide'--------------------------------------------------------------
  |I|        Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden
  |R|      Phone: (+46) 18-303671.  Fax: (+46) 18-403100.  IP: 130.238.30.23
 /|F|\          INTERNET: bt@irfu.se      UUCP: ...!mcvax!sunic!irfu!bt  
 ~~U~~ ----------------------------------------------------------------sm5dfw-
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: DEC Alpha AXP System INTEGER Performance
Organization: Digital Equipment Corporation
Date: 23 NOV 92 13:29:59    


In article <1992Nov20.220615.7494@raid.dell.com>, samf@yosemite.dell.com (Sam Fuller) writes...
>After reviewing the Alpha performance claims, I had the feeling that the integer unit
>did not really run at 133Mhz.  It looked to me that the floating point pipeline was
>superpipelined at 133Mhz, but that the integer side ran at a more reasonable 66Mhz.  The
>pipes can operate independently and I imagine be dispatched in parallel, hence the 
>superscalar appelation. In my opinion, either DEC did a terrible job of code scheduling 
>for their integer pipeline or its not really running at 133Mhz or 200Mhz as the case may
>be.
> 
> 
> 
>Anyone who knows care to comment on this analysis?
> 
This is not true. The cpu is capable of issuing 2 instructions every cycle.
Floating point is fully pipelined as is the integer unit. Integer shifts
take 2 cycles; integer add/sub and logical ops take one cycle.

Dileep
Newsgroups: comp.arch
From: andrew@megadata.mega.oz.au (Andrew McRae)
Subject: Re: DEC Alpha architecture issues
Organization: Megadata P/L, North Ryde, Sydney, Aust.
Date: Sun, 22 Nov 1992 04:38:52 GMT

> Another difference is that the instructions available to PALcode are not
> architected.  The assumption is that PALcode will use standard Alpha
> instructions plus up to five additional instructions specific to the
> implementation.  Also, no cpu registers are defined.  The PALcode is what
> implements standard things like interrupts triggered by implementation
> specific mechanisms.  So, the CPU implementations are free to be as creative
> as they can be in making the basic instruction set fast as well as making
> PALcode fast.

If it looks like microcode, smells like microcode ... Why call it PALcode?
(`A rose is a rose by any other name'?)

Andrew McRae (andrew@megadata.mega.oz.au)
From: campbelr@hpcuhe.cup.hp.com (Bob Campbell)
Date: Wed, 18 Nov 1992 21:40:15 GMT
Subject: Re: PA-RISC ``semantic loading'' (according to DEC)
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.arch

>> I suspect
>> that PA-RISC can get by with executing fewer instructions as well.

> This is, in a nutshell, the CISC viewpoint.

Some might call it engineering. 
---------------------------------------------------------------------------
Bob Campbell                Some times I wish that I could stop you from
campbelr@cup.hp.com         talking, when I hear the silly things you say.
Hewlett Packard                                    - Elvis Costello
Newsgroups: comp.arch
From: breese@monet.imada.ou.dk (Bjoern Reese)
Subject: Re: integer distance or sqrt
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Tue, 17 Nov 1992 11:30:57 GMT

In article <1992Nov16.172604.4947@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth)  
writes:
> In article <1992Nov16.110102.17077@imada.ou.dk> breese@monet.imada.ou.dk  
(Bjoern Reese) writes:
> 
> >Heron(x)   {Fast integer squareroot routine}
> >   IF x <= 64 THEN
> >      y = 2 + (x >> 3)  {shift right 3 times}
> >   ELSE
>     ...
> >   ENDIF
> >   root := (y + x DIV y) >> 1
> >
> >This algorithm is faster than Newton's Method...
> 
> Maybe so, but Newton's method doesn't tell you that the square
> root of 0 is 1.

:( Sorry about that :(

Let's fix it.

Heron(x)
   IF x = 0 THEN
      y = 1
   ELSE
      IF x <= 64 THEN
      ...
      ENDIF
   ENDIF
   root := (y + x DIV y) >> 1

or

Heron(x)
   IF x = 0 THEN
      root := 0
   ELSE
      IF x <= 64 THEN
      ...
      ENDIF
      root := (y + x DIV y) >> 1
   ENDIF

--

Bjoern Reese                   |     Email: breese@imada.ou.dk
Odense University, Denmark     |     Voice: +45 65 932 182 (private)
Newsgroups: comp.arch
From: twpierce@unix.amherst.edu (Tim Pierce)
Subject: Length of instruction pipeline in SPARC Version 8?
Organization: Elitist Usenet Administrators, Stuff & Nonsense Division
Date: Mon, 23 Nov 1992 00:04:45 GMT

Does anyone know the number of cycles in the instruction pipeline in
SPARC Version 8?  (Specifically, in a Sun SPARCstation ELC.)  My
thesis is about compiling for RISC, and I'm using SPARC for my example
RISC architecture.  It only occurred to me a couple of days ago that
I've been ASSUMING throughout that the SPARC pipeline has three
cycles!  I have "The SPARC Architecture Manual" for Version 8 of the
SPARC architecture, but I cannot find this information anywhere
therein.

I'm rather embarrassed at having to ask the net for information, since
I usually try so hard to find it in some other way.  However, this
project is coming down to the wire, and I'd like to have accurate
information about the architecture.

-- 
____ Tim Pierce                / 
\  / twpierce@unix.amherst.edu /               Rocks say goodbye.
 \/ (BITnet: TWPIERCE@AMHERST) /
From: nathanb@clipper.ingr.com (Nathan Brookwood)
Newsgroups: comp.arch
Subject: Re: Registerless processor
Date: 23 Nov 92 22:17:07 GMT
Organization: Intergraph Advanced Processor Division - Palo Alto, CA

In article 11202, Theo de Raadt suggests that the registers in the PDP-11
were mapped onto memory, in the style of the PDP-10.

This was not the case.  These registers had bus addresses from which they
could be interrogated for diagnostic purposes from the front panel, 
(in a day when machines still had physical lights and switches), but
there was no practical way for programs to access these registers as 
anything but registers.

And, yes, they were implemented as registers, and not as memory, as de Raadt
implies. And no, you couldn't execute a program out of them.

BTW, I believe the Univac 1100 Series (1105/1107/1108 et al) also mapped
their registers onto the low order addresses in memory, a la the PDP-6 and
PDP-10.
Newsgroups: comp.arch,comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Generating exponentially distributed pseudorandom numbers.
Organization: Xenix Support, FICC
Date: Mon, 16 Nov 1992 21:49:59 GMT

In the latest NASA Tech Briefs is an article describing a piece of hardware
that generates ten million exponentially distributed random numbers, 8 bits
wide, per second. From the description, extending this to 32 or more bits is
a simple matter of plugging more units in (at an n**2 cost per bit,
admittedly). It's quite a clear presentation. I would be interested in
seeing Herman's response to the article.

NASA Tech Briefs, November 1992, Volume 16 No. 11, Page 52.

The work was done by James E. Steelman, Jeff Beasley, Michael Aragon,
Francisco Ramirez, Keneth L. Summers, and Arthur Knoebel of Regents of
New Mexico State University for NASA JPL.

There is a reference to a previous work in Nasa Tech Briefs Volume 10 No. 4.
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
Newsgroups: comp.arch
From: pmk@moliere.uucp (Peter Michael Klausler)
Subject: Re: 64 bit Alpha AXP -vs- 32 bit computers
Organization: Lilydale DFL Refreshments Committee & Rhythm Section
Date: Wed, 18 Nov 1992 15:29:40 GMT

In article <BxvEJw.6Bu@rice.edu> preston@miranda.cs.rice.edu (Preston Briggs)
writes:
>
>Another nice use is to speed up bit-wise computation.
>For example, many compilers do lots of data-flow analysis,
>summarizing results in long bit vectors; say, O(1000) bit chunks.
>It's surely faster to AND and OR these things 64 bits at a time,
>not to mention the reduced fetches from cache.

It's even more fun to use real vector registers for those bit vectors.
Newsgroups: comp.arch
From: jfc@athena.mit.edu (John F Carr)
Subject: Re: DEC Alpha AXP System INTEGER Performance
Keywords: Alpha, AXP, SPEC, DEC, INTEGER
Organization: Massachusetts Institute of Technology
Date: Sun, 22 Nov 1992 17:09:12 GMT

In article <1992Nov20.220615.7494@raid.dell.com>
	samf@yosemite.dell.com (Sam Fuller) writes:

>After reviewing the Alpha performance claims, I had the feeling that the
>integer unit did not really run at 133Mhz.  It looked to me that the
>floating point pipeline was superpipelined at 133Mhz, but that the integer
>side ran at a more reasonable 66Mhz.  The pipes can operate independently
>and I imagine be dispatched in parallel, hence the superscalar appelation.

The integer pipeline runs at full speed, but:

	. dual issue is rare in the current implementation with current
	compilers, for integer-only code

	. many instructions, including load and shift, have multi-cycle
	latencies

	. the primary caches are small and the secondary cache has a
	long access time

gcc in particular runs slowly on an Alpha, because it uses a lot of bit
manipulation instructions, makes many memory references, and has a poor
memory access pattern.

--
    John Carr (jfc@athena.mit.edu)
Newsgroups: comp.arch
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: DEC Alpha AXP System INTEGER Performance
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 16 Nov 1992 05:58:33 GMT

Greg Pavlov (pavlov@niktow.canisius.edu) wrote:
:   The SPECint92 values seem somewhat low, in terms of processor MHz.  Any 
:   known reasons why ?  Essentially, our R3000-based systems, at 40 MHz, 
:   have a SPECint92 (measured by DEC) that is apx. 40% of an ALPHA-based 
:   system at 133 MHz.
The bus clock for alpha is much lower. If I remember correctly it is only
half that or even worse(33Mhz?).
	With 64 bits, the amount of data and instruction that can be cached
is much smaller so the internal cache is not as effective as many people 
thought, especially in this newsgroup.
	This is only a very wild guess. How about dhryston performance?
It may tell us more about the cache performance.

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Newsgroups: comp.arch
From: kjchang@hplabsz.hpl.hp.com (K. J. Chang)
Subject: Re: PA-RISC ``semantic loading'' (according to DEC)
Date: Fri, 20 Nov 1992 03:47:38 GMT
Organization: Hewlett-Packard Laboratories Palo Alto,CA

In article <1992Nov19.204612.10316@odin.diku.dk> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
1st> I suspect
1st> that PA-RISC can get by with executing fewer instructions as well.
2nd> This is, in a nutshell, the CISC viewpoint.
3rd>Some might call it engineering. 
 
1st>                  I was clearly describing the HP-PA architecture as
1st>being placed firmly within the RISC sphere, albeit in the less
1st>aggressively hardware-optimizable end.
1st>
1st>Rather than snide remarks, I had hoped to elicit informed comment as
1st>to how much the statefulness of the HP-PA programmers' model impacts
1st>(or can be assumed to impact) current and future implementations, in
1st>development time *and* in achievable speed for a given technology.
1st>
1st>Please?

Let me try.

First of all, I do not think I know both architecture and VLSI enough to call
PA-RISC being in the "less aggressively hardware-optimizable end." However,
I suspect that current PA-RISC is not too complex to design with the advent of
the state-of-the-art logic/layout synthesis. Using advanced EDA tools, I think 
it is possible to design a new RISC layout more complex than PA-RISC and 
still achieve fast-time-to-market and price-competitive dies. People may have
to use full/semi-custom design styles instead of gate-array though.

1st>
1st>Lars Mathiesen (U of Copenhagen CS Dep)<thorinn@diku.dk> (Humour NOT marked)

KJ "Not a PA-RISC designer" Chang
-- 
K J Chang, Hewlett-Packard ICBD R & D,                      (())_-_(())
Palo Alto, CA 94304                                          | (* *) | 
Internet: kjchang@hpl.hp.com           a UCLA Bruin  -->    {  \_@_/  }
voice mail: (415)857-4604                                     `-----'  
Newsgroups: comp.arch,comp.lang.misc
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 24 Nov 92 04:03:15 GMT
Article-I.D.: cs.By7CLG.L2q.2
Organization: School of Computer Science, Carnegie Mellon

gerhard@netmbx.netmbx.de (Gerhard Hoffmann) writes:
>In article <By4pEI.8r5.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>>- PALcode is fetched from the I-cache, not from ROM.
>
>This doesn't mean anything. Early low-end /360 machines had their 
>microcode in main store, and still it was microcode.

IBM called it microcode, but I don't. In fact, they built a small
minicomputer, and then wrote a software interpreter which took 360
instructions and did them. Calling that "microcode" was more a
political statement than a technical one. Admittedly, some microcode
schemes are more encoded than others: but this "vertical microcode"
has abandoned all the things that the word "microcode" usually means,
except one. [That users be prohibited from writing in it!]

PALcode is far more analogous to supervisor state than to microcode.
If people want to reply that supervisor state smells like microcode,
then I will hold my tongue and let them.
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: hblim@iti.gov.sg (Hock-Beng Lim)
Subject: Bus bandwidth query
Organization: Information Technology Institute, National Computer Board, Singapore.
Date: Mon, 23 Nov 1992 04:12:59 GMT

I apologize in advance if this is not the most appropriate place for my query.

I would like to know the peak and sustained data transfer bandwidth of the ISA,
EISA, VME, SBus, and MicroChannel buses. Please send me email if you know
these numbers. Thanks in advance !

HB
-- 
-----------------------------------------------------------------------------
Hock-Beng Lim                                   | hblim@csrd.uiuc.edu
Center for Supercomputing R&D, UIUC. (on leave) | hblim@iti.gov.sg 
Information Technology Institute, Singapore.    | tel : (65)772-7205,772-7273
Newsgroups: comp.arch
From: zrepachol@cc.curtin.edu.au
Subject: Re: IDE faster than Mips SCSI disk
Organization: Curtin University of Technology
Date: Mon, 16 Nov 1992 20:05:04 GMT

In article <k2.721304278@woodstock>, k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:
> tgcpwd@rw9.urc.tue.nl (Wim van Dorst) writes:
...
> I did have VMS Posix running on my VAX, and it gives indeed better
> results. I'm seeing results in the 200 - 300 kBytes/sec range.
> (A little MVIII, with SMD disks, platter rate around 2Mb/sec).
> I did not know how well the Posix environment did emulate Unix
> system calls, so I think native VMS programs with their ugly $QIO
> interface will see better rates.
> 
Yep, but you will need to specify contiguous files, lock the buffers into your
working set, run at a high real-time priority... Them you should get xfer rates
that aproach the platter speed of the drive.
On a Q-bus RSX ( PDP-11 ) system years ago I could pull >2MB/sec off 3 Fugitsu
ESDI drives. This was mainly due to defered writes in the controller cache.
The RSX case was multiple tasks BTW, not a single read stream. The best IO with-
out a cache is ~1.1MB/sec from 1.2MB/sec SMD drives, dual ported to an 11/70.
Again this was multiple streams.

A VMS system will also show how bad fragmentation can be to performance. Just
remove the contig bit from the create and turn it lose on a near full busy
disk!

All this only proves that we are infact measuring everything EXCEPT disk speed!!

~Paul

Newsgroups: comp.arch,comp.lang.misc