[Shootout-list] mandelbrot problem

[Stephen Weeks]

> > The mandelbrot benchmark is flawed because it uses floating point
> > computations with exact comparisons to yield bits in the output and
> > then requires an exact match on the output. 
> 
> This point has already been discussed, the current 'acceptance
> test' is too strict.

Thanks, I missed that.  For the record, here's the message I think
you are referring to

  http://lists.alioth.debian.org/pipermail/shootout-list/2005-February/001057.html

I haven't seen any action taken to fix the problem; or did I miss that
too?

> > As evidence of the problem, observe that mandelbrot.mlton produces
> > different output depending on whether the program is compiled with
> > "-ieee-fp false" or "-ieee-fp true", where the latter forces writes to
> > memory after every floating point operation.  
> 
> .. if that is so it is a bug in mlTon, you should file a bug
> report. There is a requirement to round after every operation.

I'm not sure what requirement you're referring to: SML, C, IEEE?  In
any case, it is not a bug in MLton.  MLton allows the programmer to
choose whether or not he wants strict IEEE compliance, at possibly
great performance cost.

> That isn't the same as writing to memory.  I provide the man page
> data for gcc version 4.0 for you below. 

Actually, I read the man page you point to as saying that
-ffloat-store for gcc is the same as -ieee-fp true for MLton.

  `-ffloat-store'
       Do not store floating point variables in registers, and inhibit
       other options that might change whether a floating point value is
       taken from a register or memory.

       This option prevents undesirable excess precision on machines such
       as the 68000 where the floating registers (of the 68881) keep more
       precision than a `double' is supposed to have.  Similarly for the
       x86 architecture.

Further, the description implies that the implementation in gcc is
similar to that of MLton.  Namely, make sure that all floating point
ops go through memory.  I just did a simple test on mandelbrot.gcc and
I see that -ffloat-store causes a similar slowdown for gcc (3X) as
-ieee-fp true does with MLton (5X).  So, everything I see is
consistent with my understanding that the only way to get IEEE
semantics on x86 is to bounce ops through memory, and that this can be
very costly.