- Glasgow-haskell-users

Why is GHC so much worse than JHC when computing the Ackermann function?
by Mikhail Glushenkov 20 Apr '13

20 Apr '13

Hi all, This came up on StackOverflow [1]. When compiled with GHC (7.4.2 & 7.6.2), this simple program: main = print $ ack 4 1 where ack :: Int -> Int -> Int ack 0 n = n+1 ack m 0 = ack (m-1) 1 ack m n = ack (m-1) (ack m (n-1)) consumes all available memory on my machine and slows down to a crawl. However, when compiled with JHC it runs in constant space and is about as fast as the straightforward Ocaml version (see the SO question for benchmark numbers). I was able to fix the space leak by using CPS-conversion, but the CPS-converted version is still about 10 times slower than the naive version compiled with JHC. I looked both at the Core and Cmm, but couldn't find anything obviously wrong with the generated code - 'ack' is compiled to a simple loop of type 'Int# -> Int# -> Int#'. What's more frustrating is that running the program with +RTS -hc makes the space leak mysteriously vanish. Can someone please explain where the space leak comes from and if it's possible to further improve the runtime of this program with GHC? Apparently it's somehow connected to the stack management strategy, since running the program with a larger stack chunk size (+RTS -kc1M) makes the space leak go away. Interestingly, choosing smaller stack chunk sizes (256K, 512K) causes it to die with an OOM exception: $ time ./Test +RTS -kc256K Test: out of memory (requested 2097152 bytes) [1] http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with… -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

3 5

GHC 7.8 release redux
by Ben Gamari 18 Apr '13

18 Apr '13

