- Glasgow-haskell-users

Re: [Haskell-cafe] A problem with par and modules boundaries...
by Duncan Coutts 23 May '09

23 May '09

On Fri, 2009-05-22 at 05:30 -0700, Don Stewart wrote: > Answer recorded at: > > http://haskell.org/haskellwiki/Performance/Parallel I have to complain, this answer doesn't explain anything. This isn't like straight-line performance, there's no reason as far as I can see that inlining should change the operational behaviour of parallel evaluation, unless there's some mistake in the original such as accidentally relying on an unspecified evaluation order. Now, I tried the example using two versions of ghc and I get different behaviour from what other people are seeing. With the original code, (ie parallelize function in the same module) with ghc-6.10.1 I get no speedup at all from -N2 and with 6.11 I get a very good speedup (though single threaded performance is slightly lower in 6.11) Original code ghc-6.10.1, -N1 -N2 real 0m9.435s 0m9.328s user 0m9.369s 0m9.249s ghc-6.11, -N1 -N2 real 0m10.262s 0m6.117s user 0m10.161s 0m11.093s With the parallelize function moved into another module I get no change whatsoever. Indeed even when I force it *not* to be inlined with {-# NOINLINE parallelize #-} then I still get no change in behaviour (as indeed I expected). So I view this advice to force inlining with great suspicion (at worst it encourages people not to think and to look at it as magic). That said, why it does not get any speedup with ghc-6.10 is also a mystery to me (there's very little GC going on). Don: can we change the advice on the wiki please? It currently makes it look like a known and understood issue. If anything we should suggest using a later ghc version. Duncan

2 1

ANNOUNCE: GHC version 6.10.3
by Ian Lynagh 23 May '09

23 May '09

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.10.3 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 6.10.2 and better line editing support in GHCi, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.10.3/html/users_guide/release-6-10-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

4 6

Re: [Haskell-cafe] A problem with par and modules boundaries...
by Duncan Coutts 23 May '09

23 May '09

