[Haskell-cafe] Data.Complex.magnitude slow?

[stefan kersten]

On 17.07.2008, at 17:42, Ian Lynagh wrote:
> On Thu, Jul 17, 2008 at 05:18:01PM +0200, Henning Thielemann wrote:
>> Complex.magnitude must prevent overflows, that is, if you just square
>> 1e200::Double you get an overflow, although the end result may be  
>> also
>> around 1e200. I guess, that to this end Complex.magnitude will  
>> separate
>> mantissa and exponent, but this is done via Integers, I'm afraid.
>
> Here's the code:
>
> {-# SPECIALISE magnitude :: Complex Double -> Double #-}
> magnitude :: (RealFloat a) => Complex a -> a
> magnitude (x:+y) =  scaleFloat k
>                      (sqrt ((scaleFloat mk x)^(2::Int) +  
> (scaleFloat mk y)^(2::Int)))
>                     where k  = max (exponent x) (exponent y)
>                           mk = - k
>
> So the slowdown may be due to the scaling, presumably to prevent
> overflow as you say. However, the e^(2 :: Int) may also be causing a
> slowdown, as (^) is lazy in its first argument; I'm not sure if  
> there is
> a rule that will rewrite that to e*e. Stefan, perhaps you can try  
> timing
> with the above code, and also with:
>
> {-# SPECIALISE magnitude :: Complex Double -> Double #-}
> magnitude :: (RealFloat a) => Complex a -> a
> magnitude (x:+y) =  scaleFloat k
>                      (sqrt (sqr (scaleFloat mk x) + sqr (scaleFloat  
> mk y)))
>                     where k  = max (exponent x) (exponent y)
>                           mk = - k
>                           sqr x = x * x
>
> and let us know what the results are?

thanks ian, here are the absolute runtimes (non-instrumented code)  
and the corresponding entries in the profile:

c_magnitude0 (Complex.Data.magnitude)           0m7.249s
c_magnitude1 (non-scaling version)              0m1.176s
c_magnitude2 (scaling version, strict square)   0m3.278s

              %time  %alloc
              (inherited)

c_magnitude0 91.6   90.2
c_magnitude1 41.7   49.6
c_magnitude2 81.5   71.1

interestingly, just pasting the original ghc library implementation  
seems to
slow things down considerably (0m12.264s) when compiling with

-O2
-funbox-strict-fields
-fvia-C
-optc-O2
-fdicts-cheap
-fno-method-sharing
-fglasgow-exts

when leaving away -fdicts-cheap and -fno-method-sharing the execution  
time for
the pasted library code reduces to 0m6.873s. seems like some options  
that are
useful (or even necessary?) for stream fusion rule reduction, may  
produce
non-optimal code in other cases?

<sk>