- ghc-devs - Haskell.org

RE: GHC 7.8 release?
by Simon Peyton-Jones 10 Feb '13

10 Feb '13

, even a point release (7.6.2 vs. 7.6.1) of ghc tends to be moderately violent with respect to the Platform. Ideally, such a point release should not be difficult to slot in because it should be compatible modulo bug fixes, but with ghc's release strategy nobody has any confidence in it being that simple. Well our clear intention for point releases (7.6.1 to 7.6.1) is that they should break nothing. I am concerned that in your experience point releases are “moderately violent”. We go to some pains to make sure that we don’t break anything. If we don’t succeed on this point-release policy, please do tell us when the release candidate comes out. If we don’t know we are causing pain, we can’t stop inflicting it :-) (Major releases are another matter. There, things are likely to break.) Simon From: Brandon Allbery [mailto:allbery.b@gmail.com] Sent: 09 February 2013 13:41 To: Simon Peyton-Jones Cc: Carter Schonwald; Manuel Chakravarty; parallel-haskell; Mark Lentczner; GHC Users List; ghc-devs(a)haskell.org; Edsko de Vries Subject: Re: GHC 7.8 release? On Sat, Feb 9, 2013 at 6:27 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: In short, I think we already have the situation that you desire. Perhaps we just need to market it better? Or am I mistaken? Except the current question is about how ghc releases interact with the Platform; this thread was set off by a question about getting 7.6.2 into the next Platform.... And the main issue there is that ghc releases tend to break things and need a lot of testing in general to make it into the Platform; while this would be expected anyway, even a point release (7.6.2 vs. 7.6.1) of ghc tends to be moderately violent with respect to the Platform. Ideally, such a point release should not be difficult to slot in because it should be compatible modulo bug fixes, but with ghc's release strategy nobody has any confidence in it being that simple. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com<mailto:allbery.b@gmail.com> ballbery(a)sinenomine.net<mailto:ballbery@sinenomine.net> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Compiling DynFlags is jolly slow
by Ian Lynagh 09 Feb '13

09 Feb '13

On Thu, Jan 31, 2013 at 12:23:02PM -0000, GHC wrote: > > I can't compile `DynFlags` on my 256MB Raspberry Pi. Could we do > something about having less auto-generated code in this module please? > > -- > Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7258#comment:13> The ticket's really about performance problems in the compiler rather than DynFlags in particular, so moving to the list. Even the non-generated code in DynFlags is quite large, and ungainly to edit. What would you think about splitting it up, perhaps moving DumpFlag, GeneralFlag and WarningFlag into separate modules? Ideally each module would also export a [Flag (CmdLineP DynFlags)], which would then be ++ed together in DynFlags, but I'm not sure if that's possible without making the modules mutually recursive. On the other hand, perhaps there's a way to split it up which would remove the need for (some of) the existing import loops; I'm not sure how feasible that is OTTOMH. Thanks Ian

2 2

Re: [commit: testsuite] master: Replace 'if_platform' and 'unless_platform' with 'platform' (22951cd)
by Johan Tibell 09 Feb '13

09 Feb '13