Recently I tried to parse the flurry of activity in the "GHC 7.8 release?" thread which started in early February[1]. This was quite a long thread with a number of different facets. To avoid losing points in the noise, I thought it might be useful to summarize the major points (please comment if I've missed something major), * More steeping time was necessary for a stable 7.8 release * Core APIs change too quickly, we need to try harder to decouple API-breaking releases from releases with core compiler functionality * The solution for this might be the three channel approach proposed by Mark[2] * Splitting base further might help the reduce unnecessary breakages[3]. Work has continued in this direction since the thread concluded[4]. * Tracking performance regression with periodic runs of nofib would be useful[5] Quite a productive thread for a week of wallclock time. That being said, if I'm not mistaken one matter is notably absent: what is the plan for 7.8? Will it admit API breakage? Should we establish a timeframe for getting work in before a formal release candidate is cut? Of course, "let's just wait and see" is a perfectly reasonable response but it would be nice to see it clearly set down in writing to avoid future confusion. Cheers, - Ben [1] http://www.haskell.org/pipermail/ghc-devs/2013-February/000309.html [2] http://www.haskell.org/pipermail/ghc-devs/2013-February/000386.html [3] http://www.haskell.org/pipermail/ghc-devs/2013-February/000451.html [4] http://hackage.haskell.org/trac/ghc/wiki/SplitBase [5] http://www.haskell.org/pipermail/ghc-devs/2013-February/000332.html

2 1

Re: porting to uClibc-based 686 Linux
by Dubiousjim 17 Apr '13

17 Apr '13

Am posting this follow-up to two mailing lists, because I've inquired about it on both. Previous messages are at: * http://www.haskell.org/pipermail/glasgow-haskell-users/2013-April/023912.ht… * http://lists.alpinelinux.org/alpine-devel/1699.html I have seemed to successfully cross-compile a stage2 ghc for my target system, an i686 Linux based on uClibc. One issue I don't think I've mentioned before is that the target system uses a kernel with grsecurity and PaX, and that involves patching the toolchain as well. However my cross-compiling toolchain doesn't have any such tweaks applied. This will be relevant below. Another potential issue is that my host system, a different i686 Linux based on glibc, is running inside a chroot on my target system. I don't think this is in fact responsible for any problems, but I thought I should mention it. So I last wrote on the glasgow-haskell mailing list: On Wed, Apr 03, 2013 at 10:55:14AM -0400, Dubiousjim wrote: > But there's still something funny with the binaries generated by the > compiler. That means I can't yet use this ghc to directly recompile ghc > on my target system. > > $ cat ~/hello.hs > main = putStrLn "Hello World!\n" > $ rm -f hello > $ inplace/bin/ghc-stage2 -B./inplace/lib ~/hello.hs -o hello > [1 of 1] Compiling Main ( /home/jim/hello.hs, > /home/jim/hello.o ) [flags changed] > Linking hello ... > $ ./hello > Can't modify application's text section; use the GCC option -fPIE > for > position-independent executables. > > Seems like I'm close, but not quite there yet. > > Supplying the flag -fPIE to ghc when building hello says: > > ghc-stage2: unrecognised flags: -fPIE > > The flag -fPIC on the other hand is accepted, but then the generated > binary hello still fails with the same error. Krzysztof replied to me offline (thanks Krzysztof!), but I still haven't managed to get this to work. I started thinking the difficulty came from the grsecurity or PaX features of my target system. Maybe the toolchain on the target system had been configured in a way to build binaries that would work ok on that system, but ghc wasn't yet so configured, and that's why the binaries compiled by ghc don't work. I wrote to my target system's mailing list (alpine-devel(a)lists.alpinelinux.org) expressing this fear. There was also some evidence against this hypothesis. (Test binaries I built using the cross-compiling toolchain, which hadn't been tweaked in the way the toolchain on the target system had, did build binaries that executed fine on the target; but perhaps this was just because the test programs were too simple.) But since I didn't know what was going on, this seemed worth exploring. However, I'm pretty confident I've now ruled this explanation out. Even if I build and boot from a vanilla kernel, binaries generated by the ghc-stage2 in question still fail with the error message I reported. So then I started trying to track down the error message in any sources or binaries on my system. Couldn't find it kernel or ghc sources. I did find it though in the source code for the uClibc library. It's from lines 614-681 of the file uClibc-0.9.33.2/ldso/ldso/ldso.c: ----------------------------- start ----------------------------------- /* At this point we are now free to examine the user application, * and figure out which libraries are supposed to be called. Until * we have this list, we will not be completely ready for dynamic * linking. */ /* Find the runtime load address of the main executable. This may be * different from what the ELF header says for ET_DYN/PIE executables. */ { unsigned int idx; ElfW(Phdr) *phdr = (ElfW(Phdr) *) auxvt[AT_PHDR].a_un.a_val; for (idx = 0; idx < auxvt[AT_PHNUM].a_un.a_val; idx++, phdr++) if (phdr->p_type == PT_PHDR) { DL_INIT_LOADADDR_PROG(app_tpnt->loadaddr, auxvt[AT_PHDR].a_un.a_val - phdr->p_vaddr); break; } if (DL_LOADADDR_BASE(app_tpnt->loadaddr)) _dl_debug_early("Position Independent Executable: " "app_tpnt->loadaddr=%x\n", DL_LOADADDR_BASE(app_tpnt->loadaddr)); } /* * This is used by gdb to locate the chain of shared libraries that are * currently loaded. */ debug_addr = _dl_zalloc(sizeof(struct r_debug)); ppnt = (ElfW(Phdr) *) auxvt[AT_PHDR].a_un.a_val; for (i = 0; i < auxvt[AT_PHNUM].a_un.a_val; i++, ppnt++) { if (ppnt->p_type == PT_GNU_RELRO) { relro_addr = ppnt->p_vaddr; relro_size = ppnt->p_memsz; } if (!app_mapaddr && (ppnt->p_type == PT_LOAD)) { app_mapaddr = DL_RELOC_ADDR (app_tpnt->loadaddr, ppnt->p_vaddr); } if (ppnt->p_type == PT_DYNAMIC) { dpnt = (ElfW(Dyn) *) DL_RELOC_ADDR(app_tpnt->loadaddr, ppnt->p_vaddr); _dl_parse_dynamic_info(dpnt, app_tpnt->dynamic_info, debug_addr, app_tpnt->loadaddr); #ifndef __FORCE_SHAREABLE_TEXT_SEGMENTS__ /* Ugly, ugly. We need to call mprotect to change the * protection of the text pages so that we can do the * dynamic linking. We can set the protection back * again once we are done. */ _dl_debug_early("calling mprotect on the application program\n"); /* Now cover the application program. */ if (app_tpnt->dynamic_info[DT_TEXTREL]) { ElfW(Phdr) *ppnt_outer = ppnt; ppnt = (ElfW(Phdr) *) auxvt[AT_PHDR].a_un.a_val; for (i = 0; i < auxvt[AT_PHNUM].a_un.a_val; i++, ppnt++) { if (ppnt->p_type == PT_LOAD && !(ppnt->p_flags & PF_W)) _dl_mprotect((void *) (DL_RELOC_ADDR(app_tpnt->loadaddr, ppnt->p_vaddr) & PAGE_ALIGN), (DL_RELOC_ADDR(app_tpnt->loadaddr, ppnt->p_vaddr) & ADDR_ALIGN) + (unsigned long) ppnt->p_filesz, PROT_READ | PROT_WRITE | PROT_EXEC); } ppnt = ppnt_outer; } #else if (app_tpnt->dynamic_info[DT_TEXTREL]) { _dl_dprintf(_dl_debug_file, "Can't modify application's text section; use the GCC option -fPIE for position-independent executables.\n"); _dl_exit(1); } #endif ----------------------------- end ----------------------------------- and indeed, the ghc-stage2 I built does seem to be generating position-dependent code, EVEN WHEN I TELL IT -fPIC. Whereas the native ghc on my host system doesn't do so, even when -fPIC is omitted. Witness: host$ which ghc /usr/bin/ghc host$ cat hello.hs main = putStrLn "Hello World!\n" host$ /usr/bin/ghc -o hello-host hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello-host ... There we've compiled hello-host using the host's native ghc. Now we switch over to the target system (sharing the same filesystem, and cding to the same directory): target$ rm -f hello.o hello.hi target$ inplace/bin/ghc-stage2 -o hello-cross hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello-cross ... target$ ./hello-cross Can't modify application's text section; use the GCC option -fPIE for position-independent executables. target$ rm -f hello.o hello.hi hello-cross target$ inplace/bin/ghc-stage2 -fPIC -o hello-cross hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello-cross ... target$ ./hello-cross Can't modify application's text section; use the GCC option -fPIE for position-independent executables. target$ readelf -d hello-host | fgrep TEXTREL target$ readelf -d hello-cross | fgrep TEXTREL 0x00000016 (TEXTREL) 0x0 So something has gone wrong with the way I cross-compiled or have configured this ghc-stage2. It won't build position-independent code whereas the native ghc running on my host system will. So I come back to the ghc folks for advice. I hope some readers might make it this far and have suggestions or advice about things I might try. -- dubiousjim(a)gmail.com