On Fri, 2009-05-22 at 16:34 +0200, Daniel Fischer wrote: > > That's great, thank you. I am still baffled, though. I'm baffled too! I don't see the same behaviour at all (see the other email). > > Must every exported function that uses `par' be INLINEd? Does every > > exported caller of such a function need the same treatment? It really should not be necessary. > > Is `par' really a macro, rather than a function? It's a function. > As far as I understand, par doesn't guarantee that both arguments are > evaluated in parallel, it's just a suggestion to the compiler, and if > whatever heuristics the compiler uses say it may be favourable to do > it in parallel, it will produce code to calculate it in parallel > (given appropriate compile- and run-time flags), otherwise it produces > purely sequential code. > > With parallelize in a separate module, when compiling that, the > compiler has no way to see whether parallelizing the computation may > be beneficial, so doesn't produce (potentially) parallel code. At the > use site, in the other module, it doesn't see the 'par', so has no > reason to even consider producing parallel code. I don't think this is right. As I understand it, par always creates a spark. It has nothing to do with heuristics. Whether the spark actually gets evaluated in parallel depends on the runtime system and whether the spark "fizzles" before it gets a chance to run. Of course when using the single threaded rts then the sparks are never evaluated in parallel. With the threaded rts and given enough CPUs, the rts will try to schedule the sparks onto idle CPUs. This business of getting sparks running on other CPUs has improved significantly since ghc-6.10. The current development version uses a better concurrent queue data structure to manage the spark pool. That's probably the underlying reason for why the example works well in ghc-6.11 but works badly in 6.10. I'm afraid I'm not sure of what exactly is going wrong that means it doesn't work well in 6.10. Generally I'd expect the effect of par to be pretty insensitive to inlining. I'm cc'ing the ghc users list so perhaps we'll get some expert commentary. Duncan

2 1

Mac OS X 64bit unregisterised port
by Ian Lynagh 23 May '09

23 May '09

Hi all, There is an unregisterised bindist for Mac OS X 64bit here: http://www.haskell.org/ghc/dist/current/ports/ghc-6.11.20090521-x86_64-appl… Thanks Ian

2 2

ANNOUNCE: GHC porting works again
by Ian Lynagh 22 May '09

22 May '09

Hi all, The instructions for porting GHC to a new architecture now work again with the HEAD: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting If you get stuck when trying to do a port, then please feel free to ask us on cvs-ghc(a)haskell.org or in #ghc on freenode. Thanks Ian

1 0

Closure elimination transformation (continuation style passing code)
by Tyson Whitehead 20 May '09

20 May '09

I was wondering about GHC's ability to optimize the following code module Test (test) where newtype Step a b = Step { unStep :: (a -> Step a b -> b) -> b -> b } iter :: [a] -> (a -> Step a b -> b) -> b -> b iter [] next done = done iter (x:xs) next done = next x (Step $ iter xs) count :: Int -> Char -> Step Char Int -> Int count i x step = unStep step (count $ i+1) (i+1) test :: String -> Int test xs = iter xs (count 0) 0 (test implements the string length function). The transformations steps that reduce this to the optimized version are 1- avoid forming the (iter xs) and (count i+1) closures by passing the function and the arguments instead of the function bound to the argument iter [] next i done = done iter (x:xs) next i done = next i x iter xs count i x step xs = step xs count (i+1) (i+1) test xs = iter xs count 0 0 2- specialize count for step = iter iter [] next i done = done iter (x:xs) next i done = next i x iter xs count i x xs = iter xs count (i+1) (i+1) test xs = iter xs count 0 0 3- specializing iter for next = count iter [] i done = done iter (x:xs) i done = count i x iter xs count i x xs = iter xs (i+1) (i+1) test xs = iter xs 0 0 4- inline count iter [] i done = done iter (x:xs) i done = iter xs (i+1) (i+1) test xs = iter xs 0 0 5- eliminate the done argument as it is always the same as the i argument iter [] i = i iter (x:xs) i = iter xs (i+1) test xs = iter xs 0 Currently 6.10.1 with -O2 seems stuck with regard to step 1 (eliminating the closures). Is there any hope of getting it to these transformations? Thanks! -Tyson

4 7

baffling manual sections
by Jason Dusek 20 May '09

20 May '09

I'm a little puzzled by these seeming duplicate pages in the manual: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.ht… http://www.haskell.org/ghc/dist/current/docs/users_guide/data-type-extensio… They give slightly different section numbers to similar stuff. The former page also has a curious discussion of standalone deriving with a `for` keyword: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.ht… -- Jason Dusek

4 7

6.8.1 on ubuntu jaunty
by Martin Matusiak 20 May '09

20 May '09

Hello, I need ghc 6.8.1 for a codebase that depends on it and I'm having trouble building it on the current ubuntu. Error output attached. Martin configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h Configuring network-2.1.0.0... rm -f network/GNUmakefile cp Makefile.local network if ifBuildable/ifBuildable network; then \ cd network && setup/Setup makefile -f GNUmakefile; \ fi Socket.hsc: In function ‘main’: Socket.hsc:1143: error: invalid application of ‘sizeof’ to incomplete type ‘struct ucred’ Socket.hsc:1143: error: invalid application of ‘sizeof’ to incomplete type ‘struct ucred’ Socket.hsc:1143: error: invalid application of ‘sizeof’ to incomplete type ‘struct ucred’ Socket.hsc:1149: error: invalid use of undefined type ‘struct ucred’ Socket.hsc:1150: error: invalid use of undefined type ‘struct ucred’ Socket.hsc:1151: error: invalid use of undefined type ‘struct ucred’ compiling dist/build/Network/Socket_hsc_make.c failed command was: gcc -c -D__GLASGOW_HASKELL__=608 -I/tmp/ghc-6.8.1/includes -I/tmp/ghc-6.8.1/gmp/gmpbuild -D__GLASGOW_HASKELL__=608 -DCALLCONV=ccall -Iinclude dist/build/Network/Socket_hsc_make.c -o dist/build/Network/Socket_hsc_make.o Preprocessing library network-2.1.0.0... make[1]: *** [network/GNUmakefile] Error 1 make[1]: Leaving directory `/tmp/ghc-6.8.1/libraries' make: *** [stage1] Error 2

1 0

Re: strictness of interpreted haskell implementations
by Geraint Jones 18 May '09

18 May '09

Sorry to revive a year-old thread, but... On Fri, 25 Apr 2008 at 20:17:53 +0100 Duncan Coutts wrote: > On Fri, 2008-04-25 at 09:08 -0700, Don Stewart wrote: > > Geraint.Jones: > > > Are there well-known differences in the implementations of Haskell in > > > ghci and hugs? I've got some moderately intricate code (simulations > > > of pipelined processors) that behave differently - apparently because > > > ghci Haskell is stricter than hugs Haskell, and I cannot find any > > > obviously relevant claims about strictness in the documentation. > > I think they should give the same answer. It sounds like a bug in one > implementation or the other. > > > Hugs does no optimisations, while GHC does a truckload, including > > strictness analysis. Some of these optimisations prevent space leaks. > > Though none should change the static semantics. > > Post the code. Even if you don't have time to track down the difference, > someone might. At the time I was reluctant to impose all the code on anyone and I found it hard to cut the example down to a manageable size. I've just got it down to a one-liner: it's the implementation of what I think ought to be strict fields in records: data S = S { a :: Int, b :: ! Int } I think ghci is correct: *Main> a (S { a = 0, b = 1 }) 0 *Main> a (S { a = 0, b = undefined }) *** Exception: Prelude.undefined and that hugs had been concealing a bug in my program by not demanding one of the fields of S when it ought to: Main> a (S { a = 0, b = 1 }) 0 Main> a (S { a = 0, b = undefined }) 0 Ho hum. Is this a "known difference"? (What makes you think I'm teaching the same course again this year?)

4 3

possible alternative to libFFI
by Bulat Ziganshin 18 May '09

18 May '09

Hello glasgow-haskell-users, http://www.nongnu.org/cinvoke/faq.html -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 3