RE: Removing Hoopl dependency?

[ning w]

Thanks Ben.


Both A and B (mentioned in Simon's reply) are good alternatives as long as
existing Hoopl users are NOT forced to upgrade when they upgrade Cable or
Stackage.  Otherwise, we will see more forks of Hoopl.   Once Cable and
Stackage gain the multi-version capability, A and B can be merged back to
Hoopl as a major release.

In my experience, Hoopl based optimizations/program analyses tend to use a
lot of memory, but they are also easy to verify. So it's still a useful
tool in some special use cases.  If the performance of Hoopl can be
improved, it will certainly be more useful.

Cheers,
Ning


*From:* Ben Gamari 
*Date:* June 12, 2017 at 11:05:51 AM PDT
*To:* Simon Peyton Jones , Sophie Taylor <
sop...@traumapony.org>, Michal Terepeta ,
ghc-devs , Ning Wang 
*Cc:* Kavon Farvardin 
*Subject:* *RE: Removing Hoopl dependency?*

Simon Peyton Jones via ghc-devs  writes:

Snip


That would leave Sophie free to do (B) free of the constraints of GHC

depending on it; but we could always use it later.


Does that sound plausible?  Do we know of any other Hoopl users?


CCing Ning, who is currently maintaining hoopl and I believe has some
projects using it.

Ning, you may want to have a look through this thread if you haven't
already seen it. You can find the previous messages in the list archive [1].

Cheers,

- Ben


[1] May messages: https://mail.haskell.org/piper
mail/ghc-devs/2017-May/014255.html
   June messages: https://mail.haskell.org/piper
mail/ghc-devs/2017-June/014293.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: WordX/IntX wrap Word#/Int#?

[Michal Terepeta]

Just for the record, I've opened:
https://ghc.haskell.org/trac/ghc/ticket/13825
to track this.

Cheers,
Michal

On Mon, Jun 12, 2017 at 8:45 PM Michal Terepeta 
wrote:

> Thanks a lot for the replies & links!
>
> I'll try to finish Simon's diff (and probably ask silly questions if I get
> stuck ;)
>
> Cheers,
> Michal
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 8.2.1-rc2 upgrade report

[Carter Schonwald]

8.2 has much more aggressive specialization of polymorphic functions at
their use sites,
is it possible that the build performance would improve and the runtime
improvements would remain, if you experimentally removed all the inline
pragmas?

On Fri, Jun 9, 2017 at 12:27 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Great.   Could you put all this into a Trac ticket?
>
>
>
> Thanks!
>
>
>
> Simon
>
>
>
> *From:* Alberto Valverde [mailto:albe...@toscat.net]
> *Sent:* 08 June 2017 13:57
> *To:* Simon Peyton Jones 
> *Cc:* GHC users 
> *Subject:* Re: 8.2.1-rc2 upgrade report
>
>
>
> 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/145ac5c01bfbadc5c9ff55e9c5c2e5
> 0e
> 
> .
>
>
>
> The plotted results live here https://gist.githubusercontent.com/albertov/
> 145ac5c01bfbadc5c9ff55e9c5c2e50e/raw/8996644707fc5c18c1d42ad43ee31b
> 1817509384/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