February 2010 - Glasgow-haskell-users

Re: Removing/deprecating -fvia-c
by Don Stewart 21 Feb '10

21 Feb '10

davidterei: > > I've been looking at some of these cases and seeing how the LLVM > back-end performs. My general impression from benchmarking the LLVM > back-end in the past has been that it generally performs with similar > characteristics as the C code generator (that is, where the C code > generator stood out compared to the NCG, so did LLVM). > > (On x86-32/Mac OS X 10.5, had some issues getting x64 working at moment): > > ./zipWith3_viac 0.72s > ./zipWith3_fasm 0.65s > ./zipWith3_llvm 0.38s Those are great numbers! I've added llvm support to ghc-core (if you compile with -fllvm, ghc-core will display the core and assembly in the pager, syntax highlighted). Unfortunately, llvm.org is down, so I can't apply patches to my llvm install at the moment, but I have managed to compile a fair few things on x86_64 -- they don't run though :-) What's the status of the x86_64 llvm backend, do you know, and are there ways to tune the optimizations that llvm applies? Should we just be using the llvm binding package on Hackage? -- Do

1 0

Confusion about GHC and GMP
by Greg Fitzgerald 20 Feb '10

20 Feb '10

I wonder if someone might be able to clear a few things up for me about implementing Integer with GMP. First, is the link below the most up-to-date information regarding GHC's situation? http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinRepl… I assume that "INTEGER_LIBRARY=integer-foo" is an option when compiling GHC itself and not when using GHC, correct? If so, what version of GHC was this added? 6.10, 6.12, HEAD? Lastly, I'm confused about GHC's posted license, should it actually be LGPL so long as it statically links GMP? Aren't there a number of companies releasing binaries that were compiled with GHC? Thanks, Greg

2 3

ghc rts selection and third party libraries
by John Lask 19 Feb '10

19 Feb '10

Hello I hope someone can provide some guidance on how I can solve a certain problem. I have a library that taps into the ghc c rts: specifically when the rts is single threaded I am pumping events in via: stg_pending_events, when the threaded rts is used I use sendIOManagerEvent. i.e. I have two versions of the library with the same api. The problem with this is that either library is only good for one context: either threaded rts or not, and the user needs to select the appropriate library to use depending on the use context. What I want to be able to do is to have ghc automatically select the compiled library version to link in depending on the which rts option is selected: "-thread" or not does any one have any ideas?

3 6

Removing/deprecating -fvia-c
by Ian Lynagh 18 Feb '10

18 Feb '10

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? Thanks Ian

11 19

Re: Removing/deprecating -fvia-c
by David Terei 18 Feb '10

18 Feb '10

