Re: wish: optimize (x > 0.) floating point comparison.

Re: wish: optimize (x > 0.) floating point comparison.

[Yotam Medini]

>   Date: Tue, 22 Sep 1998 16:04:20 -0400
>   From: Robert L Krawitz <rlk@tiac.net>
>   Cc: egcs@cygnus.com
>
>      Date: Tue, 22 Sep 1998 08:55:30 -0700
>      From: Yotam Medini <yotam@avanticorp.com>
>
>      ...
>      I believe that floating-point comparisons (<, >, <=, >=) with 0.0 is
>      very frequent and worth the trouble of optimizing using the sign bit
>      within the (platform dependent) floating-point representation or some
>      other machine instruction.
>
>   That's not correct.  Consider -0.0 (all zeroes in the mantissa and
>   exponent, 1 in the sign bit).  This should compare >= 0 (it is, after
>   all, mathematically equal to zero).  Furthermore, it would not take an
>   exception if the bits do not in fact represent a valid number.

Good point.
I am not familier with the (IEEE?) standard of floating-point representation.
May be a the following pseudo code (with lazy || evaluation)
    bool positive(double x)
    { return((highBit(x) == 0) || ((bitwise)x == (bitwise)(-0.0))); }
is still faster?

Actually, a preliminary question should be if
there is a better way to check for equality to zero than
using 'ldd' (of zero complement?) and 'fcmpd'.

   .LLC5:
	   .uaword	0x0 ! ~0.00000000000000000000e0
     .....
     .....
	   .type	 zeq,#function
	   .proc	04
   zeq:
	   !#PROLOGUE# 0
	   add %sp,-120,%sp
	   !#PROLOGUE# 1
	   sethi %hi(.LLC5),%g2
	   ldd [%g2+%lo(.LLC5)],%f2
	   std %o0,[%sp+96]
	   ldd [%sp+96],%f4
      	   fcmpd %f4,%f2
     ....

Math exception - I would gladly lose the exception handling
for faster code if I can turn it back on with appropriate debugging flags.

>   Robert Krawitz <rlk@tiac.net>	       http://www.tiac.net/users/rlk/

-- yotam

Re: wish: optimize (x > 0.) floating point comparison.

[Robert L Krawitz]

   Date: Tue, 22 Sep 1998 13:31:41 -0700
   From: Yotam Medini <yotam@avanticorp.com>

   Good point.
   I am not familier with the (IEEE?) standard of floating-point representation.
   May be a the following pseudo code (with lazy || evaluation)
       bool positive(double x)
       { return((highBit(x) == 0) || ((bitwise)x == (bitwise)(-0.0))); }
   is still faster?

BTW, there's another issue, which cuts both ways: FP numbers in the
FPU have more precision and range (64/15) than FP numbers in memory
(52/11).  Storing intermediate results in memory causes zero to be
stored if the exponent is very negative.  So if you have -1E-2000, for
example, storing it out to memory will store a zero (probably -0.0,
but zero nonetheless).

I've personally had more problems with the excess precision than
benefits (in fact, usually involving comparisons with zero!), but that
depends upon exactly what you're doing.

-- 
Robert Krawitz <rlk@tiac.net>	       http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: wish: optimize (x > 0.) floating point comparison.

[Richard Henderson]

On Tue, Sep 22, 1998 at 04:48:35PM -0400, Robert L Krawitz wrote:
> BTW, there's another issue, which cuts both ways: FP numbers in the
> FPU have more precision and range (64/15) than FP numbers in memory
> (52/11).

Keep that intel-centric abortion to yourself.  Sparc doesn't do that.


r~

Re: wish: optimize (x > 0.) floating point comparison.

[Joe Buck]

> On Tue, Sep 22, 1998 at 04:48:35PM -0400, Robert L Krawitz wrote:
> > BTW, there's another issue, which cuts both ways: FP numbers in the
> > FPU have more precision and range (64/15) than FP numbers in memory
> > (52/11).
> 
> Keep that intel-centric abortion to yourself.  Sparc doesn't do that.

The Motorola 68000 architecture has the same problem.

Re: wish: optimize (x > 0.) floating point comparison.