I think you might have missed some cases: ====> Scanning ../../libraries/directory/tests/all.T *** framework failure: found an error while executing ../../libraries/directory/tests/all.T : Traceback (most recent call last): File "../driver/runtests.py", line 251, in <module> execfile(file) File "../../libraries/directory/tests/all.T", line 27, in <module> test('T4113', if_platform('i386-apple-darwin', expect_broken(7604)), compile_and_run, ['']) NameError: name 'if_platform' is not defined ====> Scanning ../../libraries/base/tests/all.T *** framework failure: found an error while executing ../../libraries/base/tests/all.T : Traceback (most recent call last): File "../driver/runtests.py", line 251, in <module> execfile(file) File "../../libraries/base/tests/all.T", line 12, in <module> if_platform('i386-unknown-openbsd', expect_fail), NameError: name 'if_platform' is not defined ====> Scanning ../../libraries/base/tests/IO/all.T *** framework failure: found an error while executing ../../libraries/base/tests/IO/all.T : Traceback (most recent call last): File "../driver/runtests.py", line 251, in <module> execfile(file) File "../../libraries/base/tests/IO/all.T", line 107, in <module> expect_fail_if_windows)), compile_and_run, ['-package unix']) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 651, in test setup(name, myTestOpts) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 587, in <lambda> return lambda name, opts, f=f, g=g: _compose(name, opts, f, g) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 591, in _compose g(name, opts) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 587, in <lambda> return lambda name, opts, f=f, g=g: _compose(name, opts, f, g) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 591, in _compose g(name, opts) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 587, in <lambda> return lambda name, opts, f=f, g=g: _compose(name, opts, f, g) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 591, in _compose g(name, opts) TypeError: expect_fail_if_windows() takes exactly 1 argument (2 given) ====> Scanning ../../libraries/base/tests/Numeric/all.T *** framework failure: found an error while executing ../../libraries/base/tests/Numeric/all.T : Traceback (most recent call last): File "../driver/runtests.py", line 251, in <module> execfile(file) File "../../libraries/base/tests/Numeric/all.T", line 10, in <module> , if_platform('i386-apple-darwin', expect_broken(2370)) NameError: name 'if_platform' is not defined On Fri, Feb 8, 2013 at 6:19 AM, Ian Lynagh <igloo(a)earth.li> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/testsuite > > On branch : master > > > http://hackage.haskell.org/trac/ghc/changeset/22951cdab93ab21dab9fe5597954b… > > >--------------------------------------------------------------- > > commit 22951cdab93ab21dab9fe5597954b922c9c89a48 > Author: Ian Lynagh <ian(a)well-typed.com> > Date: Fri Feb 8 00:38:42 2013 +0000 > > Replace 'if_platform' and 'unless_platform' with 'platform' > > >--------------------------------------------------------------- > > driver/testlib.py | 13 ++----------- > tests/codeGen/should_gen_asm/all.T | 6 +++--- > tests/ffi/should_run/all.T | 2 +- > tests/ghci/scripts/all.T | 2 +- > tests/numeric/should_run/all.T | 2 +- > tests/perf/compiler/all.T | 6 +++--- > tests/rts/all.T | 12 ++++++------ > 7 files changed, 17 insertions(+), 26 deletions(-) > > diff --git a/driver/testlib.py b/driver/testlib.py > index 4c9b2c2..aa601f7 100644 > --- a/driver/testlib.py > +++ b/driver/testlib.py > @@ -312,17 +312,8 @@ def when(b, f): > def unless(b, f): > return when(not b, f) > > -def if_platform( plat, f ): > - if config.platform == plat: > - return f > - else: > - return normal > - > -def unless_platform( plat, f ): > - if config.platform != plat: > - return f > - else: > - return normal > +def platform( plat ): > + return config.platform == plat > > def if_os( os, f ): > if config.os == os: > diff --git a/tests/codeGen/should_gen_asm/all.T > b/tests/codeGen/should_gen_asm/all.T > index a24ae31..be30d5f 100644 > --- a/tests/codeGen/should_gen_asm/all.T > +++ b/tests/codeGen/should_gen_asm/all.T > @@ -1,6 +1,6 @@ > test('memcpy', > - unless_platform('x86_64-unknown-linux',skip), compile_cmp_asm, ['']) > + unless(platform('x86_64-unknown-linux'),skip), compile_cmp_asm, ['']) > test('memcpy-unroll', > - unless_platform('x86_64-unknown-linux',skip), compile_cmp_asm, ['']) > + unless(platform('x86_64-unknown-linux'),skip), compile_cmp_asm, ['']) > test('memcpy-unroll-conprop', > - unless_platform('x86_64-unknown-linux',skip), compile_cmp_asm, ['']) > + unless(platform('x86_64-unknown-linux'),skip), compile_cmp_asm, ['']) > diff --git a/tests/ffi/should_run/all.T b/tests/ffi/should_run/all.T > index 1811f42..09e6944 100644 > --- a/tests/ffi/should_run/all.T > +++ b/tests/ffi/should_run/all.T > @@ -33,7 +33,7 @@ test('ffi004', skip, compile_and_run, ['']) > # > test('ffi005', [ omit_ways(prof_ways), > if_arch('i386', skip), > - if_platform('i386-apple-darwin', expect_broken(4105)), > + when(platform('i386-apple-darwin'), expect_broken(4105)), > exit_code(3) ], > compile_and_run, ['']) > > diff --git a/tests/ghci/scripts/all.T b/tests/ghci/scripts/all.T > index f204af7..0b8f62e 100755 > --- a/tests/ghci/scripts/all.T > +++ b/tests/ghci/scripts/all.T > @@ -38,7 +38,7 @@ test('ghci022', normal, ghci_script, ['ghci022.script']) > test('ghci023', normal, ghci_script, ['ghci023.script']) > test('ghci024', > [skip_if_fast, > - if_platform("powerpc-apple-darwin", expect_broken(1845))], > + when(platform("powerpc-apple-darwin"), expect_broken(1845))], > run_command, > ['$MAKE -s --no-print-directory ghci024']) > test('ghci025', normal, ghci_script, ['ghci025.script']) > diff --git a/tests/numeric/should_run/all.T > b/tests/numeric/should_run/all.T > index b2109de..d2f017a 100644 > --- a/tests/numeric/should_run/all.T > +++ b/tests/numeric/should_run/all.T > @@ -7,7 +7,7 @@ test('arith001', normal, compile_and_run, ['']) > test('arith002', normal, compile_and_run, ['']) > test('arith003', normal, compile_and_run, ['']) > test('arith004', normal, compile_and_run, ['']) > -test('arith005', if_platform('i386-apple-darwin', expect_broken_for(7043, > 'ghci')), compile_and_run, ['']) > +test('arith005', when(platform('i386-apple-darwin'), > expect_broken_for(7043, 'ghci')), compile_and_run, ['']) > test('arith006', normal, compile_and_run, ['']) > test('arith007', normal, compile_and_run, ['']) > > diff --git a/tests/perf/compiler/all.T b/tests/perf/compiler/all.T > index 09a0297..1ba4c15 100644 > --- a/tests/perf/compiler/all.T > +++ b/tests/perf/compiler/all.T > @@ -117,7 +117,7 @@ test('T4801', > # 12/11/2012: 49 (amd64/Linux) (REASON UNKNOWN!) > > # expected value: 58 (amd64/OS X): > - if_platform('x86_64-apple-darwin', > + when(platform('x86_64-apple-darwin'), > compiler_stats_range_field('peak_megabytes_allocated', 58, 1)), > # expected value: 228286660 (x86/OS X) > when(wordsize(32), > @@ -130,7 +130,7 @@ test('T4801', > # 19/10/2012: 392409984 (amd64/Linux) (-fPIC turned > off) > > # expected value: 510938976 (amd64/OS X): > - if_platform('x86_64-apple-darwin', > + when(platform('x86_64-apple-darwin'), > compiler_stats_range_field('bytes allocated', 510938976, 5)), > > when(wordsize(32), > @@ -144,7 +144,7 @@ test('T4801', > # 19/10/2012: 26882576 (-fPIC turned on) > # 19/10/2012: 18619912 (-fPIC turned off) > # 24/12/2012: 21657520 (perhaps gc sampling time wibbles?) > - if_platform('x86_64-apple-darwin', > + when(platform('x86_64-apple-darwin'), > compiler_stats_range_field('max_bytes_used', 21657520, 5)), > only_ways(['normal']), > extra_hc_opts('-static') > diff --git a/tests/rts/all.T b/tests/rts/all.T > index 05510e9..380ce85 100644 > --- a/tests/rts/all.T > +++ b/tests/rts/all.T > @@ -9,7 +9,7 @@ test('testblockalloc', compose(c_src, > test('bug1010', normal, compile_and_run, ['+RTS -c -RTS']) > test('derefnull', > composes([ > - if_platform('x86_64-unknown-mingw32', expect_broken(6079)), > + when(platform('x86_64-unknown-mingw32'), > expect_broken(6079)), > # LLVM Optimiser considers dereference of a null pointer > # undefined and marks the code as unreachable which means > # that later optimisations remove it altogether. > @@ -21,13 +21,13 @@ test('derefnull', > # the right exit code we're OK. > if_os('linux', ignore_output), > # SIGBUS on OX X (PPC and x86 only; amd64 gives SEGV) > - if_platform('i386-apple-darwin', exit_code(138)), > - if_platform('powerpc-apple-darwin', exit_code(138)), > + when(platform('i386-apple-darwin'), exit_code(138)), > + when(platform('powerpc-apple-darwin'), exit_code(138)), > if_os('mingw32', exit_code(1))]), > compile_and_run, ['']) > test('divbyzero', > composes([ > - if_platform('x86_64-unknown-mingw32', expect_broken(6079)), > + when(platform('x86_64-unknown-mingw32'), > expect_broken(6079)), > # SIGFPE on Linux > exit_code(136), > # Apparently the output can be different on different > @@ -121,8 +121,8 @@ def config_T5250(name, opts): > > test('T5250', [ config_T5250, > # stack ptr is not 16-byte aligned on 32-bit Windows > - if_platform('i386-unknown-mingw32', expect_fail), > - if_platform('i386-unknown-linux', > + when(platform('i386-unknown-mingw32'), expect_fail), > + when(platform('i386-unknown-linux'), > expect_broken_for(4211,['llvm'])), > extra_clean(['spalign.o']), > omit_ways(['ghci']) ], > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

