- Glasgow-haskell-users

Re: Quasi quoting
by Dave Bayer 22 Feb '10

22 Feb '10

Perhaps I missed this or I'm missing something, but seeing a mention of quasiquoting on another thread, I reread this entire thread just now before posting. If by "stealing syntax" we mean that the odd programmer who writes illegiblelinenoisewithoutspaceshastoaddtheoddspacehereandthere, then fine, sorry about the long post which you may freely ignore. What I read when I see "stealing syntax" is that a proposal makes some prior code impossible to write. Please clarify. I have no trouble distinguishing visually between the following forms [hex| 1.fffffp+1023 |] [ hex | hex <- [ 0..8 ] ] for two different reasons: [1] I'd never leave out the spaces for the list comprehension, while I'd always leave out the spaces for quasiquoting. [2] It's completely obvious to a human reader that the first form can't be a list comprehension, because of the trailing |] which would be a parse error. Let's recall that indentation-based parsing like we use in Haskell, Python was once radical, and still jars some people. Spaces are already significant for everyone, this just leans on them a bit more. A Lisp programmer would have no issues distinguishing these forms, because [hex| is a single token for the Lisp programmer. A freshman parser for quasiquoting would get this right by accident, failing to catch the quasiquoting that used spaces, falling correctly through to the list comprehension. More generally, humans always resolve ambiguity by parsing several ways in parallel, and accepting the highest priority parse that succeeds. I always expect computer languages to work this way, and my heart is always broken. Why can't Haskell evolve in this direction, as proposals like this increase its code density? Reading "Coders at Work", all of my coding zombie masters abandoned Lisp (as I did) because code density is a Good Thing. It's a mild nuisance to wait on the closing |] to decide, but only a mild nuisance. This reminds me of heredocs, where a traditional (e.g. Perl) heredoc help prog = <<“EOF” Usage: “prog” input output “prog” -h original input output EOF looks like it's stealing syntax, but there is utterly no issue at all, if one waits till the end to resolve the ambiguity, giving priority to a correct heredoc. (I need to wait till the end in any case to steal the indent.) Somehow this was never accepted as a reasonable idea in the heredoc thread either, yet I took this from working code that my custom literate preprocessor handles without incident. So what am I missing? Require no spaces to open quasiquoting, and/or require |] to close quasiquoting, falling through to whatever else Haskell will accept if these conditions aren't met? Then it remains possible to code any list comprehension. On Jan 31, 2010, at 10:50 PM, Simon Peyton-Jones wrote: > So the proposed change will make things *more* uniform, by grabbing every > "[blah|" as lexeme. On Feb 1, 2010, at 1:43 AM, Malcolm Wallace wrote: > I am not myself a TH or QQ user, but it has always bothered me slightly that the syntax for them steals some valid list comprehensions. On Feb 22, 2010, at 5:15 AM, Simon Peyton-Jones wrote: > Or, alternatively, use quasiquoting > > [hex| 1.fffffp+1023 |]

1 0

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