[Branko Cibej]

Richard Henderson wrote:

> On Tue, Sep 22, 1998 at 04:48:35PM -0400, Robert L Krawitz wrote:
> > BTW, there's another issue, which cuts both ways: FP numbers in the
> > FPU have more precision and range (64/15) than FP numbers in memory
> > (52/11).
>
> Keep that intel-centric abortion to yourself.  Sparc doesn't do that.

I think that's a bit strong. After all, the 80-bit float format used is
an IEEE standard, as far as I know. And what's wrong with having 80-bit
long doubles instead of 128-bit ones?

--
Branko Cibej   <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
phone: (++386 61) 186 53 49  fax: (++386 61) 186 52 70

Re: wish: optimize (x > 0.) floating point comparison.

[Richard Henderson]

On Fri, Sep 25, 1998 at 09:11:27AM +0200, Branko Cibej wrote:
> I think that's a bit strong. After all, the 80-bit float format used is
> an IEEE standard, as far as I know.

Well, if you consider a standard used by exactly one machine "standard"...

> And what's wrong with having 80-bit
> long doubles instead of 128-bit ones?

No, what's wrong is that it is impossible to get intermediate results
properly rounded without sacrificing all performance.


r~

Re: wish: optimize (x > 0.) floating point comparison.

[Robert L Krawitz]

   Date: Tue, 22 Sep 1998 13:31:41 -0700
   From: Yotam Medini <yotam@avanticorp.com>

   Good point.
   I am not familier with the (IEEE?) standard of floating-point representation.
   May be a the following pseudo code (with lazy || evaluation)
       bool positive(double x)
       { return((highBit(x) == 0) || ((bitwise)x == (bitwise)(-0.0))); }
   is still faster?

Once you're doing the extra comparison, is it even faster anyway?
Anyway, this isn't correct; what happens if you have a NaN?  NaN's are
not numbers, so numerical comparisons are meaningless.

   Actually, a preliminary question should be if
   there is a better way to check for equality to zero than
   using 'ldd' (of zero complement?) and 'fcmpd'.

      .LLC5:
	      .uaword	0x0 ! ~0.00000000000000000000e0
	.....
	.....
	      .type	 zeq,#function
	      .proc	04
      zeq:
	      !#PROLOGUE# 0
	      add %sp,-120,%sp
	      !#PROLOGUE# 1
	      sethi %hi(.LLC5),%g2
	      ldd [%g2+%lo(.LLC5)],%f2
	      std %o0,[%sp+96]
	      ldd [%sp+96],%f4
	      fcmpd %f4,%f2
	....

   Math exception - I would gladly lose the exception handling
   for faster code if I can turn it back on with appropriate debugging flags.

