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

[Jan-Willem Maessen]

On Jul 20, 2008, at 8:11 PM, Richard A. O'Keefe wrote:

> I read this as
>
> 	"Is there any way to take a 32-bit float in a register and end up  
> with a 32-bit int
>         in a register, without going through memory, in GHC?
> 	 How about the other way around?
> 	 How about 64-bit floats and integers?"
>
> It is rather hard to do portably in GHC what some hardware does not  
> do.

The reason to provide this as a primitive is so that code like Complex  
magnitude doesn't have to go through a completely opaque-to-the- 
compiler interface in order to extract bits from the underlying IEEE  
float representation.  Sure, code generation can't assign it to a  
register, but it could be kept on the stack.  Once we're peeking and  
poking through a Ptr (the trick that was suggested the last time this  
came up, too, if I remember rightly) we're sunk---GHC doesn't reason  
well at all about this stuff, and we need to allocate a Ptr to peek  
and poke.  If instead we use a foreign call, again, it's completely  
compiler-opaque.

> A long time ago hardware architects decided that separating the  
> integer and
> floating point register files was a Good Thing.
> The machine I know best is SPARC, where there are no instructions to  
> move
> data directly between integer registers and floating point registers.

Ironically, this is no longer true on Niagara-class (T1 and T2) SPARC  
machines.  So nowadays this may be the only architecture that *does*  
provide this ability.  But again, the really important thing is that  
the compiler can see that bits is bits and that the conversion  
involves no magic and no extra storage beyond a spill location on the  
stack.

> ... [stuff about SIMD snipped]...

> All things considered, I wouldn't worry about it too much:  the  
> memory in
> question should be at the top of the stack, so should be in L1  
> cache, so should
> be pretty fast to access, and other things may be more significant.

But only if GHC can treat them transparently---which at the moment it  
evidently can't!

All it'd take is a primitive from Float# -> Int32# and another from  
Double# -> Int64#...

-Jan-Willem Maessen

>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe