Re: ghc 8.0.2 vs 8.4.1 compilation time and performance

2018-03-22 Thread Evan Laforge
Ok, done, I created https://ghc.haskell.org/trac/ghc/ticket/14964 But first: On Thu, Mar 22, 2018 at 3:26 AM, Simon Peyton Jones wrote: > score max mb total mb prdderive lily perform > ghc > 6 72.26 3279.22 0.88 0.79~0.84

RE: ghc 8.0.2 vs 8.4.1 compilation time and performance

2018-03-22 Thread Simon Peyton Jones via ghc-devs
Thanks for gathering this data. Simon From: Glasgow-haskell-users <glasgow-haskell-users-boun...@haskell.org> On Behalf Of Evan Laforge Sent: 21 March 2018 22:05 To: GHC users <glasgow-haskell-us...@haskell.org> Subject: ghc 8.0.2 vs 8.4.1 compilation time and performance I just u

Re: Compilation time

2017-07-08 Thread Karel Gardas
On 07/ 8/17 01:33 AM, Ben Gamari wrote: 8.2 will prefer both gold and lld over bfd ld. However two conditions must hold for these to be used, * The ld.lld/ld.gold executable must be in $PATH (or explicitly named by passing the LD variable to configure) * $CC must understand the

Re: Compilation time

2017-07-07 Thread Ben Gamari
Moritz Angermann writes: > For those of us who are on macOS, ... > Thus, if you end up having the llvm tools (and ld.lld) in your PATH, you > will need to set `--disable-ld-override` during configure on macOS, or your > ghc build will fail, because you end up trying

Re: Compilation time

2017-07-07 Thread Moritz Angermann
For those of us who are on macOS, you usually do not have any gcc, it’s all clang behind the curtains. E.g. see $ /usr/bin/gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.1.0

Re: Compilation time

2017-07-07 Thread Ben Gamari
Evan Laforge writes: > On Fri, Jul 7, 2017 at 9:28 AM, Ben Gamari wrote: >> >> In short, ./configure will now choose to use ld.gold or ld.lld if >> available (although this can be disabled using the --disable-ld-override >> configure flag). > > Just

Re: Compilation time

2017-07-07 Thread Evan Laforge
On Fri, Jul 7, 2017 at 9:28 AM, Ben Gamari wrote: > Ryan Scott writes: > >> Another things to note about 8.2 build times is that a bulk of the time is >> probably being spent during the linking phase. This is because GHC 8.2 has >> switched over to

Re: Compilation time

2017-07-07 Thread Ben Gamari
Ryan Scott writes: > Another things to note about 8.2 build times is that a bulk of the time is > probably being spent during the linking phase. This is because GHC 8.2 has > switched over to split-sections by default, but unfortunately, old versions > of the BFD linker

RE: Compilation time

2017-07-04 Thread Simon Peyton Jones via ghc-devs
Cc: Manuel Chakravarty <manuel.chakrava...@tweag.io> Subject: Compilation time Hi all, As you are probably well aware, GHC performance has been a growing concern over the last few years. Many Haskell programmers complain that build time has significantly increased over the last few re

Re: Compilation time

2017-07-04 Thread Matthew Pickering
package, which is built against all GHC > releases since 2010 : > > https://travis-ci.org/ku-fpg/data-reify > > tl;dr: Build time has gone from 1 min 32s for GHC 7.0 to 4 min 35s for GHC > 8.2. The 8.2 release alone seems to have increased compilation time by > almost 2 minutes, with the

Re: Compilation time

2017-07-04 Thread Robin Palotai
time has gone from 1 min 32s for GHC 7.0 to 4 min 35s for GHC > 8.2. The 8.2 release alone seems to have increased compilation time by > almost 2 minutes, with the current development branch bringing only minor > performance improvements. > > Of course, this single data point is n

Compilation time

2017-07-04 Thread Deest , Gaël
: https://travis-ci.org/ku-fpg/data-reify tl;dr: Build time has gone from 1 min 32s for GHC 7.0 to 4 min 35s for GHC 8.2. The 8.2 release alone seems to have increased compilation time by almost 2 minutes, with the current development branch bringing only minor performance improvements. Of course