[Haskell-cafe] [15/16] SBM: Predictions compared to the measurements

Don Stewart dons at galois.com
Sat Dec 22 20:55:40 EST 2007


firefly:
> >From Don Stewart:
> >Summary: the suspicious lazy bytestring program works now. (constant
> >space, and fastest overall, as expected originally)
> >
> >Program 1, lazy bytestring length . filter
> >
> >    Yesterday:
> >        ./A +RTS -sstderr < 150M  1.01s user 0.10s system 98% cpu 1.123 total
> >        40M allocated
> >
> >  * Today (fixed!):
> >        ./A +RTS -sstderr < 150M  0.26s user 0.06s system 96% cpu 0.332 total
> >        2M allocated
> >
> >    Reason, deprecated array fusion mucking up the optimiser.
> >
> >I think we can close this regression.
> 
> Nope.  Look at the memory graphs:
> 
> hs/space-bslc8-lenfil-1:  38632 ██████████▌                                   |
>  --                       38644 ██████████▌                                   |
>  --                        1940 ▌                                             |
>  --                      109404 █████████████████████████████▋                |
>  --                       82324 ██████████████████████▍                       |
>  --                      109388 █████████████████████████████▋                |
>  --                       82304 ██████████████████████▎                       |
> 
> It is fixed for ghc 6.8.2 running bytestring 0.9.0.2 but not for ghc
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 6.9.20071119 and head (as of noon 2007-12-19), no matter the bytestring
  ^^^^^^^^^^^^
> version.  There are lots of memory performance bugs in ghc 6.9.

Please package this up as a bug report against GHC head. 

Any regression wrt. 6.8.2, using the same bytestring version, is going
to be a ghc issue (not a bytestring library issue).

-- Don



More information about the Haskell-Cafe mailing list