- Glasgow-haskell-users

RE: Optimization beyond the Module Border
by Matthew Pocock 21 Mar '08

21 Mar '08

> | > I'd be interested in any progress here -- we noticed issues with > | > optimisations in the stream fusion package across module boundaries > | > that we never tracked down. If there's some key things not firing, > | > that would be good to know. > | > | I suspect that if all modules are compiled -O0, then you recompile one > | module with -O2, high up in the dependency graph (i.e. it depends on > | many lower-level modules), plus all things that in turn depend on it > | (--make), you will not get the good performance you expect. None of the > | lower-level functions will have exported inlinings or fusion rules into > | the interface file. _All_ modules must be recompiled with -O2, > | especially the bottom of the dependency chain, to get the best benefit > | from optimisation. > > Absolutely correct. > > Should this be better documented? If so, would someone like to think > where in GHC's user manual they would have looked (or did look), and send > me some text that would have helped them, had it been there? As it were. > > Simon Would it be possible for the compiler to say something like: "You are applying level 2 optimization but some dependencies where compiled without optimization enabled. To get full optimization, consider recompiling x,y,z with -O2" - at least this would give us a fighting chance to 'fix' things. Matthew > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

2 1

Type checking of partial programs
by ac 21 Mar '08

21 Mar '08

Is anybody interested in working on this? This is a project I've been interested in for some time, but recognize I probably need some guidance before I go off and start hacking on it. As dcoutts pointed out on #haskell-soc, this may be of particular interest to people working on yi and HaRe. Other interesting and related projects include parsing partial programs to insert "placeholders" in appropriate places. An example of a partial program could be: foo :: [Foo] -> <placeholder 1> foo xs = map <placeholder 2> xs What are the possible type signatures for placeholder 1 and the possible expressions for placeholder 2? I would like to stir up a discussion about this, and eventually write some useful code. -Abram

2 1

Bug: GHC hangs rather than reporting an occurs check error
by Bryan Donlan 20 Mar '08

20 Mar '08

Hi all, I've found a case where GHC will hang (consuming more and more memory) when it should report an occurs check error. The test case is at http://fushizen.net/~bd/kaos-ghc.loop.tgz - the error in question is that the arguments in the StateT instance for HOLift are reversed like so: diff --git a/src/Kaos/KaosM.hs b/src/Kaos/KaosM.hs index ec4e69a..268250a 100644 --- a/src/Kaos/KaosM.hs +++ b/src/Kaos/KaosM.hs @@ -88,7 +88,7 @@ genlift' unbox box f m = box $ \s -> f (unbox m s) class HOLift m b | m -> b where genlift :: (forall r'. b r' -> b r') -> (forall r. m r -> m r) -instance HOLift m (StateT s m) where +instance HOLift (StateT s m) m where genlift = genlift' runStateT StateT instance (HOLift m b, KaosDiagM r b) => KaosDiagM r m where Thanks, Bryan Donlan

2 4

Optimization beyond the Module Border
by Bernd Brassel 20 Mar '08

20 Mar '08

Hi all, I have noticed that there is a great difference between optimizing modules separately and all at once, e.g., with -fforce-recomp. I have had examples factors up to 15 in run time (and even different behavior in context with unsafePerformIO). Is there any option that makes ghc write out that intermediate optimization data he seems to use in order to get the same efficiency in a module-wise compilation? Greetings Bernd

5 9

Re: [GHC] #2163: GHC makes thunks for Integers we are strict in
by Ian Lynagh 19 Mar '08

19 Mar '08

On Tue, Mar 18, 2008 at 04:12:35PM -0000, GHC wrote: > > > W.f = > > \ (x_a5h :: GHC.Num.Integer) -> > > let { > > x'_sa7 [ALWAYS Just S] :: GHC.Num.Integer > > [Str: DmdType] > > x'_sa7 = GHC.Num.plusInteger x_a5h W.lvl } in > > GHC.Num.timesInteger x'_sa7 x'_sa7 > > `let` can be strict in Core - it doesn't always indicate a thunk. Aha! I knew that let was strict for types like Int#, but didn't realise that it could be for "normal" types too. What is it in the above let that shows that it will be evaluated strictly? The "Just S"? Also, what is the advantage to having strictly evaluated let's, both for unboxed and normal types? Presumably it helps with some optimisation - perhaps let-bound things might be inlined, whereas case'd things aren't, which reduces the number of cases the optimiser needs to consider, or something? > (don't worry, this often catches me out too. Perhaps a strict let > should be indicated more explicitly in `-ddump-simpl`). I'd certainly find it useful if it was clearer. Thanks Ian

2 2

Bug or not-yet-supported?
by Niklas Broberg 17 Mar '08

17 Mar '08

I haven't payed much attention to how much of type families is/should be implemented for 6.8.2. What of equality constraints? The following parses alright, but can't be used it seems. ------------------------------------ module Foo where class C a where proof :: a instance (a ~ Int) => C a where proof = 1 ------------------------------------ %> ghci -fglasgow-exts -XUndecidableInstances Foo.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, modules loaded: Foo. *Foo> proof :: Int : panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-mingw32): nameModule $dC{v aoz} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ------------------------------------ I would follow that last advice if I knew this was *supposed* to work. :-) Cheers, /Niklas

2 2

timer_create
by Christian Maeder 16 Mar '08

16 Mar '08

Hi, my binary distribution http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-unknown-linux.t… creates binaries that fail on some i386 linux boxes with: timer_create: Invalid argument I've built the distribution with gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) and the file lib/ghc-6.8.2/include/ghcautoconf.h contains: #define HAVE_TIMER_CREATE 1 The failing machine uses gcc version 3.3.5 and ./configure within the ghc-6.8.2 sources says: checking for a working timer_create(CLOCK_REALTIME)... no Take this as a warning when using my binary-dist above (or when building your own). Or is there a work around (apart from creating a new binary-dist using ghc-6.6.1)? Cheers Christian

