lkml.org 
[lkml]   [1996]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectAlphas and division (was: faster make depend)
From
Date
(this isn't much of  linux-kernel anymore)

Olaf Titz writes:
> Matti E Aarnio <mea@mea.cc.utu.fi> wrote:
> > In addition, calculating inverse ("1/x") of constant (at
> > compile time), and then doing multiplication with it is
> > (at Alphas) blinding fast... Sure it overflows, but the
> > result is correct for division :-) You can't get reminder
>
> Don't do such tricks without proper regard for precision. If you
> compute x/10 with FP arithmetic, the result is _exact_ e.g. for x=10
> or x=5. If you optimize this to be x*0.1, however, the result is
> _never_ exact because there is no exact binary FP representation for
> 0.1. (In simple cases you have the chance that the round-off errors
> compensate, but you can _never_ be sure of that - in precision
> calculations, round-off errors are always accounted for the worst
> case.)

I was NOT talking about FP operations, rather of INTEGER.
And of reasons, why the lack of integer division instruction
at Alphas is not a bad thing in my opinion.

For short: The division operation is iterative operation,
and as such it can't be done in short pipeline (2 stages
at calculation - 5 at the FP pipe), and therefore there
can't be very many division instructions going on at the
instruction flow -- every 80 instruction can be FP division,
assuming all else gets executed without "pipeline bubles" at
respective pipes at the 21164 (EV5) version of Alpha CPU.
(At 2-pipe models -- EV4 -- the FP-div separation is 40 instrs)

Alpha is pipelined processor, which means that to get the
most power out of it, one must have an instruction mix which
uses all resources in balanced fashion -- 4 (or 2) instruction
pipes (depending on model) are in use, when no resource
conflicts occur. If there is a resource conflict, some pipe
will not be scheduled an instruction, and it gets an "idle buble",
which degrades the performance.

Also if you look at the numeric code, MOST of it is multiplication.
(and addition/substraction), the divisions are rather rare.
(And mind you, for numerics people the Integer division is
VERY RARE, ergo it is ok to be left to software iteration)

> The numerics people would be very upset if someone implemented the
> above "optimization" in a compiler without telling them...

Yes they would, if they ever get any difference in results
due to it.

> olaf
> ___ Olaf.Titz@inka.de or @{stud,informatik}.uni-karlsruhe.de ____

/Matti Aarnio <mea@utu.fi>


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.063 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site