No instance for (Fractional Int32)
by Gabor Greif 09 Feb '13

09 Feb '13

Hi all, This is what I get while building a cross-ghc: libraries/base/Foreign/C/Types.hs:162:72: No instance for (Fractional Int32) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Fractional CFloat) Has anybody seen this with HEAD? Cheers, Gabor

3 5

Validate failures
by Simon Marlow 09 Feb '13

09 Feb '13

A batch of testsuite failures this morning - forgotten push to testsuite perhaps? Unexpected failures: perf/should_run T5113 [stat not good enough] (normal) simplCore/should_compile T3717 [stderr mismatch] (optasm) simplCore/should_compile T4908 [stderr mismatch] (optasm) simplCore/should_compile T7360 [stderr mismatch] (optasm) simplCore/should_compile spec-inline [stderr mismatch] (optasm) typecheck/should_compile holes [stderr mismatch] (normal) typecheck/should_compile holes2 [stderr mismatch] (normal) typecheck/should_compile holes3 [stderr mismatch] (normal) Cheers, Simon

4 8

Re: nofib regressions in HEAD since 7.6.2 release
by Johan Tibell 08 Feb '13

08 Feb '13

Here are the numbers using -O2. Again on my 64-bit Core i7-3770 @ 3.40GHz, running Linux. 7.6.1 vs HEAD: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna +0.1% -1.5% 0.08 0.08 +0.0% ansi -1.5% -0.4% 0.00 0.00 +0.0% atom -0.4% +0.0% +0.8% +0.8% +0.0% awards -1.0% -0.1% 0.00 0.00 +0.0% banner -2.7% -2.1% 0.00 0.00 +0.0% bernouilli -0.5% -2.6% 0.13 0.13 +0.0% binary-trees +5.6% +0.0% +4.5% +2.8% +8.0% boyer -1.5% -0.0% 0.04 0.04 +0.0% boyer2 -2.8% -0.0% 0.01 0.01 +0.0% bspt -0.4% -0.1% 0.01 0.01 -33.3% cacheprof -0.5% -6.4% +6.6% +0.0% -4.0% calendar -1.3% -0.1% 0.00 0.00 +0.0% cichelli -2.4% +0.0% 0.06 0.06 -5.7% circsim -1.1% -0.1% +6.6% +3.2% +1.0% clausify -1.4% -0.0% 0.03 0.03 +0.0% comp_lab_zift -1.3% -0.0% 0.14 0.14 -12.5% compress -1.3% -0.0% 0.12 0.12 +0.0% compress2 -1.7% -0.0% 0.13 0.14 -2.1% constraints -1.4% -0.0% +4.3% +2.6% +0.0% cryptarithm1 -2.8% +0.0% -0.5% -3.5% +0.0% cryptarithm2 -3.3% +1.0% 0.01 0.01 +0.0% cse -2.7% +0.0% 0.00 0.00 +0.0% eliza -2.6% -7.1% 0.00 0.00 +0.0% event -1.6% -0.0% 0.10 0.10 +9.5% exp3_8 -1.4% -0.0% 0.14 0.14 -50.0% expert -1.8% -15.5% 0.00 0.00 +0.0% fannkuch-redux -0.9% -0.0% -1.7% -2.1% +0.0% fasta -1.5% +8.7% +9.2% -0.6% -50.0% fem -2.1% -0.5% 0.03 0.03 +0.0% fft -0.6% -0.0% 0.03 0.03 +0.0% fft2 -3.5% -24.6% 0.04 0.04 -33.3% fibheaps -1.3% -0.2% 0.03 0.03 +0.0% fish -2.2% +0.0% 0.01 0.01 +0.0% fluid +0.8% -11.9% 0.01 0.01 -50.0% fulsom -0.0% +0.0% 0.20 0.20 -6.2% gamteb -0.8% +0.1% 0.04 0.04 +0.0% gcd -0.6% -0.0% 0.03 0.03 +0.0% gen_regexps -2.7% -2.1% 0.00 0.00 +0.0% genfft -0.9% +0.3% 0.03 0.03 +0.0% gg -0.4% -29.0% 0.02 0.02 +0.0% grep -0.1% -2.3% 0.00 0.00 +0.0% hidden +0.3% -3.4% -6.4% -10.4% +0.0% hpg -0.6% +1.3% 0.10 0.10 +0.0% ida -0.9% +1.0% 0.06 0.06 -20.0% infer -0.8% -0.5% 0.05 0.05 -38.5% integer -0.5% -1.0% -1.9% -2.6% +0.0% integrate +0.6% -36.0% 0.14 -38.2% -2.9% k-nucleotide +7.2% +5.2% +0.5% -0.6% +46.2% kahan -0.5% -99.7% -53.0% -52.8% +0.0% knights -1.7% +0.4% 0.01 0.01 +0.0% lcss -2.0% -0.7% +35.0% +22.7% -3.7% life -2.2% -0.0% 0.16 0.16 +0.0% lift -2.0% -0.1% 0.00 0.00 +0.0% listcompr -2.7% +0.0% 0.06 0.06 +0.0% listcopy -2.7% +0.0% 0.06 0.06 +0.0% maillist -2.7% -0.9% 0.04 0.04 -2.9% mandel +0.8% -0.0% 0.05 0.05 +0.0% mandel2 -2.7% -0.0% 0.00 0.00 +0.0% minimax -2.5% +0.0% 0.00 0.00 +0.0% mkhprog -2.5% -1.1% 0.00 0.00 +0.0% multiplier -1.0% -0.0% 0.08 0.08 +0.0% n-body +5.4% +0.0% -22.3% -23.1% +0.0% nucleic2 +2.2% -16.3% 0.05 0.05 +0.0% para -1.7% -18.5% -8.1% -12.8% +0.0% paraffins -1.4% -0.0% 0.07 0.07 -7.0% parser -1.3% -18.4% 0.03 0.03 +0.0% parstof -1.8% -4.5% 0.00 0.00 +0.0% pic -1.0% -0.0% 0.00 0.00 +0.0% pidigits -0.6% -0.0% +4.8% -2.3% +0.0% power +0.0% -0.0% +2.9% +0.5% +0.0% pretty -1.1% -0.0% 0.00 0.00 +0.0% primes -1.0% +0.0% 0.05 0.05 +0.0% primetest -0.6% -0.0% 0.07 0.07 +0.0% prolog -2.1% -14.0% 0.00 0.00 +0.0% puzzle -2.6% +2.2% 0.10 0.10 +0.0% queens -1.5% -0.0% 0.02 0.02 +0.0% reptile -0.8% -0.8% 0.02 0.02 +0.0% reverse-complem -2.5% +0.0% 0.08 0.08 +0.0% rewrite -1.2% -0.7% 0.02 0.02 +0.0% rfib +1.0% -0.4% 0.02 0.02 +0.0% rsa -0.7% -2.5% 0.03 0.03 +0.0% scc -2.8% -0.0% 0.00 0.00 +0.0% sched -1.5% -0.0% 0.02 0.02 +0.0% scs +2.0% -0.6% +2.2% +0.5% +0.0% simple -0.7% +0.0% 0.16 0.16 -6.5% solid -0.5% -0.0% 0.10 0.10 +0.0% sorting -2.7% -35.9% 0.00 0.00 +0.0% spectral-norm +5.4% +16.1% +0.0% +0.0% +0.0% sphere -1.1% +1.8% 0.03 0.03 +0.0% symalg +0.8% -0.3% 0.01 0.01 +0.0% tak -1.5% -0.9% 0.01 0.01 +0.0% transform -1.0% -0.0% +4.3% +2.6% +0.0% treejoin -2.7% -52.4% 0.15 0.15 +3.8% typecheck -1.3% -0.0% 0.15 0.15 +0.0% veritas -0.3% -0.0% 0.00 0.00 +0.0% wang -0.8% -0.0% 0.08 0.08 +0.0% wave4main -1.3% -1.8% 0.19 0.19 +7.7% wheel-sieve1 -1.0% -0.0% +8.3% +3.1% +14.3% wheel-sieve2 -1.0% -0.0% 0.12 0.12 -2.1% x2n1 -7.1% -48.0% 0.01 0.01 -66.7% -------------------------------------------------------------------------------- Min -7.1% -95.0% -53.0% -52.8% -66.7% Max +7.2% +16.1% +35.0% +22.7% +46.2% Geometric Mean -1.0% -6.8% -1.7% -6.6% -4.4% lcss is definitely worth looking into, as it regressed ~35%. fast might be worth looking into, as it regressed with ~10%. There are also some ~5% regressions that are probably not worth looking into, unless someone has spare time. 7.6.2 vs HEAD: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna +0.8% -1.5% 0.08 0.08 +0.0% ansi +0.5% -0.4% 0.00 0.00 +0.0% atom +0.9% +0.0% +0.8% +0.8% +0.0% awards +0.9% -0.1% 0.00 0.00 +0.0% banner -0.1% -2.1% 0.00 0.00 +0.0% bernouilli +0.6% -2.6% 0.13 0.13 +0.0% binary-trees +6.9% +0.0% +3.2% +1.6% +8.0% boyer +0.7% -0.0% 0.04 0.04 +0.0% boyer2 -0.2% -0.0% 0.01 0.01 +0.0% bspt +0.7% -0.1% 0.01 0.01 -33.3% cacheprof +0.9% -6.4% +4.0% +0.0% -4.0% calendar +0.9% -0.1% 0.00 0.00 +0.0% cichelli +0.2% +0.0% 0.06 0.06 -5.7% circsim +0.8% -0.1% +7.0% +1.9% +1.0% clausify +0.8% -0.0% 0.03 0.03 +0.0% comp_lab_zift +0.8% -0.0% 0.14 0.14 -12.5% compress +0.1% -0.0% 0.12 0.12 +0.0% compress2 +0.1% -0.0% 0.13 0.14 -2.1% constraints +0.8% -0.0% +2.3% +0.2% +0.0% cryptarithm1 +0.1% +0.0% -2.5% -4.0% +0.0% cryptarithm2 -0.6% +1.0% 0.01 0.01 +0.0% cse +0.0% +0.0% 0.00 0.00 +0.0% eliza -0.1% -7.1% 0.00 0.00 +0.0% event +0.7% -0.0% 0.10 0.10 +9.5% exp3_8 +0.8% -0.0% 0.14 0.14 -50.0% expert +0.2% -15.5% 0.00 0.00 +0.0% fannkuch-redux +0.8% -0.0% +3.7% +3.7% +0.0% fasta +0.8% -0.0% +7.8% +0.6% +0.0% fem -1.4% -0.5% 0.03 0.03 +0.0% fft +0.7% -0.0% 0.03 0.03 +0.0% fft2 -3.5% -24.6% 0.04 0.04 -33.3% fibheaps +0.9% -0.2% 0.03 0.03 +0.0% fish +0.0% +0.0% 0.01 0.01 +0.0% fluid +1.2% -11.9% 0.01 0.01 -50.0% fulsom +0.2% +0.0% 0.20 0.20 -5.1% gamteb +0.3% +0.1% 0.04 0.04 +0.0% gcd +0.8% -0.0% 0.03 0.03 +0.0% gen_regexps -0.0% -2.1% 0.00 0.00 +0.0% genfft +0.8% +0.3% 0.03 0.03 +0.0% gg +0.6% -29.0% 0.02 0.02 +0.0% grep +2.5% -2.3% 0.00 0.00 +0.0% hidden +0.7% -3.4% -6.4% -8.2% +0.0% hpg +0.5% +1.3% 0.10 0.10 +0.0% ida +0.8% +1.0% 0.06 0.06 -20.0% infer +1.2% -0.5% 0.05 0.05 -38.5% integer +0.9% -1.0% -4.7% -5.6% +0.0% integrate +0.9% -36.0% -34.6% -41.9% -1.0% k-nucleotide +8.5% +5.2% +2.7% +1.7% +46.2% kahan +0.9% -99.7% -52.2% -52.0% +0.0% knights +0.2% +0.4% 0.01 0.01 +0.0% lcss +0.2% -0.7% 0.27 +25.0% -3.7% life +0.1% -0.0% 0.16 0.16 +0.0% lift +0.0% -0.1% 0.00 0.00 +0.0% listcompr +0.1% +0.0% 0.06 0.06 +0.0% listcopy +0.1% +0.0% 0.06 0.06 +0.0% maillist -0.1% -1.8% 0.04 0.04 +6.3% mandel +0.8% -0.0% 0.05 0.05 +0.0% mandel2 +0.1% -0.0% 0.00 0.00 +0.0% minimax +0.2% +0.0% 0.00 0.00 +0.0% mkhprog +0.2% -1.1% 0.00 0.00 +0.0% multiplier +1.2% -0.0% 0.08 0.08 +0.0% n-body +6.6% +0.0% -21.4% -22.2% +0.0% nucleic2 +3.4% -16.3% 0.05 0.05 +0.0% para +0.3% -18.5% -12.8% -15.0% +0.0% paraffins +0.8% -0.0% 0.07 0.07 -7.0% parser +0.7% -18.4% 0.03 0.03 +0.0% parstof +0.5% -4.5% 0.00 0.00 +0.0% pic -0.8% -0.0% 0.00 0.00 +0.0% pidigits +0.8% -0.0% +3.6% -0.6% +0.0% power +1.0% -0.0% +1.4% -0.9% +0.0% pretty +0.2% -0.0% 0.00 0.00 +0.0% primes +0.8% +0.0% 0.05 0.05 +0.0% primetest +0.7% -0.0% 0.07 0.07 +0.0% prolog +0.2% -14.0% 0.00 0.00 +0.0% puzzle +0.1% +2.2% 0.10 0.10 +0.0% queens +0.8% -0.0% 0.02 0.02 +0.0% reptile +0.6% -0.8% 0.02 0.02 +0.0% reverse-complem +0.4% +0.0% 0.08 0.08 +0.0% rewrite +1.0% -0.7% 0.02 0.02 +0.0% rfib +1.0% -0.4% 0.02 0.02 +0.0% rsa +0.7% -2.5% 0.03 0.03 +0.0% scc +0.1% -0.0% 0.00 0.00 +0.0% sched +0.8% -0.0% 0.02 0.02 +0.0% scs +2.0% -0.6% +5.2% +1.7% +0.0% simple +0.2% +0.0% 0.16 0.16 -6.5% solid +0.7% -0.0% 0.10 0.10 +0.0% sorting -0.0% -35.9% 0.00 0.00 +0.0% spectral-norm +6.7% +16.1% +0.2% +0.0% +0.0% sphere +0.8% +1.8% 0.03 0.03 +0.0% symalg +0.8% -0.3% 0.01 0.01 +0.0% tak +0.8% -0.9% 0.01 0.01 +0.0% transform +0.9% -0.0% +6.2% +3.4% +0.0% treejoin -0.0% -52.4% 0.15 0.15 +3.8% typecheck +0.8% -0.0% 0.15 0.15 +0.0% veritas +0.7% -0.0% 0.00 0.00 +0.0% wang +0.5% -0.0% 0.08 0.08 +0.0% wave4main +0.8% -1.8% 0.19 0.19 +7.7% wheel-sieve1 +0.7% -0.0% +3.1% +0.8% +14.3% wheel-sieve2 +0.7% -0.0% 0.12 0.12 -2.1% x2n1 -6.8% -48.0% 0.01 0.01 -66.7% -------------------------------------------------------------------------------- Min -6.8% -95.0% -52.2% -52.0% -66.7% Max +8.5% +16.1% +7.8% +25.0% +46.2% Geometric Mean +0.7% -6.9% -5.5% -6.6% -3.6% 7.6.1 vs 7.6.2: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna -0.6% +0.0% 0.07 0.08 +0.0% ansi -2.0% +0.0% 0.00 0.00 +0.0% atom -1.3% +0.0% +0.0% +0.0% +0.0% awards -1.8% +0.0% 0.00 0.00 +0.0% banner -2.6% +0.0% 0.00 0.00 +0.0% bernouilli -1.0% +0.0% 0.13 0.13 +0.0% binary-trees -1.2% +0.0% +1.2% +1.2% +0.0% boyer -2.2% +0.0% 0.03 0.04 +0.0% boyer2 -2.6% +0.0% 0.01 0.01 +0.0% bspt -1.1% +0.0% 0.01 0.02 +0.0% cacheprof -1.4% +0.0% +2.5% +0.0% +0.0% calendar -2.2% +0.0% 0.00 0.00 +0.0% cichelli -2.6% +0.0% 0.05 0.06 +0.0% circsim -1.9% +0.0% -0.3% +1.3% +0.0% clausify -2.2% +0.0% 0.03 0.03 +0.0% comp_lab_zift -2.1% +0.0% 0.13 0.14 +0.0% compress -1.4% +0.0% 0.11 0.11 +0.0% compress2 -1.8% +0.0% 0.12 0.14 +0.0% constraints -2.2% +0.0% +2.0% +2.4% +0.0% cryptarithm1 -2.8% +0.0% +2.1% +0.5% +0.0% cryptarithm2 -2.7% +0.0% 0.01 0.01 +0.0% cse -2.7% +0.0% 0.00 0.00 +0.0% eliza -2.5% +0.0% 0.00 0.00 +0.0% event -2.2% +0.0% 0.09 0.10 +0.0% exp3_8 -2.2% +0.0% 0.14 0.14 +0.0% expert -2.0% +0.0% 0.00 0.00 +0.0% fannkuch-redux -1.7% +0.0% -5.2% -5.6% +0.0% fasta -2.3% +8.7% +1.3% -1.2% -50.0% fem -0.7% +0.0% 0.02 0.03 +0.0% fft -1.3% +0.0% 0.02 0.03 +0.0% fft2 +0.0% +0.0% 0.04 0.05 +0.0% fibheaps -2.2% +0.0% 0.03 0.03 +0.0% fish -2.2% +0.0% 0.01 0.01 +0.0% fluid -0.3% +0.0% 0.01 0.01 +0.0% fulsom -0.2% +0.0% 0.19 0.19 -1.3% gamteb -1.1% +0.0% 0.03 0.04 +0.0% gcd -1.4% +0.0% 0.02 0.03 +0.0% gen_regexps -2.7% +0.0% 0.00 0.00 +0.0% genfft -1.7% +0.0% 0.03 0.03 +0.0% gg -1.0% +0.0% 0.01 0.02 +0.0% grep -2.5% +0.0% 0.00 0.00 +0.0% hidden -0.4% +0.0% +0.0% -2.5% +0.0% hpg -1.1% +0.0% 0.05 0.10 +0.0% ida -1.7% +0.0% 0.06 0.06 +0.0% infer -2.0% +0.0% 0.05 0.05 +0.0% integer -1.3% +0.0% +3.0% +3.1% +0.0% integrate -0.3% +0.0% 0.21 +6.4% -1.9% k-nucleotide -1.1% +0.0% -2.2% -2.3% +0.0% kahan -1.4% +0.0% -1.7% -1.7% +0.0% knights -1.9% +0.0% 0.00 0.01 +0.0% lcss -2.2% +0.0% -1.0% -1.8% +0.0% life -2.3% +0.0% 0.16 0.16 +0.0% lift -2.0% +0.0% 0.00 0.00 +0.0% listcompr -2.8% +0.0% 0.06 0.06 +0.0% listcopy -2.8% +0.0% 0.06 0.06 +0.0% maillist -2.6% +1.0% 0.03 0.05 -8.7% mandel -0.0% +0.0% 0.04 0.05 +0.0% mandel2 -2.8% +0.0% 0.00 0.00 +0.0% minimax -2.6% +0.0% 0.00 0.00 +0.0% mkhprog -2.6% +0.0% 0.00 0.00 +0.0% multiplier -2.2% +0.0% 0.08 0.08 +0.0% n-body -1.2% +0.0% -1.1% -1.3% +0.0% nucleic2 -1.2% +0.0% 0.05 0.05 +0.0% para -2.0% +0.0% +5.4% +2.6% +0.0% paraffins -2.2% +0.0% 0.06 0.08 +0.0% parser -2.1% +0.0% 0.03 0.03 +0.0% parstof -2.2% +0.0% 0.01 0.00 +0.0% pic -0.3% +0.0% 0.00 0.00 +0.0% pidigits -1.5% +0.0% +1.2% -1.7% +0.0% power -1.0% +0.0% +1.4% +1.4% +0.0% pretty -1.4% +0.0% 0.00 0.00 +0.0% primes -1.8% +0.0% 0.05 0.05 +0.0% primetest -1.3% +0.0% 0.08 0.07 +0.0% prolog -2.4% +0.0% 0.00 0.00 +0.0% puzzle -2.7% +0.0% 0.10 0.10 +0.0% queens -2.3% +0.0% 0.02 0.02 +0.0% reptile -1.4% +0.0% 0.01 0.02 +0.0% reverse-complem -2.9% +0.0% 0.06 0.08 +0.0% rewrite -2.1% +0.0% 0.02 0.02 +0.0% rfib +0.0% +0.0% 0.02 0.02 +0.0% rsa -1.4% +0.0% 0.02 0.02 +0.0% scc -2.9% +0.0% 0.00 0.00 +0.0% sched -2.2% +0.0% 0.02 0.02 +0.0% scs +0.0% +0.0% -2.8% -1.1% +0.0% simple -1.0% +0.0% 0.15 0.16 +0.0% solid -1.3% +0.0% 0.09 0.10 +0.0% sorting -2.6% +0.0% 0.00 0.00 +0.0% spectral-norm -1.2% +0.0% -0.2% +0.0% +0.0% sphere -1.9% +0.0% 0.03 0.03 +0.0% symalg -0.0% +0.0% 0.00 0.01 +0.0% tak -2.3% +0.0% 0.01 0.01 +0.0% transform -1.9% +0.0% -1.7% -0.9% +0.0% treejoin -2.7% +0.0% 0.15 0.16 +0.0% typecheck -2.2% +0.0% 0.15 0.15 +0.0% veritas -1.1% +0.0% 0.00 0.00 +0.0% wang -1.3% +0.0% 0.07 0.08 +0.0% wave4main -2.1% +0.0% 0.19 0.18 +0.0% wheel-sieve1 -1.7% +0.0% +5.0% +2.4% +0.0% wheel-sieve2 -1.7% +0.0% 0.11 0.13 +0.0% x2n1 -0.3% +0.0% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min -2.9% +0.0% -5.2% -5.6% -50.0% Max +0.0% +8.7% +5.4% +6.4% +0.0% Geometric Mean -1.7% +0.1% +0.4% +0.0% -0.8% The big regression Bryan and I saw in hashable between 7.6.1 and 7.6.2 isn't visible here, so we might need to extract a separate benchmark for it. -- Johan

