Re: 8.2.1-rc2 upgrade report

[Alberto Valverde]

Hi Simon,

Thanks for the pointer. I re-did both builds with -dshow-passes and made a
small script to plot the results of the lines which summarize the elapsed
time and allocated memory per phase and module. I've uploaded the raw logs,
a plot of the results and the script I wrote to generate it to
https://gist.githubusercontent.com/albertov/145ac5c01bfbadc5c9ff55e9c5c2e50e
.

The plotted results live here
https://gist.githubusercontent.com/albertov/145ac5c01bfbadc5c9ff55e9c5c2e50e/raw/8996644707fc5c18c1d42ad43ee31b1817509384/bench.png

Apparently, the biggest slowdown in respect to 8.0.2 seems to occur in the
SpecConstr and Simplifier passes in the Propag (where the "main" function
is) and the Sigym4.Propag.Engine (where the main algorithm lives) modules.

Any other tests that would be helpful for me to run? I'm not sure where to
start to create a reproducible case but I'll see if I can come up with
something soon...

Alberto

On Tue, Jun 6, 2017 at 1:58 PM, Simon Peyton Jones 
wrote:

> Thanks for the report.
>
>
>
> Going from 67G to 56G allocation is a very worthwhile improvement in
> runtime!  Hurrah.
>
>
>
> However, trebling compile time is very bad.  It is (I think) far from
> typical: generally 8.2 is *faster* at compiling than 8.0 so you must be
> hitting something weird.  Anything you can do to make a reproducible case
> would be helpful.  -dshow-passes shows the size of each intermediate form,
> which at least sometimes shows where the big changes are.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:glasgow-haskell-users-
> boun...@haskell.org] *On Behalf Of *Alberto Valverde
> *Sent:* 06 June 2017 12:39
> *To:* GHC users 
> *Subject:* 8.2.1-rc2 upgrade report
>
>
>
> Hi,
>
>
>
> I've finally managed to upgrade all the dependencies of the proprietary
> app I mentioned some days ago in this list and there are good and bad
> differences I've noticed between 8.0.2 that I'd like to share.
>
>
>
> The bad
>
> ---
>
>
>
> * An optimized cold build (-O2)  is about 3 times slower (~53s vs. ~2m55s)
> and consumes more memory (~2Gb vs. ~7Gb) at it's peak.
>
>
>
> The good
>
> -
>
>
>
> * An un-optimized cold build (-O0) takes about the same time (~21s, phew!
> :) It's maybe even slightly faster with 8.2 (too few and badly taken
> measurements to really know, though)
>
> * The optimized executable is slightly faster and allocates less memory.
> For this app it makes up for the performance regression of the optimized
> build (which is almost always done by CI), IMHO.
>
>
>
> I did only a couple of runs and only wrote down [1] the last run results
> (which were similar to the previous results) so take these observations
> with a grain of salt (except maybe the optimized build slowdown, which
> doesn't have much margin for variance to be skewing the results). I also
> measured the peak memory usage by observing "top".
>
>
>
> In case gives a clue: The app is a multi-threaded 2D spread simulator
> which deals with many mmapped Storable mutable vectors and has been pretty
> optimized for countless hours (I mean by this that it has (too) many INLINE
> pragmas. Mostly on polymorphic functions to aid in their specialization). I
> think some of this information can be deduced from the results I'm linking
> at the footer. I believe the INLINEs are playing a big part of the slowdown
> since the slowest modules to compile are the "Main" ones which put
> everything together, along with the typical lens-th-heavy "Types" ones.
>
>
>
> I'd like to help by producing a reproducible and isolated benchmark or a
> better analysis or ... so someone more knowledgeable than me on GHC
> internals can someday hopefully attack the regression. Any pointers on what
> would help and where can I learn to do it?
>
>
>
> Thanks!
>
>
>
>
>
> [1] https://gist.github.com/albertov/46fbb13d940f67a569f9a25c1cb8154c
> 
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: 8.2.1-rc2 upgrade report

[Simon Peyton Jones via Glasgow-haskell-users]

Thanks for the report.

Going from 67G to 56G allocation is a very worthwhile improvement in runtime!  
Hurrah.

However, trebling compile time is very bad.  It is (I think) far from typical: 
generally 8.2 is faster at compiling than 8.0 so you must be hitting something 
weird.  Anything you can do to make a reproducible case would be helpful.  
-dshow-passes shows the size of each intermediate form, which at least 
sometimes shows where the big changes are.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Alberto Valverde
Sent: 06 June 2017 12:39
To: GHC users 
Subject: 8.2.1-rc2 upgrade report

Hi,

I've finally managed to upgrade all the dependencies of the proprietary app I 
mentioned some days ago in this list and there are good and bad differences 
I've noticed between 8.0.2 that I'd like to share.

The bad
---

* An optimized cold build (-O2)  is about 3 times slower (~53s vs. ~2m55s) and 
consumes more memory (~2Gb vs. ~7Gb) at it's peak.

The good
-

* An un-optimized cold build (-O0) takes about the same time (~21s, phew! :) 
It's maybe even slightly faster with 8.2 (too few and badly taken measurements 
to really know, though)
* The optimized executable is slightly faster and allocates less memory. For 
this app it makes up for the performance regression of the optimized build 
(which is almost always done by CI), IMHO.

I did only a couple of runs and only wrote down [1] the last run results (which 
were similar to the previous results) so take these observations with a grain 
of salt (except maybe the optimized build slowdown, which doesn't have much 
margin for variance to be skewing the results). I also measured the peak memory 
usage by observing "top".

In case gives a clue: The app is a multi-threaded 2D spread simulator which 
deals with many mmapped Storable mutable vectors and has been pretty optimized 
for countless hours (I mean by this that it has (too) many INLINE pragmas. 
Mostly on polymorphic functions to aid in their specialization). I think some 
of this information can be deduced from the results I'm linking at the footer. 
I believe the INLINEs are playing a big part of the slowdown since the slowest 
modules to compile are the "Main" ones which put everything together, along 
with the typical lens-th-heavy "Types" ones.

I'd like to help by producing a reproducible and isolated benchmark or a better 
analysis or ... so someone more knowledgeable than me on GHC internals can 
someday hopefully attack the regression. Any pointers on what would help and 
where can I learn to do it?

Thanks!


[1] 
https://gist.github.com/albertov/46fbb13d940f67a569f9a25c1cb8154c
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users