[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