1 4

Re: [commit: testsuite] master: Convert remaining *_range_field's to *_num_field (478da8f)
by Simon Marlow 08 Feb '13

08 Feb '13

On 08/02/13 14:19, Ian Lynagh wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/testsuite > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/478da8fea8c7aca287a0a6270e202… > >> --------------------------------------------------------------- > > commit 478da8fea8c7aca287a0a6270e20254221c60c84 > Author: Ian Lynagh <ian(a)well-typed.com> > Date: Fri Feb 8 13:35:34 2013 +0000 > > Convert remaining *_range_field's to *_num_field Great work on the testsuite, all these changes look really good! Cheers, Simon

1 0

RE: Stable pointers and hash table performance
by Simon Peyton-Jones 07 Feb '13

07 Feb '13

The ticket contains vastly less information than Eyal's post, though. Simon | -----Original Message----- | From: Edward Z. Yang [mailto:ezyang@MIT.EDU] | Sent: 07 February 2013 08:34 | To: Simon Peyton-Jones | Cc: Eyal Lotem; "ghc-devs(a)haskell.org" | Subject: RE: Stable pointers and hash table performance | | http://hackage.haskell.org/trac/ghc/ticket/7670 | | Excerpts from Simon Peyton-Jones's message of Thu Feb 07 00:30:21 -0800 | 2013: | > Would it be worth turning this into a Trac ticket? | > | > Simon | > | > From: ghc-devs-bounces(a)haskell.org [mailto:ghc-devs- | bounces(a)haskell.org] On Behalf Of Eyal Lotem | > Sent: 07 February 2013 02:14 | > To: ghc-devs(a)haskell.org | > Subject: Stable pointers and hash table performance | > | > Hey, | > | > Background | > ---------------- | > I built a hash table in C: https://github.com/Peaker/small_hash | > | > According to a few simple benchmarks (mainly, 10 million insertions), | my C hash table is much faster than any Haskell data structure I tried | (e.g: 8 times faster than IntMap). | > You can run the C benchmark (in small_hash) via: "make && ./benchmark | 10000000". | > | > The other benchmarks are at: | https://github.com/Peaker/hashtable_benchmarks | > Benchmarks results on my hardware: http://hpaste.org/81902 | > | > I was hoping to get that fast mapping goodness to Haskell, by building | an FFI to it: | > https://github.com/Peaker/small_hash_hs | > | > In order to do FFI bindings to a C data structure, that can contain | arbitrary Haskell values, I must create a lot of StablePtrs (for each | Haskell value stored in the C hash table). | > | > Problem 1: | > ------------- | > Disappointingly, the FFI bindings were dozens of times slower(!) than | the C code. | > | > When using +RTS -H200M the speed is about 10 times slower(!) than the | C code. | > oprofile shows that the culprit is the Stable Ptr code. | > | > Digging in, I found that stable ptrs and stable names shared a table, | despite having quite different characteristics: | > * Stable Names aren't considered roots by GC, ptrs are. | > * Making two stable ptrs for the same Haskell value doesn't really | require them to unify -- so there's no need for the hash table or the | "refs" counter for stable ptrs. | > | > My Changes: | > ----------------- | > I split the Stable Names into their own table (which allowed removing | the "refs" field from them). | > Stable Ptrs no longer use a hash table to unify, don't need "refs", or | "sn_obj", or "old". | > | > This made Stable Ptrs cost just 1 C ptr in the table and really cheap | to create/destroy. | > | > The commits are here: | > https://github.com/Peaker/ghc/commits/master | > | > They are not polished (I didn't thoroughly review myself yet, didn't | run the test suite, fix out-of-date comments involved) and not ready for | integration yet. | > | > Result: | > --------- | > The hash table benchmark via the FFI is now only ~2 times slower than | the C data structure and much faster than any other mapping structure | for that particular benchmark (10 million insertions of identity | integers, sequentially). A lot of the cost here is due to fine-grained | allocation, as the C code does bulk allocation. I shall improve this | benchmark later, and I believe it will tighten the gap some more. | > | > Problem 2: | > -------------- | > http://hackage.haskell.org/trac/ghc/ticket/7670 | > | > Every minor GC iterates a whole lot of stable ptrs. This means that | with the default heap size, runtime is about 8 times longer (than with a | 200M heap size). | > | > To avoid this, I'd like to split the stable ptrs table into | generations. | > | > To do this, I need to know which of the pointed objects were promoted | and to what generation, so I can promote my stable ptrs accordingly. | > It seems like the correct time to do this is in the | updateStablePtrTable (now named "updateStableTables") | > | > This is the part I need help with. | > How do I know if an object was promoted to a higher generation when I | traverse the objects? | > | > Thanks! | > Eyal