2 1

mask, catch, myThreadId, throwTo
by Felipe Almeida Lessa 16 Apr '13

16 Apr '13

Hey! I have some code that is not behaving the way I thought it should. The gist of it is sleeper = mask_ $ forkIOWithUnmask $ \restore -> forever $ restore sleep `catch` throwBack throwBack (Ping tid) = myThreadId >>= throwTo tid . Pong throwBack (Pong tid) = myThreadId >>= throwTo tid . Ping Since (a) throwBack is executed on a masked state, (b) myThreadId is uninterruptible, and (c) throwTo is uninterruptible, my understanding is that the sleeper thread should catch all PingPong exceptions and never let any one of them through. However, that's not what I am seeing. Running with -threaded and at least -N2 I can reliably get sleeper to be killed. Please see the complete code at: https://gist.github.com/meteficha/5390079 The expected result is 100 Pongs and 0 Pings. Running with -N1 that's what I get. Running with -N2 I get a few Pongs and then 1 Ping. Running with -N3 or more usually gives me just 1 Ping and not a single Pong. I'm testing with GHC 7.4.1. I've tried to download 7.7 but---either because of haskell.org or my ISP---I'm not being able to download it. (Note that this problem is not academic as I've been bitten by it on my production code.) Thanks! =D -- Felipe.