4 6

Making rule application less fragile
by Johan Tibell 14 Mar '08

14 Mar '08

Hi, I'm trying (for the first time ever) to use RULES pragmas to achieve some nice speedups in my bytestring parsing library. The relevant code in my library's module is: -- The module imports Control.Applicative which containes 'many' and 'some'. -- | The parser @satisfy p@ succeeds for any byte for which the -- supplied function @p@ returns 'True'. Returns the byte that is -- actually parsed. satisfy :: (Word8 -> Bool) -> Parser Word8 satisfy p = Parser $ \s@(S bs pos eof) succ fail -> case S.uncons bs of Just (b, bs') -> if p b then succ b (S bs' (pos + 1) eof) else fail s Nothing -> if eof then fail s else IPartial $ \x -> case x of Just bs' -> retry (S bs' pos eof) Nothing -> fail (S bs pos True) where retry s' = unParser (satisfy p) s' succ fail -- | @byte b@ parses a single byte @b@. Returns the parsed byte -- (i.e. @b@). byte :: Word8 -> Parser Word8 byte b = satisfy (== b) -- --------------------------------------------------------------------- -- Rewrite rules satisfyMany :: (Word8 -> Bool) -> Parser S.ByteString satisfyMany p = undefined -- More efficient implementation goes here. satisfySome :: (Word8 -> Bool) -> Parser S.ByteString satisfySome p = undefined -- More efficient implementation goes here. {-# RULES "fmap/pack/many/satisfy" forall p. fmap S.pack (many (satisfy p)) = satisfyMany p "fmap/pack/some/satisfy" forall p. fmap S.pack (some (satisfy p)) = satisfySome p #-} In another module where I use the library I have this code: pHeaders :: Parser [(S.ByteString, S.ByteString)] pHeaders = many header where header = liftA2 (,) fieldName (byte (c2w ':') *> spaces *> contents) fieldName = liftA2 (S.cons) letter fieldChars contents = liftA2 (S.append) (fmap S.pack $ some notEOL <* crlf) (continuation <|> pure S.empty) continuation = liftA2 (S.cons) ((c2w ' ') <$ some (oneOf (map c2w " \t"))) contents -- It's important that all three of these definitions are kept on the -- top level to have RULES fire correctly. fieldChars = fmap S.pack $ many fieldChar -- fieldChar = letter <|> digit <|> oneOf (map c2w "-_") fieldChar = satisfy isFieldChar where isFieldChar b = (isDigit $ chr $ fromIntegral b) || (isAlpha $ chr $ fromIntegral b) || (b `elem` map c2w "-_") I want the fieldChars use of 'fmap S.pack $ many fieldChar' to trigger my rewrite rule "fmap/pack/many/satisfy" which it does in this case. The trouble is that the rule only triggers when I make at least fieldChars and fieldChar top-level definition and isFieldChar either a named local definition in fieldChar or a top-level definition. If I turn the predicate (isFieldChar) into to an anonymous lambda function it doesn't trigger, if I make either fieldChars or fieldChars a local defintion (in a where clause) of pHeaders it doesn't trigger. If I make fieldChar a local definition in fieldChars it doesn't trigger, etc. It would be great if there was a way to make this a bit less fragile and have the rule trigger more often as it is potentially a huge performance win. I understand it's hard to guarantee that the rule always triggers but now it triggers in rare cases. -- Johan

3 5

Re: ANN: ghc 6.8.2 from MacPorts
by Christian Maeder 14 Mar '08

14 Mar '08

Hi Greg, I can't test it myself because I don't have root access to our machines. Maybe someone else can? (Meanwhile I'll try to make a binary-dist that includes the extra-libs.) Cheers Christian Gregory Wright wrote: > > Hi Christian, > > I built a new bootstrapping compiler on Tiger/ppc, incorporating > Thorkil's .text section > patch. I've modified the portfile, but since I don't have a Leopard/ppc > machine I can't > try it. Could you give it a go? > > Do > > $ sudo port selfupdate > $ sudo port clean --all ghc > $ sudo port -dv install ghc > inst.log 2>&1 > > You might want to check after the selfupdate that you have revision 2 of > the ghc portfile. > It may take a few hours for the server to index the port and make it > available by rsync. > > If it fails, you can compress the log and send it to me. The "-dv" > flags dump all of the > MacPorts and build information. > > There may still be a stupid bug or two since I can't test it myself. > > Thanks, > Greg >

1 0

setlocale
by Tristan Allwood 14 Mar '08

14 Mar '08

Hi, I've been playing around with hs-curses and utf8, and have discovered that I need to use an ffi call at the top of my main to setlocale(LC_ALL, "") in order to get the hscurses bindings to display utf8-encoded strings correctly. If I understand correctly, the fact that I need to do this means that the ghc rts is either not setting the default locale, or is forcing it to be a c-style one. With that as my context I'm just wondering: a) if this is a known issue b) if there's a known work-around other than rolling your own ffi wrapped call (a library function that I'm not aware of) c) any side effects this might have elsewhere d) if I'm being stupid and could get this to work by just using env vars Regards, Tristan Allwood 21:23:39 - tora@colorado:~ >locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= >ghc -v Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.1 >uname -a Linux colorado 2.6.24-1-amd64 #1 SMP Mon Feb 11 13:47:43 UTC 2008 x86_64 GNU/Linux -- Tristan Allwood PhD Student Department of Computing Imperial College London

4 5