Yes, looks like on 32 bits GCC is being smarter with the floating point generated from C, compared to the Haskell stuff. While on x86_64 it does the same (better) thing.

.type s1qL_info, @function
# 169 “/tmp/ghc5427_0/ghc5427_0.hc” 1
# 0 “” 2
fldl 16(%ebp)
fldl 1(%esi)
fxch %st(1)
fucom %st(1)
fnstsw %ax
fstp %st(1)
sahf
ja .L21
fld1
fldl 8(%ebp)
fadd %st(1), %st
fldl (%ebp)
fadd %st(3), %st
fxch %st(3)
faddp %st, %st(2)
fxch %st(1)
fstpl 16(%ebp)
fstpl 8(%ebp)
fstpl (%ebp)
jmp s1qL_info
.p2align 4,,7
.p2align 3
.L21:
fstp %st(0)
fldl (%ebp)
fdivl 8(%ebp)
addl $24, %ebp
fstpl 56(%ebx)
movl (%ebp), %eax
jmp *%eax

This makes the Haskell program a lot faster:

> ghc -O2 -fexcess-precision -fvia-C -optc-O2 -o h_mean src/Mean.hs
> time ./h_mean 1e9
> real 0m16.634s

By inlineing the mean function into the main function things get even more faster:

{-# INLINE mean #-}
mean :: Double -> Double -> Double
…

> ghc -O2 -fexcess-precision -fvia-C -optc-O2 -o h_mean src/Mean.hs
> time ./h_mean 1e9
> real 0m9.625s

By replacing the length counter of type Int with type Double things get even more faster:

go :: Double -> Double -> Double -> Double
go s l x | x > m = s / l
| otherwise = go (s + x) (l + 1) (x + 1)

> ghc -O2 -fexcess-precision -fvia-C -optc-O2 -o h_mean src/Mean.hs
> time ./h_mean 1e9
> real 0m4.842s

To be honest I do not really understand (yet) why the last two transformations speeded the Haskell version up. In the case of C version the last transformation had no effect on its performance.

To summarise, hear are the final results (for now) on my system:

> ghc -O2 -fexcess-precision -fvia-C -optc-O2 -o h_mean src/Mean.hs
> time ./h_mean 1e9
> real 0m4.842s

> gcc -O2 -o c_mean src/mean.c
> time ./c_mean 1e9
> real 0m2.770s

So, on my system C remains about twice as fast. For now, I am not able to make the Haskell version any faster. Any pointers in this direction will be very much appreciated. In particular, how can I get rid off the remaining fstp/fld instructions in the Haskell version.

I should also note that Don uses x86_64 architecture and I am using i686 (though my CPU, see above, has 64 bit support). I am not sure but this might be the main reason of different results. I do not have access to x86_64 machine to confirm this doubt.

Maybe it is time to upgrade my Arch Linux to x86_64 version.

Anyway, thanks for your post and helpful comments on my struggles. I learned a lot from this example.

Cheers, George

C version:

.L9:
fxch %st(2)
fxch %st(1)
.L4:
fadd %st(1), %st
fxch %st(1)
addl $1, %edx
fadds .LC0
fxch %st(2)
fucom %st(2)
fnstsw %ax
sahf
jae .L9
fstp %st(0)
fstp %st(1)
pushl %edx
fildl (%esp)
addl $4, %esp
.L3:
fdivrp %st, %st(1)
movl $.LC2, (%esp)
fstpl 4(%esp)
call printf

Haskell:

.type s1rK_info, @function
# 97 “/tmp/ghc10380_0/ghc10380_0.hc” 1
# 0 “” 2
fldl 12(%ebp)
fstpl 32(%esp)
fldl 32(%ebp)
fstpl 24(%esp)
fldl 32(%esp)
fldl 24(%esp)
fxch %st(1)
fucom %st(1)
fnstsw %ax
fstp %st(1)
sahf
ja .L12
fld %st(0)
movl 8(%ebp), %eax
fadds .LC0
addl $1, %eax
movl %eax, 8(%ebp)
fstpl 48(%esp)
fldl (%ebp)
fstpl 16(%esp)
faddl 16(%esp)
fstpl 56(%esp)
fldl 48(%esp)
fstpl 12(%ebp)
fldl 56(%esp)
fstpl (%ebp)
jmp s1rK_info
.p2align 4,,7
.p2align 3
.L12:
fstp %st(0)
fildl 8(%ebp)
fstpl 40(%esp)
fldl (%ebp)
addl $40, %ebp
fstpl 8(%esp)
fldl 8(%esp)
fdivl 40(%esp)
fstpl 64(%esp)
fldl 64(%esp)
fstpl 56(%ebx)
movl (%ebp), %eax
jmp *%eax
.size s1rK_info, .-s1rK_info

It seems to me that Haskell loop has lots of un-necessary fstp/fld (storing and loading of floating points) in the loop. However, in the core worker function for mean uses only unboxed types.

Cheers, George

P.S. I liked this ghc-core tool.

Check carefully it is being compiled properly, that the flags you think it is using are correct, and if all else fails, look at the generated code (the ghc-core tool is helpful here).

module Main where

import System.Environment

mean :: Double -> Double -> Double
mean n m = go 0 0 n
where
go :: Double -> Int -> Double -> Double
go s l x | x > m = s / fromIntegral l
| otherwise = go (s+x) (l+1) (x+1)

main :: IO ()
main = do
[d] <- map read `fmap` getArgs
print (mean 1 d)

Yes, the assembly above was obtained today (2009-03-08) with GHC 6.10, and GCC 4.3.3 on Linux x86_64. Runtimes are still much the same:

GCC -O2 1.966s
GHC -O2 -fvia-C -optc-O3 2.080

Are you sure you’re using the non-list based version?

Thanks for your timely reply.

I am using exactly the same version of GCC (4.3.3 the one which comes with Arch Linux) and tried exactly the same flags. Unfortunately, results for GHC got even worse.

> gcc -O2 -o c_mean src/mean.c
> ghc -O2 -fvia-C -optc-O3 -o h_mean src/Mean.hs

> time ./c_mean 1e9
500000000.500000
real 0m2.572s

> time ./h_mean 1e9
5.00000000067109e8
real 0m41.289s

You are right I should dig into the assembly codes and I am digging now.

Meanwhile, can you confirm that you get the similar (to your original post) results with newer versions of GHC. Results in your post are obtained with GHC 6.8.

Once again thanks for your excellent post and your help.

Cheers, George

The absolutely only way to see what is going on is to look at the assembly produced. This is highly dependent on which GCC version you use. In this case,

gcc (GCC) 4.3.3

The other issue I see is that you’re using different flags:

gcc -O2

and

ghc -O2 -fvia-C -optc-O3

Then check the resulting assembly (e.g. with the ghc-core tool):

s1u7_info:
ucomisd 5(%rbx), %xmm6
ja .L19
addsd %xmm6, %xmm5
addq $1, %rsi
addsd .LC0(%rip), %xmm6
jmp s1u7_info

.L19:
cvtsi2sdq %rsi, %xmm0
divsd %xmm0, %xmm5

> gcc -Wall -O3 -o c_mean src/mean.c
> ghc -Wall -O3 -o h_mean src/Mean.hs

> time ./c_mean 1e9
500000000.500000
real 0m2.611s

> time ./h_mean 1e9
5.00000000067109e8
real 0m17.968s

> ghc –version
The Glorious Glasgow Haskell Compilation System, version 6.10.1

> uname -a
Linux 2.6.28-ARCH #1 SMP PREEMPT i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux

I played with various GHC options (including -fvia-C) but without any success.

Any comments and suggestions will be very much appreciated. Can anyone else confirm the similar behaviour?

Understanding this results will help me to improve some of my own numerical Haskell code.

Cheers, George