Better perf
Sebastian Graf
sgraf1337 at gmail.com
Fri Dec 14 15:07:50 UTC 2018
Hey,
when going through Simon-nofib-notes, I stumbled over this thread from
March 2017, when I hadn't yet subscribed to this list:
https://mail.haskell.org/pipermail/ghc-devs/2017-March/013887.html.
Joachim and Simon were trying to pin-point seemingly random regressions and
improvements of ~5% to `binary-trees`.
It's hard to say in retrospect, but I suspect this is the same effect I
experienced in #15333 and I'm about to fix in #15999, e.g. that small
changes to allocations lead to big, uncorrelated jumps in runtime
performance due to GC.
Just wanted to record this here for posterity.
Cheers
Sebastian
Hi,
>
> Am Dienstag, den 07.03.2017, 22:55 +0000 schrieb Simon Peyton Jones via
> ghc-devs:
> >* > But: binary-trees runtime increases by 5%.
> *> >* David: might you look to see if there is any obvious reason for this
> *>* regression? We could just accept it, but it's always good to know
> *>* why, and to document it.
> *
> Turns out that my commit
> Add rule mapFB c (λx.x) = c
> fixed that regression:https://perf.haskell.org/ghc/#revision/2fa44217c1d9722227297eefb0d6c6aed7e128ca
>
> Maybe there is just a performance cliff there, and these jumps don’t
> really mean anything.
>
> Greetings,
> Joachim
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181214/24c0cc26/attachment.html>
More information about the ghc-devs
mailing list