2 1

nofib comparisons between 7.0.4, 7.4.2, 7.6.1, and 7.6.2
by Johan Tibell 07 Feb '13

07 Feb '13

Hi all, I haven't had much time to do performance tzar work yet, but I did run nofib on the last few GHC releases to see the current trend. The benchmarks where run on my 64-bit Core i7-3770 @ 3.40GHz Linux machine. Here are the results: 7.0.4 to 7.4.2: ------------------------------------------------------------ -------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -1.6% -57.3% -39.1% -36.4% -25.0% Max +21.5% +121.5% +24.5% +25.4% +300.0% Geometric Mean +8.5% -0.7% -7.1% -5.2% +2.0% The big loser here in terms of runtime is "kahan", which I added to test tight loops involving unboxed arrays and floating point arithmetic. I believe there was a regression in fromIntegral RULES during this release, which meant that some conversions between fixed-width types went via Integer, causing unnecessary allocation. 7.4.2 to 7.6.1: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -5.1% -23.8% -11.8% -12.9% -50.0% Max +5.3% +225.5% +7.2% +8.8% +200.0% Geometric Mean -0.4% +2.1% +0.3% +0.2% +0.7% The biggest loser here in terms of runtime is "integrate". I haven't looked into why yet. 7.6.1 to 7.6.2: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -2.9% +0.0% -4.8% -4.4% -1.9% Max +0.0% +1.0% +4.5% +6.4% +20.8% Geometric Mean -1.7% +0.0% +0.1% +0.3% +0.2% I have two takeaways: * It's worthwhile running nofib before releases as it does find some programs that regressed. * There are some other regressions out there (i.e. in code on Hackage) that aren't reflected here, suggesting that we need to add more programs to nofib. Cheers, Johan