Don Stewart wrote: > Here's an example that doesn't use floating point: > > import Data.Array.Vector > import Data.Bits > > main = print . sumU $ zipWith3U (\x y z -> x * y * z) > (enumFromToU 1 (100000000 :: Int)) > (enumFromToU 2 (100000001 :: Int)) > (enumFromToU 7 (100000008 :: Int)) > > In core: > > main_$s$wfold :: Int# -> Int# -> Int# -> Int# -> Int# > main_$s$wfold = > \ (sc_s1l1 :: Int#) > (sc1_s1l2 :: Int#) > (sc2_s1l3 :: Int#) > (sc3_s1l4 :: Int#) -> > case># sc2_s1l3 100000000 of _ { > False -> > case># sc1_s1l2 100000001 of _ { > False -> > case># sc_s1l1 100000008 of _ { > False -> > main_$s$wfold > (+# sc_s1l1 1) > (+# sc1_s1l2 1) > (+# sc2_s1l3 1) > (+# > sc3_s1l4 (*# (*# sc2_s1l3 sc1_s1l2) sc_s1l1)); > True -> sc3_s1l4 > }; > True -> sc3_s1l4 > }; > True -> sc3_s1l4 > } > > Rather nice! > > -fvia-C -optc-O3 > > Main_mainzuzdszdwfold_info: > cmpq $100000000, %rdi > jg .L6 > cmpq $100000001, %rsi > jg .L6 > cmpq $100000008, %r14 > jle .L10 > .L6: > movq %r8, %rbx > movq (%rbp), %rax > jmp *%rax > .L10: > movq %rsi, %r10 > leaq 1(%rsi), %rsi > imulq %rdi, %r10 > leaq 1(%rdi), %rdi > imulq %r14, %r10 > leaq 1(%r14), %r14 > leaq (%r10,%r8), %r8 > jmp Main_mainzuzdszdwfold_info > > Which looks ok. > > $ time ./zipwith3 > 3541230156834269568 > ./zipwith3 0.33s user 0.00s system 99% cpu 0.337 total > > And -fasm we get very different code, and a bit of a slowdown: > > Main_mainzuzdszdwfold_info: > .Lc1mo: > cmpq $100000000,%rdi > jg .Lc1mq > cmpq $100000001,%rsi > jg .Lc1ms > cmpq $100000008,%r14 > jg .Lc1mv > > movq %rsi,%rax > imulq %r14,%rax > movq %rdi,%rcx > imulq %rax,%rcx > movq %r8,%rax > addq %rcx,%rax > leaq 1(%rdi),%rcx > leaq 1(%rsi),%rdx > incq %r14 > movq %rdx,%rsi > movq %rcx,%rdi > movq %rax,%r8 > jmp Main_mainzuzdszdwfold_info > > .Lc1mq: > movq %r8,%rbx > jmp *(%rbp) > .Lc1ms: > movq %r8,%rbx > jmp *(%rbp) > .Lc1mv: > movq %r8,%rbx > jmp *(%rbp) > > Slower: > > $ time ./zipwith3 > 3541230156834269568 > ./zipwith3 0.38s user 0.00s system 98% cpu 0.384 total > > Now maybe we need to wait on the new backend optimizations to get there? I've been looking at some of these cases and seeing how the LLVM back-end performs. My general impression from benchmarking the LLVM back-end in the past has been that it generally performs with similar characteristics as the C code generator (that is, where the C code generator stood out compared to the NCG, so did LLVM). (On x86-32/Mac OS X 10.5, had some issues getting x64 working at moment): ./zipWith3_viac 0.72s ./zipWith3_fasm 0.65s ./zipWith3_llvm 0.38s Code that LLVM produces: _Main_mainzuzdszdwfold_entry: ## BB#0: ## %c1qP subl $12, %esp jmp LBB2_1 .align 4, 0x90 LBB2_4: ## %n1re ## Loop Depth 1 ## Loop Header is BB2_1 ## Inner Loop movl %ecx, %esi incl %ecx imull %eax, %esi incl %eax imull %edx, %esi incl %edx addl (%ebp), %esi movl %edx, 12(%ebp) movl %ecx, 8(%ebp) movl %eax, 4(%ebp) movl %esi, (%ebp) LBB2_1: ## %tailrecurse ## Loop Depth 1 ## Loop Header ## Inner Loop movl 4(%ebp), %eax cmpl $100000000, %eax jg LBB2_5 ## BB#2: ## %n1qX ## Loop Depth 1 ## Loop Header is BB2_1 ## Inner Loop movl 8(%ebp), %ecx cmpl $100000001, %ecx jg LBB2_5 ## BB#3: ## %n1r5 ## Loop Depth 1 ## Loop Header is BB2_1 ## Inner Loop movl 12(%ebp), %edx cmpl $100000008, %edx jle LBB2_4 LBB2_5: ## %c1qW movl 16(%ebp), %eax movl (%ebp), %esi addl $16, %ebp movl (%eax), %eax addl $12, %esp jmpl *%eax # TAILCALL Which is very nice. (The comments in the code are inserted by LLVM, not me). I also ran through some of the programs outlined here: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/18151 All ran with 'echo '1e-8' | ./$PRG'. 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) ======================================== ./Loops_fasm 4.53s ./Loops_viac 4.22s ./Loops_llvm 2.89s 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)) ======================================== ./Fusion_fasm 4.61s ./Fusion_viac 4.22s ./Fusion_llvm 3.62s 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)) ======================================== ./List_fasm 18.21s ./List_viac 16.71s ./List_llvm 16.92s So with these kinds of results (obviously I'm biased though since I wrote the llvm back-end) I think the sentiment that the -fvia-C approach should be eventually removed is the right way to go since with the LLVM back-end and the new code generator there is a promising and much more interesting future. ~ David