The problem is that sometimes you'll get the exception and sometimes
not, dependinging upon whether the operand is already in the FPU (in
which case it's almost surely faster to do the comparison in the FPU)
or if it's in memory.  If you always force it out to memory to perform
integer comparisons, you'll lose performance when the operand *is*
already in the FPU.

-- 
Robert Krawitz <rlk@tiac.net>	       http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: wish: optimize (x > 0.) floating point comparison.

[N8TM]

In a message dated 9/26/98 2:43:31 PM Pacific Daylight Time, root@ihack.net
writes:

> > Incorrect.  Motorola uses a 96-bit format with different precision.
>  
>  Don't let the 96-bit length fool you.  It's really the same format,
>  but with 16 bits wasted (for alignment purposes, I assume).
>  
Thanks for the confirmation.  Intel, of course, lets you pack the 80-bit
quantities in memory, or use 128 bits, with 48 bits wasted (unless you have a
special use for them), for better performance alignment.

Re: wish: optimize (x > 0.) floating point comparison.

[Charles M. Hannum]

> On Sat, Sep 26, 1998 at 10:03:54AM -0400, Charles M. Hannum wrote:
> > Don't let the 96-bit length fool you.  It's really the same format,
> > but with 16 bits wasted (for alignment purposes, I assume).
> 
> No it isn't the same, as the representable precision is different.
> For example, LDBL_MIN:
> 
>         i386    3.36210314311209350626e-4932
>         m68k    1.68105157155604675313e-4932

I hate to drag this out, but unfortunately your include files are
wrong.

Unlike the single- and double-precision formats, the
extended-precision format includes the leading 1 digit explicitly in
the mantissa.  This is the same on both i386 and m68k.

See section 1.5.2 of the `M68000 Family Programmer's Reference
Manual'.

Re: wish: optimize (x > 0.) floating point comparison.

[Andreas Schwab]

"Charles M. Hannum" <root@ihack.net> writes:

|> > On Sat, Sep 26, 1998 at 10:03:54AM -0400, Charles M. Hannum wrote:
|> > > Don't let the 96-bit length fool you.  It's really the same format,
|> > > but with 16 bits wasted (for alignment purposes, I assume).
|> > 
|> > No it isn't the same, as the representable precision is different.
|> > For example, LDBL_MIN:
|> > 
|> >         i386    3.36210314311209350626e-4932
|> >         m68k    1.68105157155604675313e-4932
|> 
|> I hate to drag this out, but unfortunately your include files are
|> wrong.

No, in this point he is right.

|> Unlike the single- and double-precision formats, the
|> extended-precision format includes the leading 1 digit explicitly in
|> the mantissa.  This is the same on both i386 and m68k.

But the Intel and Motorola formats differ in the interpretation of the
minimum exponent for denormalized numbers.  Other than that the formats
are identical apart from byte-order.

|> See section 1.5.2 of the `M68000 Family Programmer's Reference
|> Manual'.

Note that none of the m680x0 manuals get the value for LDBL_MIN right, the
68060 manual is closest, but still wrong.

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

Re: wish: optimize (x > 0.) floating point comparison.

[Charles M. Hannum]

> On Sat, Sep 26, 1998 at 01:32:18AM -0400, N8TM@aol.com wrote:
> > The same standard (extended double precision) was adopted by Motorola 6888[12]
> > and Intel.  
> 
> Incorrect.  Motorola uses a 96-bit format with different precision.

Don't let the 96-bit length fool you.  It's really the same format,
but with 16 bits wasted (for alignment purposes, I assume).

Re: wish: optimize (x > 0.) floating point comparison.

[Richard Henderson]

On Sat, Sep 26, 1998 at 10:03:54AM -0400, Charles M. Hannum wrote:
> Don't let the 96-bit length fool you.  It's really the same format,
> but with 16 bits wasted (for alignment purposes, I assume).

No it isn't the same, as the representable precision is different.
For example, LDBL_MIN:

	i386	3.36210314311209350626e-4932
	m68k	1.68105157155604675313e-4932


r~

Re: wish: optimize (x > 0.) floating point comparison.

[N8TM]

In a message dated 9/25/98 7:56:20 AM Pacific Daylight Time, rth@cygnus.com
writes:

> the 80-bit float format used is
>  > an IEEE standard, as far as I know.
>  
>  Well, if you consider a standard used by exactly one machine "standard"...
>
The same standard (extended double precision) was adopted by Motorola 6888[12]
and Intel.  
  
>  > And what's wrong with having 80-bit
>  > long doubles instead of 128-bit ones?
>  
>  No, what's wrong is that it is impossible to get intermediate results
>  properly rounded without sacrificing all performance.
The 80-bit intermediate precision is sufficient in a number of documented
cases to protect the accuracy of the final standard double precision result.
My results using CELEFUNT, for example, bear this out.   Using 128-bit
intermediate results will achieve this with a far greater loss of performance.
The rounding mode switch has been provided to enable 53-bit rounding mode, in
case that is desired, with a significant increase in speed of division and
sqrt().   It's true that changing the rounding mode consumes quit a bit of
time, but in practice that's more of a problem for integer truncation and for
Fortran ANINT() and NINT(), where the Fortran and IEEE standards are at odds.

How did we stray so far from the original topic of this thread?

Re: wish: optimize (x > 0.) floating point comparison.

[Richard Henderson]

On Sat, Sep 26, 1998 at 01:32:18AM -0400, N8TM@aol.com wrote:
> The same standard (extended double precision) was adopted by Motorola 6888[12]
> and Intel.  

Incorrect.  Motorola uses a 96-bit format with different precision.

> The 80-bit intermediate precision is sufficient in a number of documented
> cases to protect the accuracy of the final standard double precision result.

That's nice.  If you want to follow ISO and IEEE rules all calculations,
without exception, must be properly rounded.

> My results using CELEFUNT, for example, bear this out.

So technically you should have written that using an explicit long double. 
Or real*10 if g77 supported that.

> The rounding mode switch has been provided to enable 53-bit rounding mode,
> in case that is desired...

You miss the key point: to follow the rules, single precision operations
must also be properly rounded. 

So a strictly conforming compiler on x86 must either drop all intermediate
results to memory, or be continually reloading the fpcr.

> How did we stray so far from the original topic of this thread?

I have no idea.


r~

Re: wish: optimize (x > 0.) floating point comparison.

[Andreas Schwab]

Richard Henderson <rth@cygnus.com> writes:

|> On Sat, Sep 26, 1998 at 01:32:18AM -0400, N8TM@aol.com wrote:
|> > The same standard (extended double precision) was adopted by Motorola 6888[12]
|> > and Intel.  
|> 
|> Incorrect.  Motorola uses a 96-bit format with different precision.

Incorrect.  The Motorola format is identical (apart from byte order) to
the Intel format except for the minimum denormalized number.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

Re: wish: optimize (x > 0.) floating point comparison.

[N8TM]

In a message dated 9/23/98 2:37:10 PM Pacific Daylight Time,
yotam@avanticorp.com writes:

> I wonder if there are primitive FPU compare instructions with (+/- 0.0)
>  with a single operand. 
There have been architectures which kept the positive and zero condition flags
automatically set in accordance with the last changed floating point register,
but this doesn't seem to be too useful now that most CPU's have multiple
register pipelined operations and out-of-order execution.  Architectures which
keep a "register" which always shows as containing zero provide the ability to
compare with zero without having to find a zero variable datum.

Re: wish: optimize (x > 0.) floating point comparison.

[Yotam Medini]

Now that I realized how much I lack knowledge of FPU issues,
I wonder if there are primitive FPU compare instructions with (+/- 0.0)
with a single operand. 

-- yotam

Re: wish: optimize (x > 0.) floating point comparison.

[Richard Henderson]

On Wed, Sep 23, 1998 at 08:57:09AM -0700, Yotam Medini wrote:
> Now that I realized how much I lack knowledge of FPU issues,
> I wonder if there are primitive FPU compare instructions with (+/- 0.0)
> with a single operand. 

No, but zero will be held in a register as needed; fcmp
really is the fastest way to do this operation.


r~

wish: optimize (x > 0.) floating point comparison.

[Yotam Medini]

My assembly-code reading skill is very poor.
Still, given:
    double x;
and viewing the code generated (gcc -S -O?) I think the following
two logical expressions
       (x >= 0.)
       (x >= 13.)
result with the same computational complexity.

I believe that floating-point comparisons (<, >, <=, >=) with 0.0 is
very frequent and worth the trouble of optimizing using the sign bit
within the (platform dependent) floating-point representation or some
other machine instruction.

Hope this idea could help. -- yotam

Re: wish: optimize (x > 0.) floating point comparison.

[Robert L Krawitz]

   Date: Tue, 22 Sep 1998 08:55:30 -0700
   From: Yotam Medini <yotam@avanticorp.com>

   My assembly-code reading skill is very poor.
   Still, given:
       double x;
   and viewing the code generated (gcc -S -O?) I think the following
   two logical expressions
	  (x >= 0.)
	  (x >= 13.)
   result with the same computational complexity.

   I believe that floating-point comparisons (<, >, <=, >=) with 0.0 is
   very frequent and worth the trouble of optimizing using the sign bit
   within the (platform dependent) floating-point representation or some
   other machine instruction.

That's not correct.  Consider -0.0 (all zeroes in the mantissa and
exponent, 1 in the sign bit).  This should compare >= 0 (it is, after
all, mathematically equal to zero).  Furthermore, it would not take an
exception if the bits do not in fact represent a valid number.

-- 
Robert Krawitz <rlk@tiac.net>	       http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton