- Glasgow-haskell-users

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

buildbot status
by Karel Gardas 14 Feb '10

14 Feb '10

Hello, as per GHC wiki (http://hackage.haskell.org/trac/ghc/wiki/BuildBot) its buildbot should be accessible either on http://darcs.haskell.org/buildbot or on http://darcs.haskell.org:8010. The first one return 404 page not found and the second tries to connect forever. May I ask what's the correct url for buildbot web page? Thanks, Karel

2 1

How to get the file descriptor of a handle?
by Volker Wysk 14 Feb '10

14 Feb '10

Hello I'd like to know how you get the file descriptor, which is incapsulated in a handle. The libraries GHC.IO.Handle/GHC.IO.Handle.FD only provide for the other direction. The function haFD, which I've used before I've updated to the current version of GHC (6.12), appears to be in use two times in the libraries. But there isn't a definition anywhere. Any help would be appreciated. Cheers, Volker -- Volker Wysk <pf3(a)volker-wysk.de>

2 1

Fw: Re: Re[2]: No more ExitException? <- documentation bug
by Volker Wysk 13 Feb '10

13 Feb '10

The following message went to Bulat Ziganshin alone. So here it is for the mailing list. Sorry. Begin forwarded message: On Wed, 27 Jan 2010 12:43:13 +0300 Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: > > exitWith throws the ExitCode when it is called. This leads to the > > shutdown of the program, if it isn't caught. Just like ExitException. > > > This isn't documented. > > i've googled for "exitWith throws the ExitCode" and it pointed me to > the exitWith docs: "Computation exitWith code throws ExitException code." This is the source code of exitWith: -------------------------snip----------------------------- -- --------------------------------------------------------------------------- -- exitWith -- | Computation 'exitWith' @code@ throws 'ExitException' @code@. -- Normally this terminates the program, returning @code@ to the -- program's caller. Before the program terminates, any open or -- semi-closed handles are first closed. -- -- A program that fails in any other way is treated as if it had -- called 'exitFailure'. -- A program that terminates successfully without calling 'exitWith' -- explicitly is treated as it it had called 'exitWith' 'ExitSuccess'. -- -- As an 'ExitException' is not an 'IOError', 'exitWith' bypasses -- the error handling in the 'IO' monad and cannot be intercepted by -- 'catch' from the "Prelude". However it is an 'Exception', and can -- be caught using the functions of "Control.Exception". This means -- that cleanup computations added with 'Control.Exception.bracket' -- (from "Control.Exception") are also executed properly on 'exitWith'. #ifndef __NHC__ exitWith :: ExitCode -> IO a exitWith ExitSuccess = throwIO ExitSuccess exitWith code@(ExitFailure n) | n /= 0 = throwIO code #ifdef __GLASGOW_HASKELL__ | otherwise = ioError (IOError Nothing InvalidArgument "exitWith" "ExitFailure 0" Nothing) #endif #endif /* ! __NHC__ */ -------------------------snip----------------------------- As you can see, it throws the ExitCode, not an ExitException. The documentation is faulty. Cheers, Volker -- Volker Wysk <vw(a)volker-wysk.de> -- Volker Wysk <vw(a)volker-wysk.de>

2 1

Overlapping Instances + Existentials = Incoherent Instances
by Dan Doel 10 Feb '10

10 Feb '10

Greetings, I've actually known about this for a while, but while discussing it, it occurred to me that perhaps it's something I should report to the proper authorities, as I've never seen a discussion of it. But, I thought I'd start here rather than file a bug, since I'm not sure it isn't intended. Anyhow, here's the example: class C a where foo :: a -> String instance C a where foo _ = "universal" instance C Int where foo _ = "Int" bar :: a -> String bar x = foo x Now, normally bar generates a complaint, but if you enable IncoherentInstances, it's accepted, and it always generates "universal", even if called with an Int. Adding a 'C a' constraint to the type makes it give "Int" in the case of an Int. Now, IncoherentInstances is something most people would suggest you don't use (even people who are cool with OverlappingInstances). However, it turns out that ExistentialQuantification does the same thing, because we can write: data Ex = forall a. Ex a baz :: a -> String baz x = case Ex x of Ex x' -> foo x' and this is accepted, and always yields "universal", just like bar. So, things that you get out of an existential are allowed to make use of the general versions of overlapping instances if any fit. So, I never really regarded this as anything more than an oddity that's unlikely to come up. And it might be working as intended. But I thought perhaps I should ask: is this intended? One could probably build a case that baz should only be accepted if IncoherentInstances are enabled, since it's doing about the same thing. I'm not really sure how far back this behavior goes. I've probably known about it for several 6.X releases without mentioning it except as a fun party fact (apologies). Is this the way things are supposed to work? (And sorry if I just missed the discussion somewhere. I searched the trac and didn't see anything very promising.) Cheers, -- Dan

3 3