1 0

Re: Removing/deprecating -fvia-c
by scooter.phd＠gmail.com 17 Feb '10

17 Feb '10

Before the "Pile on Scooter" fest starts, bear in mind that LLVM effectively restricts you to its current backends. As the guy who started CellSPU in LLVM and who needs a good couple of research months off to finish it, think this through. Carefully. FWIW: I lead a computer systems research department for a non-for-profit in real life. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: scooter.phd(a)gmail.com Date: Wed, 17 Feb 2010 03:26:08 To: Don Stewart<dons(a)galois.com>; <glasgow-haskell-users(a)haskell.org> Subject: Re: Removing/deprecating -fvia-c It seems to me, in the absence of any other fallback, that the C backend should stay around. Assume that one is porting to a new platform, the C backend at least gives one code from which to bootstrap. Calling convention handling: weak argument IMHO for ditching. Sounds like refactoring is required, and, yes, it's platform-specific. Perl script postprocessing foo: I haven't looked at the code, but again, it sounds like platform-specific refactoring. Yes, I've looked at the web page. There's a reason why backends are messy goo and have target triples, etc. It's like Monad: not everything is pure. My vote is to keep the C backend. If it's good enough for LLVM, it's probably good enough for GHC. -scooter ------Original Message------ From: Don Stewart Sender: glasgow-haskell-users-bounces(a)haskell.org To: glasgow-haskell-users(a)haskell.org Subject: Re: Removing/deprecating -fvia-c Sent: Feb 14, 2010 09:58 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? -- Don _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sent from my Verizon Wireless BlackBerry

2 1

Re: Removing/deprecating -fvia-c
by scooter.phd＠gmail.com 17 Feb '10

17 Feb '10

It seems to me, in the absence of any other fallback, that the C backend should stay around. Assume that one is porting to a new platform, the C backend at least gives one code from which to bootstrap. Calling convention handling: weak argument IMHO for ditching. Sounds like refactoring is required, and, yes, it's platform-specific. Perl script postprocessing foo: I haven't looked at the code, but again, it sounds like platform-specific refactoring. Yes, I've looked at the web page. There's a reason why backends are messy goo and have target triples, etc. It's like Monad: not everything is pure. My vote is to keep the C backend. If it's good enough for LLVM, it's probably good enough for GHC. -scooter ------Original Message------ From: Don Stewart Sender: glasgow-haskell-users-bounces(a)haskell.org To: glasgow-haskell-users(a)haskell.org Subject: Re: Removing/deprecating -fvia-c Sent: Feb 14, 2010 09:58 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? -- Don _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sent from my Verizon Wireless BlackBerry

1 0

RE: Quasi quoting
by Simon Peyton-Jones 16 Feb '10

16 Feb '10

4 3

Re: Removing/deprecating -fvia-c
by Christian Höner zu Siederdissen 15 Feb '10

15 Feb '10

Hi, the things I am interested in are: foldU f init . mapU (\k -> array_1 !: (i,k) `combine` array_2 !: (k,j)) $ enumFromToU i j where (!:) = fancy_index_op with both `vector` and `uvector` (then D.V.fold etc). Since ghc 6.12 there has been no significant difference in using either backend. Then again, more time is spent indexing than optimising the tight loop. Viele Gruesse, Christian Hoener zu Siederdissen From: Ian Lynagh <igloo(a)earth.li> > > > 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? > > > Thanks > Ian > >

1 0

-package
by Luca Ciciriello 15 Feb '10

15 Feb '10

I've imported in my module: import Control.Concurrent.STM. My question is: Have I to use -package stm in ghc command line options? Thanks in advance. Luca.

2 1