Re: FFI-free NaN checks? (isDoubleNan and friends)

2018-03-06 Thread Sylvain Henry
Hi, You can try with foreign primops, it should be faster than the FFI: In IsDoubleNanPrim.s: .global isDoubleNan_prim isDoubleNan_prim:    xor %rbx,%rbx    ucomisd %xmm1, %xmm1    lahf    testb $68, %ah    jnp .Lout    mov $1, %rbx .Lout:    jmp * (%rbp) In IsDoubleNan.hs: {-# LANGUAGE

Re: FFI-free NaN checks? (isDoubleNan and friends)

2018-03-06 Thread Mateusz Kowalczyk
On 03/06/2018 10:43 AM, Brandon Allbery wrote: > I'd in general expect good C code to optimize a little better; and in > particular, decomposing an IEEE float is almost certainly more expensive in > Haskell than in C, because unions let you cheat. (And I recall looking at > the implementation of

Re: FFI-free NaN checks? (isDoubleNan and friends)

2018-03-06 Thread Brandon Allbery
I'd in general expect good C code to optimize a little better; and in particular, decomposing an IEEE float is almost certainly more expensive in Haskell than in C, because unions let you cheat. (And I recall looking at the implementation of decodeFloat once; it's significantly longer than that

Re: FFI-free NaN checks? (isDoubleNan and friends)

2018-03-06 Thread Mateusz Kowalczyk
On 03/05/2018 10:23 PM, Brandon Allbery wrote: > If the FFI version is done with "safe", consider using "unsafe" instead. > There are technical reasons why this is slightly incorrect, but unless > you're fiddling with the CPU's FP control flags they're mostly irrelevant > and you can treat isNaN

Re: FFI-free NaN checks? (isDoubleNan and friends)

2018-03-05 Thread Brandon Allbery
If the FFI version is done with "safe", consider using "unsafe" instead. There are technical reasons why this is slightly incorrect, but unless you're fiddling with the CPU's FP control flags they're mostly irrelevant and you can treat isNaN as pure and non-side-effectful, significantly reducing