3 5

Using old code generator
by Roman Cheplyaka 12 Apr '13

12 Apr '13

Hi, I'm looking for a workaround for #7574 [1] (I run into it when trying to build the 'statistics' package with profiling enabled with GHC HEAD.) The symptom is ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130407 for i386-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_cCdO [1]: http://hackage.haskell.org/trac/ghc/ticket/7574 Do I understand correctly that this bug is specific to the new codegen? If so, is it possible to ask the compiler to use the old codegen? Is it okay to mix together packages compiled with both codegens? Thanks, Roman

2 2

Does GHC on cygwin have an I/O manager?
by kudah 08 Apr '13

08 Apr '13

I've been desperate to get any semblance of I/O performance from Haskell on Windows. Does ghc still build under cygwin, and if so, does the cygwin build have a working I/O manager? Also, is it possible yet to build a ghc cross-compiler targeting windows?

2 2

Problems installing 7.6.2 on MACOS
by Dominic Steinitz 07 Apr '13

07 Apr '13

Hi, I followed the instructions pointed to from here: http://www.haskell.org/ghc/download_ghc_7_6_2#macosx_x86_64 > bash-3.2$ ./configure --prefix=/Library/Haskell > bash-3.2$ sudo make install But sadly I get: > bash-3.2$ ghc-pkg list > ghc-pkg: missing --global-package-db option, location of global package database unknown and > bash-3.2$ ghc --make nnClassifier.lhs -O2 > ghc: missing -B<dir> option Any advice on how to get 7.6.2 working would be much appreciated. Dominic. Here's some more information: > bash-3.2$ which ghc-pkg > /Library/Haskell/lib/ghc-7.6.2/ghc-pkg > bash-3.2$ which ghc > /Library/Haskell/lib/ghc-7.6.2/ghc 7.4.1 still works fine: > bash-3.2$ ghc-pkg-7.4.1 list > /Library/Frameworks/GHC.framework/Versions/7.4.1-x86_64/usr/lib/ghc-7.4.1/package.conf.d: > Cabal-1.14.0 > GLUT-2.1.2.1 > bash-3.2$ ghc-7.4.1 --make nnClassifier.lhs -O2 -fforce-recomp > [1 of 6] Compiling MatrixPlus ( MatrixPlus.hs, MatrixPlus.o ) > [2 of 6] Compiling NeuralNet ( NeuralNet.hs, NeuralNet.o ) > [3 of 6] Compiling Backprop ( Backprop.hs, Backprop.o ) > [4 of 6] Compiling MarineExplore ( MarineExplore.hs, MarineExplore.o ) > [5 of 6] Compiling Runner ( Runner.hs, Runner.o ) > [6 of 6] Compiling Main ( nnClassifier.lhs, nnClassifier.o ) > Linking nnClassifier ... > ld: warning: directory not found for option '-L/opt/local/lib/' > bash-3.2$ ./nnClassifier > Reading training labels... > Read 100 labels[(1,0),(2,1),(3,0),(4,1),(5,0),(6,0),(7,1),(8,0),(9,1),(10,0)] > Reading training images... > 9:9 > 9:9

2 2

Allowing (Char ~ Bool => Void)?
by Shachaf Ben-Kiki 05 Apr '13

05 Apr '13

