Removing/deprecating -fvia-c

[Daniel Fischer]

Am Montag 15 Februar 2010 17:37:55 schrieb Simon Marlow:
> On 14/02/2010 17:58, Don Stewart wrote:
> > igloo:
> >> Hi all,
> >>
> >> We are planning to remove the -fvia-c way of compiling code
> >> (unregisterised compilers will continue to compile via C only, but
> >> registerised compilers will only use the native code generator).
> >> We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in
> >> 6.16.
> >>
> >> Simon Marlow has recently fixed FP performance for modern x86 chips
> >> in the native code generator in the HEAD. That was the last reason we
> >> know of to prefer via-C to the native code generators. But before we
> >> start the removal process, does anyone know of any other problems
> >> with the native code generators that need to be fixed first?
> >
> > Do we have the blessing of the DPH team, wrt. tight, numeric inner
> > loops?
> >
> > As recently as last year -fvia-C -optc-O3 was still useful for some
> > microbenchmarks -- what's changed in that time, or is expected to
> > change?
>
> If you have benchmarks that show a significant difference, I'd be
> interested to see them.

I have a benchmark (or a couple) from the Beginners mailing list two weeks 
ago (thread starting in January at 
http://www.haskell.org/pipermail/beginners/2010-January/003356.html and 
continued in February at 
http://www.haskell.org/pipermail/beginners/2010-February/003373.html ff) 
which show a significant difference.

Loop.hs:
========================================
{-# LANGUAGE BangPatterns #-}
module Main (main) where

main :: IO ()
main = do
    putStrLn "EPS: "
    eps <- readLn :: IO Double
    let !mx = (4/eps)
        !pi14 = pisum mx
    putStrLn $ "PI mit EPS "++(show eps)++" = "++ show(4*pi14)

pisum :: Double -> Double
pisum cut = go True 1 0
      where
        go b n s | cut < n = if b then s+1/(2*n) else s-1/(2*n)
        go True n !s = go False (n+2) (s+recip n)
        go False n !s = go True (n+2) (s-recip n)
========================================

$ echo '1e-8' | time ./Loop

ghc -O2 --make:
4.53s
ghc -O2 -fexcess-precision --make:
4.54s
ghc -O2 -fvia-C -optc-O3 --make:
7.52s
ghc -O2 -fvia-C -optc-O3 -optc-ffast-math --make:
7.53s
ghc -O2 -fvia-C -optc-O3 -optc-ffast-math -optc-fno-float-store --make:
3.02s
ghc -O2 -fvia-C -optc-O3 -optc-fno-float-store --make:
3.02s
ghc -O2 -fexcess-precision -fvia-C -optc-O3 --make:
3.02s

The loop coded in C and compiled with gcc -O3 [-ffast-math, -fno-float-
store, -msse2 make no difference there] also takes 3.02s (gcc-4.3.2), 2.70s 
with icc -O3 (icc 11.0).

It is probably worth pointing out, however, that on Markus Böhm's box 
running Windows XP, the native code generator produced better code than the 
via-C route (NCG code was faster there than on my box [openSUSE 11.1], 
while -O2 -fexcess-precision -fvia-C -optc-O3 on his box was slower than 
NCG on mine).

Similar results for

Fusion.hs (uses stream-fusion package)
========================================
module Main (main) where

import qualified Data.List.Stream as S

main :: IO ()
main = do
    putStrLn "EPS: "
    eps <- readLn :: IO Double
    let !mx = floor (4/eps)
        !k = (mx+1) `quot` 2
    putStrLn $ "PI mit EPS " ++ (show eps) ++ " = " ++ show (leibniz k)

leibniz n = (4 *) $ S.sum $ S.take n step

step :: [Double]
step = S.unfoldr phi (True,1) where
   phi (sig,d) | sig         = Just (1/d, (False,d+2))
               | otherwise   = Just (negate (1/d), (True,d+2))
========================================

ghc -O2 [-fexcess-precision] --make:
4.22s
ghc -O2 -fexcess-precision -fvia-C -optc-O3 --make:
3.02s

Using lists instead of loops,

List.hs
========================================
module Main (main) where

import Data.List (unfoldr)

main :: IO ()
main = do
    putStrLn "EPS: "
    eps <- readLn :: IO Double
    let mx = floor (4/eps)
        !k = (mx+1) `quot` 2
    putStrLn $ "PI mit EPS " ++ (show eps) ++ " = " ++ show (leibniz k)

leibniz n = (4 *) $ sum $ take n step

step :: [Double]
step = unfoldr phi (True,1) where
   phi (sig,d) | sig         = Just (1/d, (False,d+2))
               | otherwise   = Just (negate (1/d), (True,d+2))
========================================

things are much slower, 23.60s vs. 18.15s, but the via-C route is again 
significantly faster.

>
> What I've done for 6.14.1 is to add the -msse2 flag to the x86 backend,
> so where previously we had to use -fvia-C -fexcess-precision -optc-O3
> etc. to get reasonable floating point performance, now we can use -msse2
> with the native code gen and get about the same results.

Can I test whether I get about the same results as with -fvia-C ... for the 
above?
I.e., is it in the HEAD, and would I have to pass -msse2 on the command 
line or is it implied by -O2 already?

>
> In the future we have a couple of ways that things could get better:
>
>   1. The new back-end, which eventually will incorporate more
>      optimisations at the C-- level, and potentially could produce
>      good loop code.  It will also free up some registers.
>
>   2. Compiling via LLVM.
>
> Dropping the C backend will give us more flexibility with calling
> conventions, letting us use more of the x86 registers for passing
> arguments.  We can only make this change by removing -fvia-C, though.
> There's low hanging fruit here particularly for the x86 backend, as soon
> as we drop -fvia-C.
>
> There are other reasons to want to get rid of -fvia-C:
>
>   - it doubles the testing surface
>
>   - it's associated with a bucketload of grotesque Perl 4 code and
>     gcc-specific hacks in the RTS headers.
>
> Cheers,
> 	Simon