8 21

Stable pointers and hash table performance
by Eyal Lotem 07 Feb '13

07 Feb '13

Hey, Background ---------------- I built a hash table in C: https://github.com/Peaker/small_hash According to a few simple benchmarks (mainly, 10 million insertions), my C hash table is much faster than any Haskell data structure I tried (e.g: 8 times faster than IntMap). You can run the C benchmark (in small_hash) via: "make && ./benchmark 10000000". The other benchmarks are at: https://github.com/Peaker/hashtable_benchmarks Benchmarks results on my hardware: http://hpaste.org/81902 I was hoping to get that fast mapping goodness to Haskell, by building an FFI to it: https://github.com/Peaker/small_hash_hs In order to do FFI bindings to a C data structure, that can contain arbitrary Haskell values, I must create a lot of StablePtrs (for each Haskell value stored in the C hash table). Problem 1: ------------- Disappointingly, the FFI bindings were dozens of times slower(!) than the C code. When using +RTS -H200M the speed is about 10 times slower(!) than the C code. oprofile shows that the culprit is the Stable Ptr code. Digging in, I found that stable ptrs and stable names shared a table, despite having quite different characteristics: * Stable Names aren't considered roots by GC, ptrs are. * Making two stable ptrs for the same Haskell value doesn't really require them to unify -- so there's no need for the hash table or the "refs" counter for stable ptrs. My Changes: ----------------- I split the Stable Names into their own table (which allowed removing the "refs" field from them). Stable Ptrs no longer use a hash table to unify, don't need "refs", or "sn_obj", or "old". This made Stable Ptrs cost just 1 C ptr in the table and really cheap to create/destroy. The commits are here: https://github.com/Peaker/ghc/commits/master They are not polished (I didn't thoroughly review myself yet, didn't run the test suite, fix out-of-date comments involved) and not ready for integration yet. Result: --------- The hash table benchmark via the FFI is now only ~2 times slower than the C data structure and much faster than any other mapping structure for that particular benchmark (10 million insertions of identity integers, sequentially). A lot of the cost here is due to fine-grained allocation, as the C code does bulk allocation. I shall improve this benchmark later, and I believe it will tighten the gap some more. Problem 2: -------------- http://hackage.haskell.org/trac/ghc/ticket/7670 Every minor GC iterates a whole lot of stable ptrs. This means that with the default heap size, runtime is about 8 times longer (than with a 200M heap size). To avoid this, I'd like to split the stable ptrs table into generations. To do this, I need to know which of the pointed objects were promoted and to what generation, so I can promote my stable ptrs accordingly. It seems like the correct time to do this is in the updateStablePtrTable (now named "updateStableTables") This is the part I need help with. How do I know if an object was promoted to a higher generation when I traverse the objects? Thanks! Eyal

2 1