Is there a good reason that GHC doesn't allow any value of type (Char ~ Bool => Void), even undefined? There are various use cases for this. It's allowed indirectly, via GADT pattern matches -- "foo :: Is Char Bool -> Void; foo x = case x of {}" (with EmptyCase in HEAD) -- but not directly. One thing this prevents, for instance, is CPSifying GADTs: data Foo a = a ~ Char => A | a ~ Bool => B -- valid newtype Bar a = Bar { runBar :: forall r. (a ~ Char => r) -> (a ~ Bool => r) -> r } -- unusable Trying to use a type like the latter in practice runs into problems quickly because one needs to provide an absurd value of type (Char ~ Bool => r), which is generally impossible (even if we're willing to cheat with ⊥!). It seems that this sort of thing should be doable. Shachaf

4 6

ImplicitParams and MonoLocalBinds
by Roman Cheplyaka 03 Apr '13

03 Apr '13

The value of the following expression let ?y = 2 in let p = ?y in let ?y = 1 in p depends on whether the second binding is generalised. MonomorphismRestriction makes it not generalise, hence the value is 2. What surprises me is that MonoLocalBinds doesn't have this effect. Prelude> :set -XImplicitParams -XNoMonomorphismRestriction -XMonoLocalBinds Prelude> let ?y = 2 in let p = ?y in let ?y = 1 in p 1 What's going on here? Roman

3 4

Re: porting to uClibc-based 686 Linux
by Dubiousjim 03 Apr '13

03 Apr '13

On Wed, Apr 03, 2013 at 09:56:58AM -0400, Dubiousjim wrote: > Ok, with all of that, the build completes. And the build ghc-stage2 > (which I temporarily named inplace/lib/ghc-stage2.exe, but now let's > restore it to its original name) does in fact execute on the target > machine: > > $ inplace/lib/ghc-stage2 --version > The Glorious Glasgow Haskell Compilation System, version 7.6.2 > $ inplace/lib/ghc-stage2 --interactive > ghc-stage2: missing -B<dir> option > $ cat ~/hello.hs > main = putStrLn "Hello World!\n" > $ inplace/lib/ghc-stage2 -B./inplace/lib ~/hello.hs -o hello > $ ./hello > Can't modify application's text section; use the GCC option -fPIE > for > position-independent executables. > > That's as far as I've got for now. Hopefully someone will have > bothered to read this far and have some suggestions for what I should be > doing differently, or how to proceed from here, to get the compiled > ghc-stage2 really working on the target machine, so that I can use it to > compile ghc on the target machine directly. Oh, in fact I'm closer than I thought. The error I reported as: > $ inplace/lib/ghc-stage2 -B./inplace/lib --interactive > GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... ghc-stage2: mmap 442368 bytes at (nil): > Operation not permitted > ghc-stage2: Try specifying an address with +RTS -xm<addr> -RTS is in fact due to my forgetfulness. My target system uses PaX kernel security, and so compilers like ghc have to be tweaked before they can be used: $ paxctl -c inplace/lib/ghc-stage2 $ paxctl -m inplace/lib/ghc-stage2 $ inplace/bin/ghc-stage2 -B./inplace/lib --interactive GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> Yay, the interpreter works! But there's still something funny with the binaries generated by the compiler. That means I can't yet use this ghc to directly recompile ghc on my target system. $ cat ~/hello.hs main = putStrLn "Hello World!\n" $ rm -f hello $ inplace/bin/ghc-stage2 -B./inplace/lib ~/hello.hs -o hello [1 of 1] Compiling Main ( /home/jim/hello.hs, /home/jim/hello.o ) [flags changed] Linking hello ... $ ./hello Can't modify application's text section; use the GCC option -fPIE for position-independent executables. Seems like I'm close, but not quite there yet. Supplying the flag -fPIE to ghc when building hello says: ghc-stage2: unrecognised flags: -fPIE The flag -fPIC on the other hand is accepted, but then the generated binary hello still fails with the same error. -- dubiousjim(a)gmail.com

1 0