RE: [Haskell] Re: indirectly recursive dictionaries
[Redirecting to GHC users.] | Tom Schrijvers wrote: | The cyclic dictionaries approach is a bit fragile. The problem appears to | be here that GHC alternates exhaustive phases of constraint reduction and | functional dependency improvement. The problem is that in your example you | need both for detecting a cycle. The whole thing relies on spotting a loop, and that's inherently a bit fragile. I don't know of any formal work on the subject, although I bet there is some. GHC's current algorithm does not run functional dependencies sufficiently aggressively, because it treats fundeps a different kind of thing to class constraints. Our new solver, long promised but still in the works, fully integrates type classes with type equalities (fundeps, type functions etc), and so should do a better job here. Roughly speaking, the idea is to combine our ICFP'08 paper [1] with a type-class solver. Since writing the ICFP'08 paper we have found some very useful simplifications; and we also have a new plan for the solving strategy OutsideIn [2]. That said, solving recursive problems is not our primary focus right now -- getting it working is -- so I can't promise that it'll do a better job, but I think it will. | It seems we can convince GHC to do constraint reduction and | improvement in the order we desire. The key is to use the | continuation-passing style -- which forces things to happen in the | right order, both at the run-time and at the compile time. Oleg you are a master at persuading GHC's somewhat ad-hoc implementation to dance to your tune. But it'd be better just to make the implementation more complete in the solutions it finds. That's what we are working on now. Simon [1] http://research.microsoft.com/~simonpj/papers/assoc-types/index.htm [2] http://research.microsoft.com/~simonpj/papers/gadt ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under Solaris: GHC 6.10.2 Release Candidate 1
Duncan Coutts wrote: On Tue, 2009-03-17 at 11:09 +0100, Christian Maeder wrote: ./bootstrap.sh: !: not found Under Solaris sh is not bash! Indeed. According to the OpenGroup that syntax should be fine: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_02 It works for me under Solaris 10. Perhaps Solaris 9 or older do not have a standard compliant /bin/sh program. What do you suggest we use instead as a workaround? The Isabelle people use #!/usr/bin/env bash as first line. Btw I had this problem under Solaris 10 (but I don't know how it was installed). Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under Solaris: GHC 6.10.2 Release Candidate 1
On Tue, 2009-03-17 at 21:12 -0400, Brandon S. Allbery KF8NH wrote:
On 2009 Mar 17, at 20:28, Duncan Coutts wrote:
It works for me under Solaris 10. Perhaps Solaris 9 or older do not
have a standard compliant /bin/sh program. What do you suggest we use
instead as a workaround?
For backward compatibility reasons sh in Solaris 9 and earlier is not
POSIX compliant. Use /usr/xpg4/bin/sh or /bin/bash instead.
(Unfortunately you can't cheat and define a shell function, although
you could create a program called !:
if ${1+$@}; then
exit 1
else
exit 0
fi
Actually this is what the script used 'til someone pointed out to me
that sh has the ! syntax :-). I'll switch it back to using this style
with a note to say why.
Duncan
- ! grep ${PKG}-${VER_MATCH} ghc-pkg.list /dev/null 21
+ if grep ${PKG}-${VER_MATCH} ghc-pkg.list /dev/null 21
+ then
+return 1;
+ else
+return 0;
+ fi
+ #Note: we cannot use ! grep as Solaris 9 /bin/sh doesn't like it.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as a bootstrap compiler. The build was done using the MacPorts infrastructure. Summary test results: OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 2334 total tests, which gave rise to 12487 test cases, of which 0 caused framework failures 2460 were skipped 9709 expected passes 258 expected failures 0 unexpected passes 60 unexpected failures Unexpected failures: 2469(ghci) apirecomp001(normal) bits (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) conc049(hpc) conc068(normal) derefnull(profc,profthreaded) divbyzero(profc,profthreaded) genUpTo (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) num009 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) num012 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) signals002(ghci) signals004(ghci,threaded1,threaded2,profthreaded) I haven't looked at the errors in detail, but generally the release candidate seems OK. BTW, a test target will be added to MacPorts's portfile for the 6.10.2 release, which will let you run the test suite by typing sudo port test ghc and if you then install the tested build, a record of the test will be saved in $PREFIX/share/ghc-version/. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hello, On Sunday 15 March 2009 16:51, Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 6.10.2: ... Please test as much as possible; bugs are much cheaper if we find them before the release! ... I have tried the Intel Mac installer and the source package on both FreeBSD and PPC Mac OS X. Some comments follow, first on GHC-6.10.1.20090314-i386.pkg: 1. An important property of such installers is that you are told, right from the start, that all the information you are presented with during the installation process can be accessed at any time, after completion of the installation, and you are told how. In case of GHC, something like a reference to a suitable spot, given as part of the output from ghc --help. I don't see any trace of such a facility on the introduction screen. (I know that other installers don't do this either, which is part of the reason why I try to avoid them.) 2. The introduction screen says This package must be installed on the system volume which seems to imply that there is some kind of choice involved at a later stage. But I don't recall having to perform any choice that related to this. So perhaps this should be This package will be installed on the system volume instead. 3. I can copy and paste the text of the introduction screen, excellent. I cannot copy and paste the header. 4. On the License screen, GMP is denoted GNU MP Bignum Library in two places. I suggest using GNU Multiple Precision Arithmetic Library (from http://gmplib.org/) instead. 5. On the License screen, replace licence by license, twice. 6. The License screen explains that by default the GMP will be statically linked into any binary produced by GHC. Software with a non-GPL compatible licence [sic] will have to ensure that the conditions of the LGPL are met; for example, by forcing GMP to link dynamically instead. Some details or a reference to an explanation of how to do this would be nice. Also, shouldn't non-GPL compatible be plain non-GPL? 7. I may very well be wrong, but as far as I have been able to tell, the ghc executable itself that is distributed (/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc) contains GMP, statically linked. For example: thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES /usr/bin/ghc --version dyld: loaded: /bin/sh dyld: loaded: /usr/lib/libncurses.5.4.dylib dyld: loaded: /usr/lib/libiconv.2.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib dyld: loaded: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc dyld: loaded: /usr/lib/libedit.2.dylib dyld: loaded: /usr/lib/libncurses.5.4.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib The Glorious Glasgow Haskell Compilation System, version 6.10.1.20090314 thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ where I fail to observe anything that seems to relate to GMP. This is in contrast to the corresponding information for an earlier GHC installation thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES ghc --version dyld: loaded: /bin/sh dyld: loaded: /usr/lib/libncurses.5.4.dylib dyld: loaded: /usr/lib/libiconv.2.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib dyld: loaded: /Users/thorkilnaur/tn/install/ghc-6.8.3/lib/ghc-6.8.3/ghc-6.8.3 dyld: loaded: /opt/local/lib/libreadline.5.2.dylib dyld: loaded: /opt/local/lib/libncurses.5.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /opt/local/lib/libgmp.3.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib The Glorious Glasgow Haskell Compilation System, version 6.8.3 thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ where one observes the presence of dyld: loaded: /opt/local/lib/libgmp.3.dylib that loads the separately installed dynamic GMP library. I am no expert in these matters, but this seems to activate requirement d) 0) under section 4. Combined Works of the LGPL GNU LESSER GENERAL PUBLIC LICENSE Version 3, 29 June 2007 (http://www.fsf.org/licensing/licenses/lgpl.html) which talks about providing material and giving instructions about how to re-link with a new version of the library and all that. If this material and the instructions are present in the installation package, I have failed to notice it. Alternatively, if the ghc executable links to GMP dynamically, requirement d) 1) of the LGPL comes into effect and that talks about a mechanism ...that ... uses at run time a copy of the Library already present on the user's computer
Re: Bootstrapping the compiler
I tried again with the same result. Is this a known problem, or do I have investigate myself? Colin == Colin Paul Adams co...@colina.demon.co.uk writes: Colin I have just downloaded a darcs snapshot, pulled patches and Colin followed the instructions at Colin http://hackage.haskell.org/trac/ghc/wiki/Building/QuickStart Colin When I got to do Colin make Colin it didn't work. The tail of the output looks like this: Colin [55 of 55] Compiling Main ( cabal-bin.hs, Colin /home/colin/ghc/libraries/bootstrapping/Main.o ) Linking Colin cabal-bin ... echo [] bootstrapping.conf.tmp cd Colin extensible-exceptions Colin /home/colin/ghc/libraries/cabal-bin ghc --make Colin -fno-warn-unrecognised-pragmas Colin /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 clean Colin --distpref=dist-bootstrapping unrecognised command: Colin /home/colin/ghc/libraries/bootstrapping.conf (try --help) Colin make[1]: [bootstrapping.conf] Error 1 (ignored) cd Colin extensible-exceptions Colin /home/colin/ghc/libraries/cabal-bin ghc --make Colin -fno-warn-unrecognised-pragmas Colin /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 Colin configure --distpref=dist-bootstrapping --with-compiler=ghc Colin --make -fno-warn-unrecognised-pragmas Colin --with-hc-pkg=/usr/local/bin/ghc-pkg Colin --package-db=/home/colin/ghc/libraries/bootstrapping.conf.tmp Colin unrecognised command: Colin /home/colin/ghc/libraries/bootstrapping.conf (try --help) Colin make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving Colin directory `/home/colin/ghc/libraries' make: *** [stage1] Colin Error 2 Colin I then tried the following: Colin [co...@susannah ghc]$ ls libraries/bootstrapping.conf ls: Colin cannot access libraries/bootstrapping.conf: No such file or Colin directory [co...@susannah ghc]$ ls Colin libraries/bootstrapping.conf.tmp Colin libraries/bootstrapping.conf.tmp Colin It looks to me like all I have to do is to rename Colin libraries/bootstrapping.conf.tmp Colin to Colin libraries/bootstrapping.conf Colin but I don't see why this is happening. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping the compiler
Colin == Colin Paul Adams co...@colina.demon.co.uk writes: Colin I tried again with the same result. Is this a known Colin problem, or do I have investigate myself? Colin == Colin Paul Adams co...@colina.demon.co.uk writes: Colin I have just downloaded a darcs snapshot, pulled patches and P.S. This was the January 2009 snapshot of HEAD (the 118 MB version). -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping the compiler
Colin Paul Adams wrote: I have just downloaded a darcs snapshot, pulled patches and followed the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/QuickStart When I got to do make it didn't work. The tail of the output looks like this: [55 of 55] Compiling Main ( cabal-bin.hs, /home/colin/ghc/libraries/bootstrapping/Main.o ) Linking cabal-bin ... echo [] bootstrapping.conf.tmp cd extensible-exceptions /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 clean --distpref=dist-bootstrapping unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) make[1]: [bootstrapping.conf] Error 1 (ignored) cd extensible-exceptions /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 configure --distpref=dist-bootstrapping --with-compiler=ghc --make -fno-warn-unrecognised-pragmas --with-hc-pkg=/usr/local/bin/ghc-pkg --package-db=/home/colin/ghc/libraries/bootstrapping.conf.tmp unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) make[1]: *** [bootstrapping.conf] Error 1 Your problem appears to be that you have set $(GHC) to ghc --make -fno-warn-unrecognised-pragmas $(GHC) should be set to the path to GHC, nothing else. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
Gregory Wright wrote: I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as a bootstrap compiler. The build was done using the MacPorts infrastructure. Summary test results: OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 2334 total tests, which gave rise to 12487 test cases, of which 0 caused framework failures 2460 were skipped 9709 expected passes 258 expected failures 0 unexpected passes 60 unexpected failures Unexpected failures: 2469(ghci) apirecomp001(normal) bits(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) conc049(hpc) conc068(normal) derefnull(profc,profthreaded) divbyzero(profc,profthreaded) genUpTo(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) num009(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) num012(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) signals002(ghci) signals004(ghci,threaded1,threaded2,profthreaded) Thanks. We really need people to look at these failing tests and either fix them or submit tickets as necessary. Volunteers? For num009 and num012, I've turned these on as part of validate which will force the problems to the surface. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping the compiler
Simon == Simon Marlow marlo...@gmail.com writes: Simon Your problem appears to be that you have set $(GHC) to Simon ghc --make -fno-warn-unrecognised-pragmas Simon $(GHC) should be set to the path to GHC, nothing else. You're right. I was using that prior to cabalizing my other project. I'll scrap it now. Thanks. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
There should be a file called testlog somewhere, either at the toplevel or within the tests directory. Could you search for apirecomp001 and send me the test output from running that test. I can't reproduce this failure when running it manually even though I'm on OS X, too. On 18 Mar 2009, at 10:51, Gregory Wright wrote: I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as a bootstrap compiler. The build was done using the MacPorts infrastructure. Summary test results: OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 2334 total tests, which gave rise to 12487 test cases, of which 0 caused framework failures 2460 were skipped 9709 expected passes 258 expected failures 0 unexpected passes 60 unexpected failures Unexpected failures: 2469(ghci) apirecomp001(normal) bits (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) conc049(hpc) conc068(normal) derefnull(profc,profthreaded) divbyzero(profc,profthreaded) genUpTo (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) num009 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) num012 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) signals002(ghci) signals004(ghci,threaded1,threaded2,profthreaded) I haven't looked at the errors in detail, but generally the release candidate seems OK. BTW, a test target will be added to MacPorts's portfile for the 6.10.2 release, which will let you run the test suite by typing sudo port test ghc and if you then install the tested build, a record of the test will be saved in $PREFIX/share/ghc-version/. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users / Thomas -- Push the envelope. Watch it bend. PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Advice wanted on parallel processing
I've just managed to build ghc 6.11 (Thanks Simon).
I did this for two reasons, one of which is I want to try to improve
the speed of the AI for the Chu Shogi program I am writing by making
use of parallel processing. I have a 4-core Xeon runing Fedora Linux
10 (AMD64).
I have a repeatable scenario for timings. With ghc 6.10.1, no threaded
runtime, the computer takes 51 or 52 seconds to move (experimental
variation up to 1.2 seconds).
With ghc 6.11, it takes the same time.
If I switch on the threaded runtime, then it rises slightly (perhaps
not significantly - I measure 53-54 seconds). With 2, 3 or 4
processors, I measured (one-off, so not reliable) 65, 55 and 58
seconds respectively.
Well, that doesn't really matter, provided I can get the time back
with interest by exploiting parallelism. My first thought for an
easy win is the move generator. At present I have this code:
-- | Generate all legal moves from state.
--
-- The best moves (according to some heuristic) should come first
generate_moves :: (Non_interactive_state, Maybe Move) -
[(Non_interactive_state, Maybe Move)]
generate_moves (state, _) =
let colour = case is_black_to_play state of
True - Black
False - White
pieces' = all_pieces_of_colour (board state) colour
unsorted = concatMap (generate_moves_for_piece state) pieces'
sorted = sortBy best_move unsorted
moves = mapMaybe new_move sorted
in {-trace (concat (intersperse \n (map (print_move . fromJust . snd)
moves)))-} moves
where new_move mv =
case update_from_move (state, Nothing) mv of
Nothing - Nothing
Just (st', Nothing) - Just (st', Just mv)
and my idea was to run the call to generate_moves_for_piece in
parallel over the pieces' list. I thought I could do that simply by
replacing concatMap with parFlatMap, but discovered I need to supply
an extra argument - a Strategy. Not knowing what this should be
(where's the best place to read up on this?) I tried specifying rwhnf.
My timings then are:
-N1 83 seconds
-N2 57 seconds
-N3 58 seconds
-N4 60 seconds
so a complete failure.
Where should I go from here?
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
Hello Thomas, On Wednesday 18 March 2009 15:03, Thomas Schilling wrote: There should be a file called testlog somewhere, either at the toplevel or within the tests directory. Could you search for apirecomp001 and send me the test output from running that test. I can't reproduce this failure when running it manually even though I'm on OS X, too. Several of the buildbot slaves fail the apirecomp001(normal) test as well. For eaxmple, here is the output from http://darcs.haskell.org/buildbot/all/builders/tnaur%20x86%20Linux%20head/builds/333/steps/runtestsuite/logs/unexpected for that test: = apirecomp001(normal) cd ./ghc-api/apirecomp001 $MAKE -s --no-print-directory apirecomp001 /dev/null apirecomp001.run.stdout 2apirecomp001.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: make[1]: myghc: Command not found make[1]: *** [apirecomp001] Error 127 *** unexpected failure for apirecomp001(normal) On 18 Mar 2009, at 10:51, Gregory Wright wrote: I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as a bootstrap compiler. The build was done using the MacPorts infrastructure. Summary test results: OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 2334 total tests, which gave rise to 12487 test cases, of which 0 caused framework failures 2460 were skipped 9709 expected passes 258 expected failures 0 unexpected passes 60 unexpected failures Unexpected failures: 2469(ghci) apirecomp001(normal) bits (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) conc049(hpc) conc068(normal) derefnull(profc,profthreaded) divbyzero(profc,profthreaded) genUpTo (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) num009 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) num012 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) signals002(ghci) signals004(ghci,threaded1,threaded2,profthreaded) I haven't looked at the errors in detail, but generally the release candidate seems OK. BTW, a test target will be added to MacPorts's portfile for the 6.10.2 release, which will let you run the test suite by typing sudo port test ghc and if you then install the tested build, a record of the test will be saved in $PREFIX/share/ghc-version/. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users / Thomas -- Push the envelope. Watch it bend. Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice wanted on parallel processing
Am Mittwoch, 18. März 2009 15:28 schrieb Colin Paul Adams:
I've just managed to build ghc 6.11 (Thanks Simon).
I did this for two reasons, one of which is I want to try to improve
the speed of the AI for the Chu Shogi program I am writing by making
use of parallel processing. I have a 4-core Xeon runing Fedora Linux
10 (AMD64).
I have a repeatable scenario for timings. With ghc 6.10.1, no threaded
runtime, the computer takes 51 or 52 seconds to move (experimental
variation up to 1.2 seconds).
With ghc 6.11, it takes the same time.
If I switch on the threaded runtime, then it rises slightly (perhaps
not significantly - I measure 53-54 seconds). With 2, 3 or 4
processors, I measured (one-off, so not reliable) 65, 55 and 58
seconds respectively.
Well, that doesn't really matter, provided I can get the time back
with interest by exploiting parallelism. My first thought for an
easy win is the move generator. At present I have this code:
-- | Generate all legal moves from state.
--
-- The best moves (according to some heuristic) should come first
generate_moves :: (Non_interactive_state, Maybe Move) -
[(Non_interactive_state, Maybe Move)] generate_moves (state, _) =
let colour = case is_black_to_play state of
True - Black
False - White
pieces' = all_pieces_of_colour (board state) colour
unsorted = concatMap (generate_moves_for_piece state) pieces'
sorted = sortBy best_move unsorted
moves = mapMaybe new_move sorted
in {-trace (concat (intersperse \n (map (print_move . fromJust . snd)
moves)))-} moves where new_move mv =
case update_from_move (state, Nothing) mv of
Nothing - Nothing
Just (st', Nothing) - Just (st', Just mv)
and my idea was to run the call to generate_moves_for_piece in
parallel over the pieces' list. I thought I could do that simply by
replacing concatMap with parFlatMap, but discovered I need to supply
an extra argument - a Strategy. Not knowing what this should be
(where's the best place to read up on this?) I tried specifying rwhnf.
Control.Parallel.Strategies, docs and source?
generate_moves_for_piece produces a list. rwhnf forces this list enough to see
if it's [] or (_:_)
(rwhnf x = x `seq` ()), that doesn't get enough work done in each thread to
compensate the overhead. Try using rnf after writing an NFData instance for
Move.
If e.g.
data Move = Move {from :: Position, to :: Position}
, the instance would be
instance NFData Move where
rnf (Move f t) = rnf f `seq` rnf t `seq` ()
That might require NFData instances for Position and its components, but
specifying these should be automatic.
My timings then are:
-N1 83 seconds
-N2 57 seconds
-N3 58 seconds
-N4 60 seconds
so a complete failure.
Where should I go from here?
HTH,
Daniel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
Hi Thomas, On Mar 18, 2009, at 10:03 AM, Thomas Schilling wrote: There should be a file called testlog somewhere, either at the toplevel or within the tests directory. Could you search for apirecomp001 and send me the test output from running that test. I can't reproduce this failure when running it manually even though I'm on OS X, too. I get: Running ./ghc-api/apirecomp001/all.T = apirecomp001(normal)cd ./ghc-api/apirecomp001 $MAKE -s --no- print-directory apirecomp001/dev/null apirecomp001.run.stdout 2apirecomp001.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: ld warning: atom sorting error for _ghczm6zi10zi1zi20090314_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi1zi20090314_LibFFI_Czuffizucif_closure_tbl in /opt/local/ var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc- beta/work/ghc-6.10.1.20090314/compiler/dist-stage2/build/ libHSghc-6.10.1.20090314.a(LibFFI.o) ld warning: atom sorting error for _ghczm6zi10zi1zi20090314_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi1zi20090314_LibFFI_Czuffizucif_closure_tbl in /opt/local/ var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc- beta/work/ghc-6.10.1.20090314/compiler/dist-stage2/build/ libHSghc-6.10.1.20090314.a(LibFFI.o) make[2]: myghc: Command not found make[2]: *** [apirecomp001] Error 127 *** unexpected failure for apirecomp001(normal) Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under Solaris: GHC 6.10.2 Release Candidate 1
On Wed, Mar 18, 2009 at 12:28:50AM +, Duncan Coutts wrote: On Tue, 2009-03-17 at 11:09 +0100, Christian Maeder wrote: unix = 2.0 2.4 Changing to = 2.4 was not sufficient, so I changed it to = 2.5. This will affect any OS! Hmm, it's a bit suspicious that the major version number is changing in a minor ghc release. Do we know what the API breakage is? This could affect any program. This looks like a braino to me. Things have been added to the API, but I don't see anything that's been removed or change. I'll put the version number back to 2.3.2.0. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice wanted on parallel processing
Daniel == Daniel Fischer daniel.is.fisc...@web.de writes:
Daniel generate_moves_for_piece produces a list. rwhnf forces
Daniel this list enough to see if it's [] or (_:_) (rwhnf x = x
Daniel `seq` ()), that doesn't get enough work done in each
Daniel thread to compensate the overhead. Try using rnf after
Daniel writing an NFData instance for Move.
Daniel If e.g.
Daniel data Move = Move {from :: Position, to :: Position}
Daniel , the instance would be
Daniel instance NFData Move where rnf (Move f t) = rnf f `seq`
Daniel rnf t `seq` ()
It made no difference to the timings whatsoever.
Anyway, at that point I decided to revert to the first rule of
performance tuning, and profiled the program for time. The move
generator was using less than 3% of the cpu time, so that was clearly
a waste of time on my part.
The one routine that stood out was this one (about 35% CPU time, with
0% attributed to children):
-- | Value of one rank of the board
rank_value :: (Int, Array Int Square) - Int
rank_value (rank_coord, rank') = sum (map (cell_value rank_coord)
(assocs rank'))
The array has 12 elements.
So I tried changing the map to parMap rnf. This gave timings of:
-N1 93 seconds -N2 105 seconds -N3 206 seconds
at which point I decided I hadn't got a clue what was going on.
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice wanted on parallel processing
On 2009 Mar 18, at 16:34, Colin Paul Adams wrote: The one routine that stood out was this one (about 35% CPU time, with 0% attributed to children): -- | Value of one rank of the board rank_value :: (Int, Array Int Square) - Int rank_value (rank_coord, rank') = sum (map (cell_value rank_coord) (assocs rank')) The array has 12 elements. How many times do you call it? Perhaps the real optimization you need is to memoize. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice wanted on parallel processing
Brandon == Brandon S Allbery KF8NH allb...@ece.cmu.edu writes: The array has 12 elements. Brandon How many times do you call it? Perhaps the real Brandon optimization you need is to memoize. Very many times indeed. But it is a different array on most occasions (I am not updating in place). It represents one rank of the board on which the game is played. The move generator produces a new board for each move. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice wanted on parallel processing
On 2009 Mar 18, at 16:59, Colin Paul Adams wrote: Brandon == Brandon S Allbery KF8NH allb...@ece.cmu.edu writes: The array has 12 elements. Brandon How many times do you call it? Perhaps the real Brandon optimization you need is to memoize. Very many times indeed. But it is a different array on most occasions (I am not updating in place). It represents one rank of the board on which the game is played. The move generator produces a new board for each move. It might be helpful for you to show more of the program. One thing to keep in mind about parallelization is that the level at which happens matters: if individual calculations across the list are fast, all you gain by parallelizing it is MP synchronization/locking overhead. On the other hand, it's possible that if the caller can be rearranged so that rank_value is computed on another CPU while it's doing something else, you could gain quite a bit. Or maybe the caller is itself at the right level to parallelize. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Loop unrolling + fusion ?
Recursion unfolding spec, 2nd attempt.
The main difference is to look at groups of mutually recursive
definitions as a whole, rather than trying to think about individual
definitions. That step actually seems sufficient to address most of
the shortcomings raised so far, such as avoiding runaway INLINE
or using PEEL/UNROLL also for mutually recursive definitions.
I've also interpreted Max's comments as most of the existing
INLINE restriction still making sense for recursive INLINE,
with small clarifications.
In the following, let REC({f g ..}) denote the set of all identifiers
belonging to the recursion involving f, g, .. (f, g, .. in REC({f g ..})
or in {-# INLINE f g .. #-} are required to belong to the same
recursion).
{-# NOINLINE f #-}
as now: no unfolding of f
{-# INLINE f #-}
as now: for non-recursive f only, unfold definition of f at call
sites of f (might in future be taken as go-ahead for analysis-based
recursion unfolding)
{-# INLINE f g .. PEEL n #-}
new: unfold definitions of the named identifiers at their call
sites *outside* their recursion group REC({f g ..}). In other
words, *entries into* REC({f g ..}) via f, g, .. are unfolded.
(for the special case of loops this corresponds to loop peeling)
{-# INLINE f g .. UNROLL m #-}
new: unfold definitions of the named identifiers at their call
sites *inside* their recursion group REC({f g ..}). In other
words, *cross-references inside* REC({f g ..}) via f, g, .. are
unfolded.
(for the special case of loops this corresponds to loop unrolling)
{-# INLINE f g .. PEEL n UNROLL m #-}
combine the previous two
The numeric parameters are to be interpreted as if each call to
f, g, .. was annotated with both PEEL and UNROLL limits for the
whole recursion group REC({f g ..}), starting with the limits from
the pragmas (write f_n_m for a call to f with PEEL limit n and
UNROLL limit m), to be decreased for every PEEL or UNROLL
action, as follows (REC({f g}) = {f g h}, in these examples):
1. let {-# INLINE f g PEEL n UNROLL m #-}
f .. = .. f_?_? .. g_?_? .. h_0_0 ..
g .. = .. f_?_? .. g_?_? .. h_0_0 ..
h .. = .. f_?_? .. g_?_? .. h_0_0 ..
in ..|f_n_m|..
--PEEL--
let {-# INLINE f g PEEL n UNROLL m #-}
f .. = .. f_?_? .. g_?_? .. h_0_0 ..
g .. = .. f_?_? .. g_?_? .. h_0_0 ..
h .. = .. f_?_? .. g_?_? .. h_0_0 ..
in ..|.. f_(n-1)_0 .. g_(n-1)_0 .. h_0_0 ..|..
Notes: - unfolding produces copies of definition bodies
- the PEEL limit at the call site decides the PEEL
limit for all calls to REC({f g}) in the inlined
copy; this limit decreases with each PEEL step
- since peeling unfolds code into call sites from outside
the recursion, the UNROLL limits of calls to REC({f g})
are effectively 0 in the inlined copy
- only calls to identifiers named in the INLINE pragma
can be peeled (f and g here), calls to other members of
the same recursion remain unaffected (h here), having
effective limits of 0
2. let {-# INLINE f g PEEL n UNROLL m #-}
f .. = .. f_0_m .. g_?_? .. h_0_0 ..
g .. = .. f_?_? .. g_?_? .. h_0_0 ..
h .. = .. f_?_? .. g_?_? .. h_0_0 ..
in ..
--UNROLL--
let {-# INLINE f g PEEL n UNROLL m #-}
f .. = .. .. f_0_(m-1) .. g_0_(m-1) .. h_0_0 .. .. g_?_? .. h_0_0 ..
g .. = .. f_?_? .. g_?_? .. h_0_0 ..
h .. = .. f_?_? .. g_?_? .. h_0_0 ..
in ..
Notes: - unfolding produces copies of definition bodies
- the UNROLL limit at the call site decides the UNROLL
limit for all calls to REC({f g}) in the inlined copy; this
limit decreases with each UNROLL step
- peeling conceptually precedes unrolling (PEEL limit needs
to reach 0 before unrolling commences), to avoid peeling
unrolled definitions (this corresponds to an existing restriction
of no inlining into definitions to be inlined;
- unrolling unfolds copies of the original definitions, not the
already unrolled ones, again corresponding to the existing
inlining restriction (TODO: how to specify this avoidance
of unrolling unrolled defs in this form of local rule spec?)
- only calls to identifiers named in the INLINE pragma
can be unrolled (f and g here), calls to other members of
the same recursion remain unaffected (h here), having
effective limits of 0
Peeling and unrolling stop when the respective count annotation has
reached 0. Peeling precedes unrolling, to avoid ambiguities in the
size of the peeled definitions. Note that mutual recursion is the
domain of PEEL, while UNROLL only applies to (mutual) recursion.
{-# INLINE f PEEL n #-}, for n0, corresponds to worker/
wrapper transforms (previously done manually) + inline wrapper,
and should therefore also be taken
Re: Advice wanted on parallel processing
(I am not updating in place). The move generator produces a new board for each move. Well, this is sound design, but current memory managers may not be up to it. If you check the (board) game programming literature, you'll find that engine authors take great efforts to bypass automatic memory management (do all updates on the current board in-place, and write their own malloc/free for game tree nodes). This becomes even more important when trying to exploit concurrency. In theory, that's all very nice (you can evaluate independent branches of the game tree in parallel) but in practice, you're doomed if your memory allocator/collector is still essentially single-threaded (that is, blocks all threads). That's language independent (it's a property of the run-time system). Of course in a more declarative language it should be easier for the compiler to analyze the source code and replace malloc/free by something better (no allocation by immediate re-use, or easy deallocation by some stack regime). J.W. -- View this message in context: http://www.nabble.com/Advice-wanted-on-parallel-processing-tp22580444p22591720.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hi Karel, On Mon, Mar 16, 2009 at 11:26:05AM +0100, Karel Gardas wrote: interesting but I'm not able to build this on SunOS 5.11/x86. The build fails with: (echo dist/build/cbits/PrelIOUtils.p_o dist/build/cbits/WCsubst.p_o dist/build/cbits/Win32Utils.p_o dist/build/cbits/consUtils.p_o dist/build/cbits/dirUtils.p_o dist/build/cbits/inputReady.p_o dist/build/cbits/selectUtils.p_o `find dist/build -name *_stub.p_o -print`; find dist/build/Foreign/Concurrent_split dist/build/GHC/Arr_split dist/build/GHC/Base_split [...] dist/build/Text/Show/Functions_split dist/build/Unsafe/Coerce_split -name '*.p_o' -print) | xargs /usr/bin/ar q dist/build/libHSbase-4.1.0.0_p.a ar: creating dist/build/libHSbase-4.1.0.0_p.a internal error: error_message(58) gmake[3]: *** [dist/build/libHSbase-4.1.0.0_p.a] Error 100 gmake[2]: *** [all] Error 1 gmake[2]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/libraries/base' gmake[1]: *** [make.library.base] Error 2 gmake[1]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/libraries' gmake: *** [stage1] Error 2 I've configure with simple: ./configure --prefix=/tmp/ghc-6.10.1.20090314 and build with: gmake The interesting thing is that GHC stable builds on my buildbot well: http://darcs.haskell.org/buildbot/all/builders/kgardas%20stable The buildbot is putting SplitObjs=NO in mk/build.mk. The above log has object splitting enabled, which means that there are a lot more .o files, which is presumably causing some problem with your ar. If you have both a GNU ar and a Solaris ar then it might be worth seeing if the other one works. Otherwise, putting SplitObjs=NO in mk/build.mk will work, but at the expense of larger binaries. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Loop unrolling + fusion ?
{-# INLINE f PEEL n UNROLL m #-}
The problem here is that this only works for directly recursive
functions which I, for instance, don't normally use in high-
performance code. Most of my loops are pipelines of collective
combinators like map, filter, fold etc. because these are the ones
that can be fused automatically. Unless I'm misunderstanding
something, this approach doesn't handle such cases.
If the map, filter, fold, etc can be unrolled, then the unrolled
definitions would be fused, right? So what is missing is fine
control (how much to unroll this particular call to map here).
Would it help to allow {-# INLINE map PEEL n UNROLL m #-}
in the caller modules as well as the definition modules, with the latter
providing a general case/upper limit, and the former providing finer
control? If you wanted even finer control, one would need a way to
specify named copies of inlineable recursion combinators, with
PEEL/UNROLL attached to the copies..
I see how this would need addressing, but I don't yet see a good
way to specify call-site-specific PEEL/UNROLL for recursion
combinators. Unless you want to control it by adding combinators
for the purpose?-)
Claus
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
I've installed a GUI application based on gtk2hs. It frequently crashes with the error: leksah: error: a C finalizer called back into Haskell. use Foreign.Concurrent.newForeignPtr for Haskell finalizers. This error did never occur with the 6.10 released version. It was verified that this happens on different machines. I've no idea how to isolate this bug. Any idea about this? Jürgen Nicklisch-Franken Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 6.10.2: http://www.haskell.org/ghc/dist/6.10.2-rc1/ This includes two source bundles: ghc-6.10.1.20090314-src.tar.bz2 ghc-6.10.1.20090314-src-extralibs.tar.bz2 Only the first of these is necessary. The extralibs package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There are also installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22592804.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
