Re: Increased memory usage with GHC 7.10.1

[Paolino]

Hello, compiling 2.5.0 on (linux 4.0.1, 64 bit) and ghc 7.10.1 with
/usr/bin/time -f %M gives values between 2.3 GB and 2.6 GB on multiple runs.

(2.4.1 was requesting more than 3 GB, cannot say how much precisely)

Thanks Sven

2015-05-03 16:45 GMT+02:00 George Colpitts :

> I think this helps quite a bit. Although it still peaks briefly at over 3
> GB mem usage on my Mac according to the Activity Monitor it seems to spend
> much of its time using 400 - 800 mb memory use. I can't be sure as I never
> tried to compile this before. I'm compiling by simply doing cabal install
>  Not sure what optimization levels that uses, I assume -O1
>
> On Sun, May 3, 2015 at 10:41 AM, Sven Panne  wrote:
>
>> 2015-05-02 12:01 GMT+02:00 Paolino :
>> > Hello, I succeded in compiling
>> >
>> https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html
>> > on a 32 bit machine with 2GB of memory with ghc 7.10.1. O_O
>>
>> To alleviate the pain a bit, I've uploaded a new version of OpenGLRaw
>> (2.5.0.0) to Hackage, containing 2 improvements:
>>
>>* 'foreign import "dynamic"'s with the same signature are re-used,
>> cutting down their number from 3062 to 864.
>>
>>* Those 'foreign import "dynamic"'s live in a separate module now.
>>
>> Travis CI seems to be happy with these changes (the VMs there don't
>> have much memory, either), although Haddock still seems to eat memory
>> like hell. But that's a different story...
>>
>> It would be nice to hear if the new version improved the situation for
>> people who previous had trouble.
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[George Colpitts]

I think this helps quite a bit. Although it still peaks briefly at over 3
GB mem usage on my Mac according to the Activity Monitor it seems to spend
much of its time using 400 - 800 mb memory use. I can't be sure as I never
tried to compile this before. I'm compiling by simply doing cabal install
 Not sure what optimization levels that uses, I assume -O1

On Sun, May 3, 2015 at 10:41 AM, Sven Panne  wrote:

> 2015-05-02 12:01 GMT+02:00 Paolino :
> > Hello, I succeded in compiling
> >
> https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html
> > on a 32 bit machine with 2GB of memory with ghc 7.10.1. O_O
>
> To alleviate the pain a bit, I've uploaded a new version of OpenGLRaw
> (2.5.0.0) to Hackage, containing 2 improvements:
>
>* 'foreign import "dynamic"'s with the same signature are re-used,
> cutting down their number from 3062 to 864.
>
>* Those 'foreign import "dynamic"'s live in a separate module now.
>
> Travis CI seems to be happy with these changes (the VMs there don't
> have much memory, either), although Haddock still seems to eat memory
> like hell. But that's a different story...
>
> It would be nice to hear if the new version improved the situation for
> people who previous had trouble.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Sven Panne]

2015-05-02 12:01 GMT+02:00 Paolino :
> Hello, I succeded in compiling
> https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html
> on a 32 bit machine with 2GB of memory with ghc 7.10.1. O_O

To alleviate the pain a bit, I've uploaded a new version of OpenGLRaw
(2.5.0.0) to Hackage, containing 2 improvements:

   * 'foreign import "dynamic"'s with the same signature are re-used,
cutting down their number from 3062 to 864.

   * Those 'foreign import "dynamic"'s live in a separate module now.

Travis CI seems to be happy with these changes (the VMs there don't
have much memory, either), although Haddock still seems to eat memory
like hell. But that's a different story...

It would be nice to hear if the new version improved the situation for
people who previous had trouble.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Paolino]

Hello, I succeded in compiling
https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html
on a 32 bit machine with 2GB of memory with ghc 7.10.1. O_O

HTH, paolino

2015-05-01 21:32 GMT+02:00 Michal Terepeta :

> On Fri, May 1, 2015 at 5:05 PM Simon Peyton Jones 
> wrote:
>
>>  It would be amazingly helpful if someone (anyone) could diagnose a bit.
>>
>>
>>
>> It may be a bug in GHC but it may also be a bug in the pragmas in a
>> library.   If someone can produce evidence for the former, I’ll gladly look
>> at it.
>>
>>
>>
>> Simon
>>
> I've opened https://ghc.haskell.org/trac/ghc/ticket/10370 for the
> OpenGLRaw case (and it does seem that this might be a problem in GHC).
>
> Cheers,
> Michal
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Michal Terepeta]

On Fri, May 1, 2015 at 5:05 PM Simon Peyton Jones 
wrote:

>  It would be amazingly helpful if someone (anyone) could diagnose a bit.
>
>
>
> It may be a bug in GHC but it may also be a bug in the pragmas in a
> library.   If someone can produce evidence for the former, I’ll gladly look
> at it.
>
>
>
> Simon
>
I've opened https://ghc.haskell.org/trac/ghc/ticket/10370 for the OpenGLRaw
case (and it does seem that this might be a problem in GHC).

Cheers,
Michal
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Increased memory usage with GHC 7.10.1

[Simon Peyton Jones]

It would be amazingly helpful if someone (anyone) could diagnose a bit.

It may be a bug in GHC but it may also be a bug in the pragmas in a library.   
If someone can produce evidence for the former, I’ll gladly look at it.

Simon

From: Greg Weber [mailto:g...@gregweber.info]
Sent: 01 May 2015 16:01
To: Simon Peyton Jones
Cc: Paolino; George Colpitts; Manuel Chakravarty; 
glasgow-haskell-users@haskell.org
Subject: Re: Increased memory usage with GHC 7.10.1

We have observed issues with compile-time inlining taking much longer in newer 
versions of GHC in some cases
https://github.com/larskuhtz/toCaseFoldBuildTimes
This particular issue was reported to the text repo: 
https://github.com/bos/text/issues/116

On Fri, May 1, 2015 at 7:49 AM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
It would be great if someone could

• create a ticket for Paolio

• investigate what is happening
This smaller test case uses Repa, so it’s not clear that GHC is doing anything 
wrong. Maybe repa is inlining too much?  We need insight.

Thanks

SImon

From: Glasgow-haskell-users 
[mailto:glasgow-haskell-users-boun...@haskell.org<mailto:glasgow-haskell-users-boun...@haskell.org>]
 On Behalf Of Paolino
Sent: 01 May 2015 15:30
To: George Colpitts
Cc: glasgow-haskell-users@haskell.org<mailto:glasgow-haskell-users@haskell.org>
Subject: Re: Increased memory usage with GHC 7.10.1

here is another file , which is small, which cannot be compiled within 4GB  
memory.

https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs
I'd just want to add that this problem is a nasty one if one doesn't set the 
max heap: a remote machine frozen that must be rebooted is not a nice adventure 
, hoping the crash remains confined to the vm.
hth, paolino



2015-05-01 15:31 GMT+02:00 George Colpitts 
mailto:george.colpi...@gmail.com>>:
Should we recommend that all library developers compile their libraries with a 
max heap of 4G (to pick an arbitrary number) so that we can catch some of these 
issues earlier?

On Fri, May 1, 2015 at 5:42 AM, Paolino 
mailto:paolo.verone...@gmail.com>> wrote:
Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with 
-O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file 
making memory explode is  
Graphics.Rendering.OpenGL.Raw.Functions<https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html>.
 With -O0 it uses 600 MB.
The file is really huge, but I could compile it with prior versions of ghc.
Regards
paolino

2015-04-17 1:33 GMT+02:00 David Laing 
mailto:dave.laing...@gmail.com>>:
Hi all,
I've been playing around with profiling GHC recently, so I thought I'd chime in 
with a pointer that might save people searching for the right docs - you could 
configure a cabal sandbox to work with multiple version of ghc, which I've 
found useful:

https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta 
mailto:michal.terep...@gmail.com>> wrote:
Hi Richard,

Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build 
flavor 'prof' then get the haskell-src-exts sources, install the dependencies 
and finally add +RTS -p -RTS to the cabal file and compile it, the resulting 
ghc.prof contains the profiling information.

For anyone interested about CallArity slowness, the problem is tracked in 
https://ghc.haskell.org/trac/ghc/ticket/10293

Cheers,
Michal

On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
mailto:e...@cis.upenn.edu>> wrote:
I've pasted Michal's numbers in #9630, which seems like a good place to track 
this. Michal, would you mind fleshing out a bit precisely what you did to get 
those numbers? That would be helpful (though you've already been very helpful 
indeed in getting the data together)!

Thanks,
Richard

On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
mailto:m...@joachim-breitner.de>> wrote:

> Hi,
>
> Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>> mailto:christiaan.ba...@gmail.com>> wrote:
>>> Actually, I meant only with -fno-specialise.
>>
>> Done. Helps quite a bit but CallArity is still a pretty expensive.
>
> I’m on that, and I think I have a quite neat fix for it. I’ll report on
> that in the trac ticket:
> https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>  m...@joachim-breitner.de<mailto:m...@joachim-breitner.de> • 
> http://www.joachim-breitner.de/
>  Jabber: nome...@joachim-breitner.de<mailto:nome...@joachim-breitner.de>  • 
> GPG-Key: 0xF0FBF51F
>

Re: Increased memory usage with GHC 7.10.1

[Greg Weber]

We have observed issues with compile-time inlining taking much longer in
newer versions of GHC in some cases
https://github.com/larskuhtz/toCaseFoldBuildTimes
This particular issue was reported to the text repo:
https://github.com/bos/text/issues/116

On Fri, May 1, 2015 at 7:49 AM, Simon Peyton Jones 
wrote:

>  It would be great if someone could
>
> · create a ticket for Paolio
>
> · investigate what is happening
>
> This smaller test case uses Repa, so it’s not clear that GHC is doing
> anything wrong. Maybe repa is inlining too much?  We need insight.
>
>
>
> Thanks
>
>
>
> SImon
>
>
>
> *From:* Glasgow-haskell-users [mailto:
> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Paolino
> *Sent:* 01 May 2015 15:30
> *To:* George Colpitts
> *Cc:* glasgow-haskell-users@haskell.org
> *Subject:* Re: Increased memory usage with GHC 7.10.1
>
>
>
> here is another file , which is small, which cannot be compiled within
> 4GB  memory.
>
>
> https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs
>
>   I'd just want to add that this problem is a nasty one if one doesn't
> set the max heap: a remote machine frozen that must be rebooted is not a
> nice adventure , hoping the crash remains confined to the vm.
>
> hth, paolino
>
>
>
>
>
>
> 2015-05-01 15:31 GMT+02:00 George Colpitts :
>
>   Should we recommend that all library developers compile their libraries
> with a max heap of 4G (to pick an arbitrary number) so that we can catch
> some of these issues earlier?
>
>
>
> On Fri, May 1, 2015 at 5:42 AM, Paolino  wrote:
>
>   Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now
> impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB
> linux host. The file making memory explode is
> Graphics.Rendering.OpenGL.Raw.Functions
> <https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html>.
> With -O0 it uses 600 MB.
>
> The file is really huge, but I could compile it with prior versions of ghc.
>
> Regards
>
> paolino
>
>
>
> 2015-04-17 1:33 GMT+02:00 David Laing :
>
>   Hi all,
>
> I've been playing around with profiling GHC recently, so I thought I'd
> chime in with a pointer that might save people searching for the right docs
> - you could configure a cabal sandbox to work with multiple version of ghc,
> which I've found useful:
>
>
> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage
>
>
> Cheers,
>
>
>
> Dave
>
>
>
> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta <
> michal.terep...@gmail.com> wrote:
>
>  Hi Richard,
>
> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
> build flavor 'prof' then get the haskell-src-exts sources, install the
> dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
> the resulting ghc.prof contains the profiling information.
>
>
>
> For anyone interested about CallArity slowness, the problem is tracked in
> https://ghc.haskell.org/trac/ghc/ticket/10293
>
>
>
> Cheers,
>
> Michal
>
>
>
> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
> wrote:
>
>  I've pasted Michal's numbers in #9630, which seems like a good place to
> track this. Michal, would you mind fleshing out a bit precisely what you
> did to get those numbers? That would be helpful (though you've already been
> very helpful indeed in getting the data together)!
>
> Thanks,
> Richard
>
> On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
> wrote:
>
> > Hi,
> >
> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
> >>  wrote:
> >>> Actually, I meant only with -fno-specialise.
> >>
> >> Done. Helps quite a bit but CallArity is still a pretty expensive.
> >
> > I’m on that, and I think I have a quite neat fix for it. I’ll report on
> > that in the trac ticket:
> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
> >
> > Greetings,
> > Joachim
> >
> > --
> > Joachim “nomeata” Breitner
> >  m...@joachim-breitner.de • http://www.joachim-breitner.de/
> >  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
> >  Debian Developer: nome...@debian.org
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> > http://mail.haskell.o

RE: Increased memory usage with GHC 7.10.1

[Simon Peyton Jones]

It would be great if someone could

· create a ticket for Paolio

· investigate what is happening
This smaller test case uses Repa, so it’s not clear that GHC is doing anything 
wrong. Maybe repa is inlining too much?  We need insight.

Thanks

SImon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Paolino
Sent: 01 May 2015 15:30
To: George Colpitts
Cc: glasgow-haskell-users@haskell.org
Subject: Re: Increased memory usage with GHC 7.10.1

here is another file , which is small, which cannot be compiled within 4GB  
memory.

https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs

I'd just want to add that this problem is a nasty one if one doesn't set the 
max heap: a remote machine frozen that must be rebooted is not a nice adventure 
, hoping the crash remains confined to the vm.
hth, paolino



2015-05-01 15:31 GMT+02:00 George Colpitts 
mailto:george.colpi...@gmail.com>>:
Should we recommend that all library developers compile their libraries with a 
max heap of 4G (to pick an arbitrary number) so that we can catch some of these 
issues earlier?

On Fri, May 1, 2015 at 5:42 AM, Paolino 
mailto:paolo.verone...@gmail.com>> wrote:
Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with 
-O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file 
making memory explode is  
Graphics.Rendering.OpenGL.Raw.Functions<https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html>.
 With -O0 it uses 600 MB.
The file is really huge, but I could compile it with prior versions of ghc.
Regards
paolino

2015-04-17 1:33 GMT+02:00 David Laing 
mailto:dave.laing...@gmail.com>>:
Hi all,
I've been playing around with profiling GHC recently, so I thought I'd chime in 
with a pointer that might save people searching for the right docs - you could 
configure a cabal sandbox to work with multiple version of ghc, which I've 
found useful:

https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta 
mailto:michal.terep...@gmail.com>> wrote:
Hi Richard,

Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build 
flavor 'prof' then get the haskell-src-exts sources, install the dependencies 
and finally add +RTS -p -RTS to the cabal file and compile it, the resulting 
ghc.prof contains the profiling information.

For anyone interested about CallArity slowness, the problem is tracked in 
https://ghc.haskell.org/trac/ghc/ticket/10293

Cheers,
Michal

On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
mailto:e...@cis.upenn.edu>> wrote:
I've pasted Michal's numbers in #9630, which seems like a good place to track 
this. Michal, would you mind fleshing out a bit precisely what you did to get 
those numbers? That would be helpful (though you've already been very helpful 
indeed in getting the data together)!

Thanks,
Richard

On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
mailto:m...@joachim-breitner.de>> wrote:

> Hi,
>
> Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>> mailto:christiaan.ba...@gmail.com>> wrote:
>>> Actually, I meant only with -fno-specialise.
>>
>> Done. Helps quite a bit but CallArity is still a pretty expensive.
>
> I’m on that, and I think I have a quite neat fix for it. I’ll report on
> that in the trac ticket:
> https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>  m...@joachim-breitner.de<mailto:m...@joachim-breitner.de> • 
> http://www.joachim-breitner.de/
>  Jabber: nome...@joachim-breitner.de<mailto:nome...@joachim-breitner.de>  • 
> GPG-Key: 0xF0FBF51F
>  Debian Developer: nome...@debian.org<mailto:nome...@debian.org>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-u

Re: Increased memory usage with GHC 7.10.1

[Paolino]

here is another file , which is small, which cannot be compiled within 4GB
memory.

https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs


I'd just want to add that this problem is a nasty one if one doesn't set
the max heap: a remote machine frozen that must be rebooted is not a nice
adventure , hoping the crash remains confined to the vm.

hth, paolino



2015-05-01 15:31 GMT+02:00 George Colpitts :

> Should we recommend that all library developers compile their libraries
> with a max heap of 4G (to pick an arbitrary number) so that we can catch
> some of these issues earlier?
>
> On Fri, May 1, 2015 at 5:42 AM, Paolino  wrote:
>
>> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible
>> with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host.
>> The file making memory explode is
>> Graphics.Rendering.OpenGL.Raw.Functions
>> .
>> With -O0 it uses 600 MB.
>>
>> The file is really huge, but I could compile it with prior versions of
>> ghc.
>>
>> Regards
>>
>> paolino
>>
>> 2015-04-17 1:33 GMT+02:00 David Laing :
>>
>>> Hi all,
>>>
>>> I've been playing around with profiling GHC recently, so I thought I'd
>>> chime in with a pointer that might save people searching for the right docs
>>> - you could configure a cabal sandbox to work with multiple version of ghc,
>>> which I've found useful:
>>>
>>>
>>> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage
>>>
>>> Cheers,
>>>
>>> Dave
>>>
>>> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta <
>>> michal.terep...@gmail.com> wrote:
>>>
 Hi Richard,

 Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
 build flavor 'prof' then get the haskell-src-exts sources, install the
 dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
 the resulting ghc.prof contains the profiling information.

 For anyone interested about CallArity slowness, the problem is tracked
 in https://ghc.haskell.org/trac/ghc/ticket/10293

 Cheers,
 Michal

 On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
 wrote:

> I've pasted Michal's numbers in #9630, which seems like a good place
> to track this. Michal, would you mind fleshing out a bit precisely what 
> you
> did to get those numbers? That would be helpful (though you've already 
> been
> very helpful indeed in getting the data together)!
>
> Thanks,
> Richard
>
> On Apr 14, 2015, at 9:09 PM, Joachim Breitner <
> m...@joachim-breitner.de> wrote:
>
> > Hi,
> >
> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
> >>  wrote:
> >>> Actually, I meant only with -fno-specialise.
> >>
> >> Done. Helps quite a bit but CallArity is still a pretty expensive.
> >
> > I’m on that, and I think I have a quite neat fix for it. I’ll report
> on
> > that in the trac ticket:
> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
> >
> > Greetings,
> > Joachim
> >
> > --
> > Joachim “nomeata” Breitner
> >  m...@joachim-breitner.de • http://www.joachim-breitner.de/
> >  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
> >  Debian Developer: nome...@debian.org
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> >
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


>>>
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[George Colpitts]

Should we recommend that all library developers compile their libraries
with a max heap of 4G (to pick an arbitrary number) so that we can catch
some of these issues earlier?

On Fri, May 1, 2015 at 5:42 AM, Paolino  wrote:

> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible
> with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host.
> The file making memory explode is  Graphics.Rendering.OpenGL.Raw.Functions
> .
> With -O0 it uses 600 MB.
>
> The file is really huge, but I could compile it with prior versions of ghc.
>
> Regards
>
> paolino
>
> 2015-04-17 1:33 GMT+02:00 David Laing :
>
>> Hi all,
>>
>> I've been playing around with profiling GHC recently, so I thought I'd
>> chime in with a pointer that might save people searching for the right docs
>> - you could configure a cabal sandbox to work with multiple version of ghc,
>> which I've found useful:
>>
>>
>> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage
>>
>> Cheers,
>>
>> Dave
>>
>> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta <
>> michal.terep...@gmail.com> wrote:
>>
>>> Hi Richard,
>>>
>>> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
>>> build flavor 'prof' then get the haskell-src-exts sources, install the
>>> dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
>>> the resulting ghc.prof contains the profiling information.
>>>
>>> For anyone interested about CallArity slowness, the problem is tracked
>>> in https://ghc.haskell.org/trac/ghc/ticket/10293
>>>
>>> Cheers,
>>> Michal
>>>
>>> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
>>> wrote:
>>>
 I've pasted Michal's numbers in #9630, which seems like a good place to
 track this. Michal, would you mind fleshing out a bit precisely what you
 did to get those numbers? That would be helpful (though you've already been
 very helpful indeed in getting the data together)!

 Thanks,
 Richard

 On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
 wrote:

 > Hi,
 >
 > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
 >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
 >>  wrote:
 >>> Actually, I meant only with -fno-specialise.
 >>
 >> Done. Helps quite a bit but CallArity is still a pretty expensive.
 >
 > I’m on that, and I think I have a quite neat fix for it. I’ll report
 on
 > that in the trac ticket:
 > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
 >
 > Greetings,
 > Joachim
 >
 > --
 > Joachim “nomeata” Breitner
 >  m...@joachim-breitner.de • http://www.joachim-breitner.de/
 >  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
 >  Debian Developer: nome...@debian.org
 > ___
 > Glasgow-haskell-users mailing list
 > Glasgow-haskell-users@haskell.org
 >
 http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

>>>
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Paolino]

I did the worst and splitted the file.  It worked.
Still waiting ghc trac to send me the verification mails

paolino

2015-05-01 14:22 GMT+02:00 Paolino :

> not that lucky, as it's btrfs which doesn't allow swapon :-/
> btw, thanks for the hint
>
> paolino
>
> 2015-05-01 14:00 GMT+02:00 Carter Schonwald :
>
>> as a near term mitigation, could you enable having swap files on your VM ?
>>
>> On Fri, May 1, 2015 at 5:00 AM, Paolino 
>> wrote:
>>
>>> Ghc trac is not sending the verification emails and won't let me file a
>>> bug without. As soon as this gets fixed I will.
>>>
>>> Thanks
>>>
>>> paolino
>>>
>>> 2015-05-01 10:44 GMT+02:00 Simon Peyton Jones :
>>>
>>>>  Can you open a ticket, please? And put as much data as you can.
>>>> Using `-dshow-passes` (both for 7.10 and prior versions) and showing the
>>>> output would be helpful.
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:* Glasgow-haskell-users [mailto:
>>>> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Paolino
>>>> *Sent:* 01 May 2015 09:42
>>>> *To:* glasgow-haskell-users@haskell.org
>>>> *Subject:* Re: Increased memory usage with GHC 7.10.1
>>>>
>>>>
>>>>
>>>> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now
>>>> impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB
>>>> linux host. The file making memory explode is
>>>> Graphics.Rendering.OpenGL.Raw.Functions
>>>> <https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html>.
>>>> With -O0 it uses 600 MB.
>>>>
>>>> The file is really huge, but I could compile it with prior versions of
>>>> ghc.
>>>>
>>>> Regards
>>>>
>>>> paolino
>>>>
>>>>
>>>>
>>>> 2015-04-17 1:33 GMT+02:00 David Laing :
>>>>
>>>>   Hi all,
>>>>
>>>> I've been playing around with profiling GHC recently, so I thought I'd
>>>> chime in with a pointer that might save people searching for the right docs
>>>> - you could configure a cabal sandbox to work with multiple version of ghc,
>>>> which I've found useful:
>>>>
>>>>
>>>> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage
>>>>
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>> Dave
>>>>
>>>>
>>>>
>>>> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta <
>>>> michal.terep...@gmail.com> wrote:
>>>>
>>>>  Hi Richard,
>>>>
>>>> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
>>>> build flavor 'prof' then get the haskell-src-exts sources, install the
>>>> dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
>>>> the resulting ghc.prof contains the profiling information.
>>>>
>>>>
>>>>
>>>> For anyone interested about CallArity slowness, the problem is tracked
>>>> in https://ghc.haskell.org/trac/ghc/ticket/10293
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Michal
>>>>
>>>>
>>>>
>>>> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
>>>> wrote:
>>>>
>>>>  I've pasted Michal's numbers in #9630, which seems like a good place
>>>> to track this. Michal, would you mind fleshing out a bit precisely what you
>>>> did to get those numbers? That would be helpful (though you've already been
>>>> very helpful indeed in getting the data together)!
>>>>
>>>> Thanks,
>>>> Richard
>>>>
>>>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
>>>> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>>>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>>>> >>  wrote:
>>>> >>> Actually, I meant only with -fno-specialise

Re: Increased memory usage with GHC 7.10.1

[Paolino]

not that lucky, as it's btrfs which doesn't allow swapon :-/
btw, thanks for the hint

paolino

2015-05-01 14:00 GMT+02:00 Carter Schonwald :

> as a near term mitigation, could you enable having swap files on your VM ?
>
> On Fri, May 1, 2015 at 5:00 AM, Paolino  wrote:
>
>> Ghc trac is not sending the verification emails and won't let me file a
>> bug without. As soon as this gets fixed I will.
>>
>> Thanks
>>
>> paolino
>>
>> 2015-05-01 10:44 GMT+02:00 Simon Peyton Jones :
>>
>>>  Can you open a ticket, please? And put as much data as you can.  Using
>>> `-dshow-passes` (both for 7.10 and prior versions) and showing the output
>>> would be helpful.
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Glasgow-haskell-users [mailto:
>>> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Paolino
>>> *Sent:* 01 May 2015 09:42
>>> *To:* glasgow-haskell-users@haskell.org
>>> *Subject:* Re: Increased memory usage with GHC 7.10.1
>>>
>>>
>>>
>>> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible
>>> with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host.
>>> The file making memory explode is
>>> Graphics.Rendering.OpenGL.Raw.Functions
>>> <https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html>.
>>> With -O0 it uses 600 MB.
>>>
>>> The file is really huge, but I could compile it with prior versions of
>>> ghc.
>>>
>>> Regards
>>>
>>> paolino
>>>
>>>
>>>
>>> 2015-04-17 1:33 GMT+02:00 David Laing :
>>>
>>>   Hi all,
>>>
>>> I've been playing around with profiling GHC recently, so I thought I'd
>>> chime in with a pointer that might save people searching for the right docs
>>> - you could configure a cabal sandbox to work with multiple version of ghc,
>>> which I've found useful:
>>>
>>>
>>> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Dave
>>>
>>>
>>>
>>> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta <
>>> michal.terep...@gmail.com> wrote:
>>>
>>>  Hi Richard,
>>>
>>> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
>>> build flavor 'prof' then get the haskell-src-exts sources, install the
>>> dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
>>> the resulting ghc.prof contains the profiling information.
>>>
>>>
>>>
>>> For anyone interested about CallArity slowness, the problem is tracked
>>> in https://ghc.haskell.org/trac/ghc/ticket/10293
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Michal
>>>
>>>
>>>
>>> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
>>> wrote:
>>>
>>>  I've pasted Michal's numbers in #9630, which seems like a good place to
>>> track this. Michal, would you mind fleshing out a bit precisely what you
>>> did to get those numbers? That would be helpful (though you've already been
>>> very helpful indeed in getting the data together)!
>>>
>>> Thanks,
>>> Richard
>>>
>>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>>> >>  wrote:
>>> >>> Actually, I meant only with -fno-specialise.
>>> >>
>>> >> Done. Helps quite a bit but CallArity is still a pretty expensive.
>>> >
>>> > I’m on that, and I think I have a quite neat fix for it. I’ll report on
>>> > that in the trac ticket:
>>> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>>> >
>>> > Greetings,
>>> > Joachim
>>> >
>>> > --
>>> > Joachim “nomeata” Breitner
>>> >  m...@joachim-breitner.de • http://www.joachim-breitner.de/
>>> >  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>>> >  Debian Developer: nome...@debian.org
>&

Re: Increased memory usage with GHC 7.10.1

[Carter Schonwald]

as a near term mitigation, could you enable having swap files on your VM ?

On Fri, May 1, 2015 at 5:00 AM, Paolino  wrote:

> Ghc trac is not sending the verification emails and won't let me file a
> bug without. As soon as this gets fixed I will.
>
> Thanks
>
> paolino
>
> 2015-05-01 10:44 GMT+02:00 Simon Peyton Jones :
>
>>  Can you open a ticket, please? And put as much data as you can.  Using
>> `-dshow-passes` (both for 7.10 and prior versions) and showing the output
>> would be helpful.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Glasgow-haskell-users [mailto:
>> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Paolino
>> *Sent:* 01 May 2015 09:42
>> *To:* glasgow-haskell-users@haskell.org
>> *Subject:* Re: Increased memory usage with GHC 7.10.1
>>
>>
>>
>> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible
>> with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host.
>> The file making memory explode is
>> Graphics.Rendering.OpenGL.Raw.Functions
>> <https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html>.
>> With -O0 it uses 600 MB.
>>
>> The file is really huge, but I could compile it with prior versions of
>> ghc.
>>
>> Regards
>>
>> paolino
>>
>>
>>
>> 2015-04-17 1:33 GMT+02:00 David Laing :
>>
>>   Hi all,
>>
>> I've been playing around with profiling GHC recently, so I thought I'd
>> chime in with a pointer that might save people searching for the right docs
>> - you could configure a cabal sandbox to work with multiple version of ghc,
>> which I've found useful:
>>
>>
>> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage
>>
>>
>> Cheers,
>>
>>
>>
>> Dave
>>
>>
>>
>> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta <
>> michal.terep...@gmail.com> wrote:
>>
>>  Hi Richard,
>>
>> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
>> build flavor 'prof' then get the haskell-src-exts sources, install the
>> dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
>> the resulting ghc.prof contains the profiling information.
>>
>>
>>
>> For anyone interested about CallArity slowness, the problem is tracked in
>> https://ghc.haskell.org/trac/ghc/ticket/10293
>>
>>
>>
>> Cheers,
>>
>> Michal
>>
>>
>>
>> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
>> wrote:
>>
>>  I've pasted Michal's numbers in #9630, which seems like a good place to
>> track this. Michal, would you mind fleshing out a bit precisely what you
>> did to get those numbers? That would be helpful (though you've already been
>> very helpful indeed in getting the data together)!
>>
>> Thanks,
>> Richard
>>
>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
>> wrote:
>>
>> > Hi,
>> >
>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>> >>  wrote:
>> >>> Actually, I meant only with -fno-specialise.
>> >>
>> >> Done. Helps quite a bit but CallArity is still a pretty expensive.
>> >
>> > I’m on that, and I think I have a quite neat fix for it. I’ll report on
>> > that in the trac ticket:
>> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>> >
>> > Greetings,
>> > Joachim
>> >
>> > --
>> > Joachim “nomeata” Breitner
>> >  m...@joachim-breitner.de • http://www.joachim-breitner.de/
>> >  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>> >  Debian Developer: nome...@debian.org
>> > ___
>> > Glasgow-haskell-users mailing list
>> > Glasgow-haskell-users@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Paolino]

Ghc trac is not sending the verification emails and won't let me file a bug
without. As soon as this gets fixed I will.

Thanks

paolino

2015-05-01 10:44 GMT+02:00 Simon Peyton Jones :

>  Can you open a ticket, please? And put as much data as you can.  Using
> `-dshow-passes` (both for 7.10 and prior versions) and showing the output
> would be helpful.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:
> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Paolino
> *Sent:* 01 May 2015 09:42
> *To:* glasgow-haskell-users@haskell.org
> *Subject:* Re: Increased memory usage with GHC 7.10.1
>
>
>
> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible
> with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host.
> The file making memory explode is  Graphics.Rendering.OpenGL.Raw.Functions
> <https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html>.
> With -O0 it uses 600 MB.
>
> The file is really huge, but I could compile it with prior versions of ghc.
>
> Regards
>
> paolino
>
>
>
> 2015-04-17 1:33 GMT+02:00 David Laing :
>
>   Hi all,
>
> I've been playing around with profiling GHC recently, so I thought I'd
> chime in with a pointer that might save people searching for the right docs
> - you could configure a cabal sandbox to work with multiple version of ghc,
> which I've found useful:
>
>
> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage
>
>
> Cheers,
>
>
>
> Dave
>
>
>
> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta <
> michal.terep...@gmail.com> wrote:
>
>  Hi Richard,
>
> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
> build flavor 'prof' then get the haskell-src-exts sources, install the
> dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
> the resulting ghc.prof contains the profiling information.
>
>
>
> For anyone interested about CallArity slowness, the problem is tracked in
> https://ghc.haskell.org/trac/ghc/ticket/10293
>
>
>
> Cheers,
>
> Michal
>
>
>
> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
> wrote:
>
>  I've pasted Michal's numbers in #9630, which seems like a good place to
> track this. Michal, would you mind fleshing out a bit precisely what you
> did to get those numbers? That would be helpful (though you've already been
> very helpful indeed in getting the data together)!
>
> Thanks,
> Richard
>
> On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
> wrote:
>
> > Hi,
> >
> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
> >>  wrote:
> >>> Actually, I meant only with -fno-specialise.
> >>
> >> Done. Helps quite a bit but CallArity is still a pretty expensive.
> >
> > I’m on that, and I think I have a quite neat fix for it. I’ll report on
> > that in the trac ticket:
> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
> >
> > Greetings,
> > Joachim
> >
> > --
> > Joachim “nomeata” Breitner
> >  m...@joachim-breitner.de • http://www.joachim-breitner.de/
> >  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
> >  Debian Developer: nome...@debian.org
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Increased memory usage with GHC 7.10.1

[Simon Peyton Jones]

Can you open a ticket, please? And put as much data as you can.  Using 
`-dshow-passes` (both for 7.10 and prior versions) and showing the output would 
be helpful.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Paolino
Sent: 01 May 2015 09:42
To: glasgow-haskell-users@haskell.org
Subject: Re: Increased memory usage with GHC 7.10.1

Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with 
-O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file 
making memory explode is  
Graphics.Rendering.OpenGL.Raw.Functions<https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html>.
 With -O0 it uses 600 MB.
The file is really huge, but I could compile it with prior versions of ghc.
Regards
paolino

2015-04-17 1:33 GMT+02:00 David Laing 
mailto:dave.laing...@gmail.com>>:
Hi all,
I've been playing around with profiling GHC recently, so I thought I'd chime in 
with a pointer that might save people searching for the right docs - you could 
configure a cabal sandbox to work with multiple version of ghc, which I've 
found useful:

https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta 
mailto:michal.terep...@gmail.com>> wrote:
Hi Richard,

Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build 
flavor 'prof' then get the haskell-src-exts sources, install the dependencies 
and finally add +RTS -p -RTS to the cabal file and compile it, the resulting 
ghc.prof contains the profiling information.

For anyone interested about CallArity slowness, the problem is tracked in 
https://ghc.haskell.org/trac/ghc/ticket/10293

Cheers,
Michal

On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
mailto:e...@cis.upenn.edu>> wrote:
I've pasted Michal's numbers in #9630, which seems like a good place to track 
this. Michal, would you mind fleshing out a bit precisely what you did to get 
those numbers? That would be helpful (though you've already been very helpful 
indeed in getting the data together)!

Thanks,
Richard

On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
mailto:m...@joachim-breitner.de>> wrote:

> Hi,
>
> Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>> mailto:christiaan.ba...@gmail.com>> wrote:
>>> Actually, I meant only with -fno-specialise.
>>
>> Done. Helps quite a bit but CallArity is still a pretty expensive.
>
> I’m on that, and I think I have a quite neat fix for it. I’ll report on
> that in the trac ticket:
> https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>  m...@joachim-breitner.de<mailto:m...@joachim-breitner.de> • 
> http://www.joachim-breitner.de/
>  Jabber: nome...@joachim-breitner.de<mailto:nome...@joachim-breitner.de>  • 
> GPG-Key: 0xF0FBF51F
>  Debian Developer: nome...@debian.org<mailto:nome...@debian.org>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Paolino]

Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible
with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host.
The file making memory explode is  Graphics.Rendering.OpenGL.Raw.Functions
.
With -O0 it uses 600 MB.

The file is really huge, but I could compile it with prior versions of ghc.

Regards

paolino

2015-04-17 1:33 GMT+02:00 David Laing :

> Hi all,
>
> I've been playing around with profiling GHC recently, so I thought I'd
> chime in with a pointer that might save people searching for the right docs
> - you could configure a cabal sandbox to work with multiple version of ghc,
> which I've found useful:
>
>
> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage
>
> Cheers,
>
> Dave
>
> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta <
> michal.terep...@gmail.com> wrote:
>
>> Hi Richard,
>>
>> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
>> build flavor 'prof' then get the haskell-src-exts sources, install the
>> dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
>> the resulting ghc.prof contains the profiling information.
>>
>> For anyone interested about CallArity slowness, the problem is tracked in
>> https://ghc.haskell.org/trac/ghc/ticket/10293
>>
>> Cheers,
>> Michal
>>
>> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
>> wrote:
>>
>>> I've pasted Michal's numbers in #9630, which seems like a good place to
>>> track this. Michal, would you mind fleshing out a bit precisely what you
>>> did to get those numbers? That would be helpful (though you've already been
>>> very helpful indeed in getting the data together)!
>>>
>>> Thanks,
>>> Richard
>>>
>>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>>> >>  wrote:
>>> >>> Actually, I meant only with -fno-specialise.
>>> >>
>>> >> Done. Helps quite a bit but CallArity is still a pretty expensive.
>>> >
>>> > I’m on that, and I think I have a quite neat fix for it. I’ll report on
>>> > that in the trac ticket:
>>> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>>> >
>>> > Greetings,
>>> > Joachim
>>> >
>>> > --
>>> > Joachim “nomeata” Breitner
>>> >  m...@joachim-breitner.de • http://www.joachim-breitner.de/
>>> >  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>>> >  Debian Developer: nome...@debian.org
>>> > ___
>>> > Glasgow-haskell-users mailing list
>>> > Glasgow-haskell-users@haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[David Laing]

Hi all,

I've been playing around with profiling GHC recently, so I thought I'd
chime in with a pointer that might save people searching for the right docs
- you could configure a cabal sandbox to work with multiple version of ghc,
which I've found useful:

https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta 
wrote:

> Hi Richard,
>
> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
> build flavor 'prof' then get the haskell-src-exts sources, install the
> dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
> the resulting ghc.prof contains the profiling information.
>
> For anyone interested about CallArity slowness, the problem is tracked in
> https://ghc.haskell.org/trac/ghc/ticket/10293
>
> Cheers,
> Michal
>
> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
> wrote:
>
>> I've pasted Michal's numbers in #9630, which seems like a good place to
>> track this. Michal, would you mind fleshing out a bit precisely what you
>> did to get those numbers? That would be helpful (though you've already been
>> very helpful indeed in getting the data together)!
>>
>> Thanks,
>> Richard
>>
>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
>> wrote:
>>
>> > Hi,
>> >
>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>> >>  wrote:
>> >>> Actually, I meant only with -fno-specialise.
>> >>
>> >> Done. Helps quite a bit but CallArity is still a pretty expensive.
>> >
>> > I’m on that, and I think I have a quite neat fix for it. I’ll report on
>> > that in the trac ticket:
>> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>> >
>> > Greetings,
>> > Joachim
>> >
>> > --
>> > Joachim “nomeata” Breitner
>> >  m...@joachim-breitner.de • http://www.joachim-breitner.de/
>> >  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>> >  Debian Developer: nome...@debian.org
>> > ___
>> > Glasgow-haskell-users mailing list
>> > Glasgow-haskell-users@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Michal Terepeta]

Hi Richard,

Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build
flavor 'prof' then get the haskell-src-exts sources, install the
dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
the resulting ghc.prof contains the profiling information.

For anyone interested about CallArity slowness, the problem is tracked in
https://ghc.haskell.org/trac/ghc/ticket/10293

Cheers,
Michal

On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg  wrote:

> I've pasted Michal's numbers in #9630, which seems like a good place to
> track this. Michal, would you mind fleshing out a bit precisely what you
> did to get those numbers? That would be helpful (though you've already been
> very helpful indeed in getting the data together)!
>
> Thanks,
> Richard
>
> On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
> wrote:
>
> > Hi,
> >
> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
> >>  wrote:
> >>> Actually, I meant only with -fno-specialise.
> >>
> >> Done. Helps quite a bit but CallArity is still a pretty expensive.
> >
> > I’m on that, and I think I have a quite neat fix for it. I’ll report on
> > that in the trac ticket:
> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
> >
> > Greetings,
> > Joachim
> >
> > --
> > Joachim “nomeata” Breitner
> >  m...@joachim-breitner.de • http://www.joachim-breitner.de/
> >  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
> >  Debian Developer: nome...@debian.org
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Richard Eisenberg]

I've pasted Michal's numbers in #9630, which seems like a good place to track 
this. Michal, would you mind fleshing out a bit precisely what you did to get 
those numbers? That would be helpful (though you've already been very helpful 
indeed in getting the data together)!

Thanks,
Richard

On Apr 14, 2015, at 9:09 PM, Joachim Breitner  wrote:

> Hi,
> 
> Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>>  wrote:
>>> Actually, I meant only with -fno-specialise.
>> 
>> Done. Helps quite a bit but CallArity is still a pretty expensive.
> 
> I’m on that, and I think I have a quite neat fix for it. I’ll report on
> that in the trac ticket:
> https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
> 
> Greetings,
> Joachim
> 
> -- 
> Joachim “nomeata” Breitner
>  m...@joachim-breitner.de • http://www.joachim-breitner.de/
>  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>  Debian Developer: nome...@debian.org
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Joachim Breitner]

Hi,

Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>  wrote:
> > Actually, I meant only with -fno-specialise.
> 
> Done. Helps quite a bit but CallArity is still a pretty expensive.

I’m on that, and I think I have a quite neat fix for it. I’ll report on
that in the trac ticket:
https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org


signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Michal Terepeta]

On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
 wrote:
> Actually, I meant only with -fno-specialise.

Done. Helps quite a bit but CallArity is still a pretty expensive.


Tue Apr 14 21:46 2015 Time and Allocation Profiling Report  (Final)

  ghc +RTS -p -RTS [...] -fno-specialise

total time  =  109.78 secs   (109784 ticks @ 1000 us, 1 processor)
total alloc = 124,469,615,048 bytes  (excludes profiling overheads)

COST CENTRE   MODULE   %time %alloc

SimplTopBinds SimplCore 35.4   32.4
CallArity SimplCore 13.4   20.7
pprNativeCode AsmCodeGen 4.14.5
OccAnal   SimplCore  3.13.1
StgCmmHscMain3.02.5
occAnalBind.assoc OccurAnal  3.03.1
RegAlloc  AsmCodeGen 2.63.2
tc_rn_src_decls   TcRnDriver 2.51.8
regLiveness   AsmCodeGen 2.42.6
Simplify  SimplCore  2.30.1
FloatOutwards SimplCore  2.31.8
sink  CmmPipeline2.22.0
genMachCode   AsmCodeGen 1.51.3
NewStranalSimplCore  1.51.7
layoutStack   CmmPipeline1.31.3
NativeCodeGen CodeOutput 1.21.1
FloatInwards  SimplCore  1.01.2
Digraph.scc   Digraph0.81.2
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Christiaan Baaij]

Actually, I meant only with -fno-specialise.

On 13 April 2015 at 21:09, Michal Terepeta 
wrote:

> On Mon, Apr 13, 2015 at 12:20 PM, Christiaan Baaij
>  wrote:
> >
> > Hi,
> >
> > I wonder if this might be in any way related to the HUGE amount of new
> terms/types/coercions created by the specialiser as documented in:
> > https://ghc.haskell.org/trac/ghc/ticket/9630#comment:10
> >
> > I don’t have a profiled version of GHC, so I was wondering if you could
> run your tests with a ‘-fno-specialise’, and see how everything performs
> then?
> >
> > Cheers,
> >
> > Christiaan
>
> Unfortunately trac is timing out for me, so I'll have a look at the
> issues later...
>
> As for compiling haskell-src-exts with both -fno-specialise and
> -fno-call-arity,
> we're pretty much at the same level as GHC 7.8.4.
>
>
>
> Mon Apr 13 20:25 2015 Time and Allocation Profiling Report  (Final)
>
>   ghc +RTS -p -RTS  [...] -fno-specialise -fno-call-arity
>
> total time  =   89.93 secs   (89928 ticks @ 1000 us, 1 processor)
> total alloc = 93,495,685,792 bytes  (excludes profiling overheads)
>
> COST CENTRE   MODULE  %time %alloc
>
> SimplTopBinds SimplCore38.7   38.6
> pprNativeCode AsmCodeGen5.15.9
> StgCmmHscMain   3.73.3
> occAnalBind.assoc OccurAnal 3.23.6
> OccAnal   SimplCore 3.23.6
> tc_rn_src_decls   TcRnDriver3.12.5
> RegAlloc  AsmCodeGen3.14.2
> regLiveness   AsmCodeGen3.03.5
> FloatOutwards SimplCore 2.72.4
> sink  CmmPipeline   2.62.7
> Simplify  SimplCore 2.50.1
> NewStranalSimplCore 1.92.3
> genMachCode   AsmCodeGen1.81.7
> layoutStack   CmmPipeline   1.61.7
> NativeCodeGen CodeOutput1.41.5
> FloatInwards  SimplCore 1.21.6
> CoreTidy  HscMain   1.21.2
> deSugar   HscMain   1.21.2
> do_block  Hoopl.Dataflow1.10.7
> CorePrep  HscMain   1.01.1
> versioninfo   MkIface   0.91.0
> ParserHscMain   0.91.2
> Digraph.scc   Digraph   0.91.5
> canEvVar  TcCanonical   0.71.0
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Michal Terepeta]

On Mon, Apr 13, 2015 at 12:20 PM, Christiaan Baaij
 wrote:
>
> Hi,
>
> I wonder if this might be in any way related to the HUGE amount of new 
> terms/types/coercions created by the specialiser as documented in:
> https://ghc.haskell.org/trac/ghc/ticket/9630#comment:10
>
> I don’t have a profiled version of GHC, so I was wondering if you could run 
> your tests with a ‘-fno-specialise’, and see how everything performs then?
>
> Cheers,
>
> Christiaan

Unfortunately trac is timing out for me, so I'll have a look at the
issues later...

As for compiling haskell-src-exts with both -fno-specialise and -fno-call-arity,
we're pretty much at the same level as GHC 7.8.4.



Mon Apr 13 20:25 2015 Time and Allocation Profiling Report  (Final)

  ghc +RTS -p -RTS  [...] -fno-specialise -fno-call-arity

total time  =   89.93 secs   (89928 ticks @ 1000 us, 1 processor)
total alloc = 93,495,685,792 bytes  (excludes profiling overheads)

COST CENTRE   MODULE  %time %alloc

SimplTopBinds SimplCore38.7   38.6
pprNativeCode AsmCodeGen5.15.9
StgCmmHscMain   3.73.3
occAnalBind.assoc OccurAnal 3.23.6
OccAnal   SimplCore 3.23.6
tc_rn_src_decls   TcRnDriver3.12.5
RegAlloc  AsmCodeGen3.14.2
regLiveness   AsmCodeGen3.03.5
FloatOutwards SimplCore 2.72.4
sink  CmmPipeline   2.62.7
Simplify  SimplCore 2.50.1
NewStranalSimplCore 1.92.3
genMachCode   AsmCodeGen1.81.7
layoutStack   CmmPipeline   1.61.7
NativeCodeGen CodeOutput1.41.5
FloatInwards  SimplCore 1.21.6
CoreTidy  HscMain   1.21.2
deSugar   HscMain   1.21.2
do_block  Hoopl.Dataflow1.10.7
CorePrep  HscMain   1.01.1
versioninfo   MkIface   0.91.0
ParserHscMain   0.91.2
Digraph.scc   Digraph   0.91.5
canEvVar  TcCanonical   0.71.0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Christiaan Baaij]

Hi,

I wonder if this might be in any way related to the HUGE amount of new 
terms/types/coercions created by the specialiser as documented in:
https://ghc.haskell.org/trac/ghc/ticket/9630#comment:10 


I don’t have a profiled version of GHC, so I was wondering if you could run 
your tests with a ‘-fno-specialise’, and see how everything performs then?

Cheers,

Christiaan

> On 12 Apr 2015, at 18:28, Michal Terepeta  wrote:
> 
> So I've tried to compile Idris/Agda with prof compilers but this
> didn't quite work out due to deps not compiling (apparently it's not
> possible to use template haskell with a profiled compiler).
> 
> Out of curiosity I had a look at compiling haskell-src-exts since that
> takes quite a while. I've used ghc HEAD and 7.8.4 (both built with
> BuildFlavour=prof & bootstrapped with a standard ghc 7.8.4) and it's
> interesting -- the current HEAD takes quite a bit longer and allocates
> way more than 7.8.4. One of the main things that stand out is the
> CallArity analysis (which IIRC was not there in 7.8.4). So unless I
> messed something up with measuring, the analysis seem to be
> pretty expensive.
> 
> Anyway, the results are below.
> 
> Cheers,
> Michal
> 
> 
> ** HEAD
> 
>   Sun Apr 12 15:52 2015 Time and Allocation Profiling Report  (Final)
> 
>  ghc +RTS -p -RTS [...]
> 
>   total time  =  147.84 secs   (147841 ticks @ 1000 us, 1 processor)
>   total alloc = 172,378,600,408 bytes  (excludes profiling overheads)
> 
> COST CENTRE   MODULE   %time %alloc
> 
> SimplTopBinds SimplCore 32.4   28.8
> CallArity SimplCore 18.4   25.6
> lintAnnotsCoreLint   4.54.6
> CoreTidy  HscMain4.55.1
> pprNativeCode AsmCodeGen 3.23.4
> OccAnal   SimplCore  3.23.1
> occAnalBind.assoc OccurAnal  2.62.5
> StgCmmHscMain2.31.9
> Simplify  SimplCore  2.10.2
> RegAlloc  AsmCodeGen 2.12.4
> FloatOutwards SimplCore  2.01.6
> regLiveness   AsmCodeGen 1.91.9
> tc_rn_src_decls   TcRnDriver 1.81.3
> sink  CmmPipeline1.71.5
> NewStranalSimplCore  1.31.5
> genMachCode   AsmCodeGen 1.11.0
> layoutStack   CmmPipeline1.01.0
> 
> 
> ** HEAD with -fno-call-arity
> 
>   Sun Apr 12 18:16 2015 Time and Allocation Profiling Report  (Final)
> 
>  ghc +RTS -p -RTS [...] -fno-call-arity
> 
>   total time  =  113.71 secs   (113714 ticks @ 1000 us, 1 processor)
>   total alloc = 121,884,896,720 bytes  (excludes profiling overheads)
> 
> COST CENTRE   MODULE  %time %alloc
> 
> SimplTopBinds SimplCore37.2   36.6
> CoreTidy  HscMain   6.07.3
> lintAnnotsCoreLint  5.86.5
> pprNativeCode AsmCodeGen4.14.8
> OccAnal   SimplCore 3.63.8
> occAnalBind.assoc OccurAnal 2.93.2
> StgCmmHscMain   2.92.6
> RegAlloc  AsmCodeGen2.63.4
> FloatOutwards SimplCore 2.62.3
> regLiveness   AsmCodeGen2.52.8
> tc_rn_src_decls   TcRnDriver2.41.9
> Simplify  SimplCore 2.40.3
> sink  CmmPipeline   2.12.2
> NewStranalSimplCore 1.72.1
> genMachCode   AsmCodeGen1.41.4
> layoutStack   CmmPipeline   1.41.4
> NativeCodeGen CodeOutput1.11.2
> FloatInwards  SimplCore 1.11.4
> do_block  Hoopl.Dataflow1.00.6
> Digraph.scc   Digraph   0.81.3
> 
> 
> ** 7.8.4
> 
>   Sun Apr 12 15:41 2015 Time and Allocation Profiling Report  (Final)
> 
>  ghc +RTS -p -RTS [...]
> 
>   total time  =   93.11 secs   (93112 ticks @ 1000 us, 1 processor)
>   total alloc = 103,135,975,120 bytes  (excludes profiling overheads)
> 
> COST CENTRE MODULE %time %alloc
> 
> SimplTopBinds   SimplCore   38.5   37.4
> pprNativeCode   AsmCodeGen   6.27.2
> StgCmm  HscMain  3.94.2
> RegAllocAsmCodeGen   3.75.1
> occAnalBind.assoc   OccurAnal3.33.6
> OccAnal SimplCore3.33.6
> regLiveness AsmCodeGen   3.13.4
> FloatOutwards   SimplCore2.92.4
> sinkCmmPipeline  2.82.8
> SimplifySimplCore2.60.3
> tc_rn_src_decls TcRnDriver   2.42.1
> genMachCode AsmCodeGen   1.92.0
> NewStranal  SimplCore1.82.1
> layoutStack CmmPipeline  1.81.8
> Core2Core   HscMain  1.31.2
> deSugar Hsc

Re: Increased memory usage with GHC 7.10.1

[Michal Terepeta]

So I've tried to compile Idris/Agda with prof compilers but this
didn't quite work out due to deps not compiling (apparently it's not
possible to use template haskell with a profiled compiler).

Out of curiosity I had a look at compiling haskell-src-exts since that
takes quite a while. I've used ghc HEAD and 7.8.4 (both built with
BuildFlavour=prof & bootstrapped with a standard ghc 7.8.4) and it's
interesting -- the current HEAD takes quite a bit longer and allocates
way more than 7.8.4. One of the main things that stand out is the
CallArity analysis (which IIRC was not there in 7.8.4). So unless I
messed something up with measuring, the analysis seem to be
pretty expensive.

Anyway, the results are below.

Cheers,
Michal


** HEAD

Sun Apr 12 15:52 2015 Time and Allocation Profiling Report  (Final)

   ghc +RTS -p -RTS [...]

total time  =  147.84 secs   (147841 ticks @ 1000 us, 1 processor)
total alloc = 172,378,600,408 bytes  (excludes profiling overheads)

COST CENTRE   MODULE   %time %alloc

SimplTopBinds SimplCore 32.4   28.8
CallArity SimplCore 18.4   25.6
lintAnnotsCoreLint   4.54.6
CoreTidy  HscMain4.55.1
pprNativeCode AsmCodeGen 3.23.4
OccAnal   SimplCore  3.23.1
occAnalBind.assoc OccurAnal  2.62.5
StgCmmHscMain2.31.9
Simplify  SimplCore  2.10.2
RegAlloc  AsmCodeGen 2.12.4
FloatOutwards SimplCore  2.01.6
regLiveness   AsmCodeGen 1.91.9
tc_rn_src_decls   TcRnDriver 1.81.3
sink  CmmPipeline1.71.5
NewStranalSimplCore  1.31.5
genMachCode   AsmCodeGen 1.11.0
layoutStack   CmmPipeline1.01.0


** HEAD with -fno-call-arity

Sun Apr 12 18:16 2015 Time and Allocation Profiling Report  (Final)

   ghc +RTS -p -RTS [...] -fno-call-arity

total time  =  113.71 secs   (113714 ticks @ 1000 us, 1 processor)
total alloc = 121,884,896,720 bytes  (excludes profiling overheads)

COST CENTRE   MODULE  %time %alloc

SimplTopBinds SimplCore37.2   36.6
CoreTidy  HscMain   6.07.3
lintAnnotsCoreLint  5.86.5
pprNativeCode AsmCodeGen4.14.8
OccAnal   SimplCore 3.63.8
occAnalBind.assoc OccurAnal 2.93.2
StgCmmHscMain   2.92.6
RegAlloc  AsmCodeGen2.63.4
FloatOutwards SimplCore 2.62.3
regLiveness   AsmCodeGen2.52.8
tc_rn_src_decls   TcRnDriver2.41.9
Simplify  SimplCore 2.40.3
sink  CmmPipeline   2.12.2
NewStranalSimplCore 1.72.1
genMachCode   AsmCodeGen1.41.4
layoutStack   CmmPipeline   1.41.4
NativeCodeGen CodeOutput1.11.2
FloatInwards  SimplCore 1.11.4
do_block  Hoopl.Dataflow1.00.6
Digraph.scc   Digraph   0.81.3


** 7.8.4

Sun Apr 12 15:41 2015 Time and Allocation Profiling Report  (Final)

   ghc +RTS -p -RTS [...]

total time  =   93.11 secs   (93112 ticks @ 1000 us, 1 processor)
total alloc = 103,135,975,120 bytes  (excludes profiling overheads)

COST CENTRE MODULE %time %alloc

SimplTopBinds   SimplCore   38.5   37.4
pprNativeCode   AsmCodeGen   6.27.2
StgCmm  HscMain  3.94.2
RegAllocAsmCodeGen   3.75.1
occAnalBind.assoc   OccurAnal3.33.6
OccAnal SimplCore3.33.6
regLiveness AsmCodeGen   3.13.4
FloatOutwards   SimplCore2.92.4
sinkCmmPipeline  2.82.8
SimplifySimplCore2.60.3
tc_rn_src_decls TcRnDriver   2.42.1
genMachCode AsmCodeGen   1.92.0
NewStranal  SimplCore1.82.1
layoutStack CmmPipeline  1.81.8
Core2Core   HscMain  1.31.2
deSugar HscMain  1.11.1
do_blockHoopl.Dataflow   1.10.7
CoreTidyHscMain  1.01.1
CorePrepHscMain  1.01.1
Digraph.scc Digraph  0.91.5
versioninfo MkIface  0.91.0
zonkEvBndr_zonkTcTypeToType TcHsSyn  0.61.4


On Fri, Apr 3, 2015 at 4:49 PM David Feuer  wrote:

> On a machine with an SSD instead of a hard disk, swapping greatly reduces
> the lifespan of the storage device.
>
> On Fri, Apr 3, 2015 at 10:14 AM, Bertram Felgenhauer <
> bertram.felgenha...@googlemail.com> wrote:
>
>> George Colpitts wrote:
>> > I'm curious why the amount of RAM is relevant as all of our OS have
>> virtual
>> > memory so it is only the size

Re: Increased memory usage with GHC 7.10.1

[David Feuer]

On a machine with an SSD instead of a hard disk, swapping greatly reduces
the lifespan of the storage device.

On Fri, Apr 3, 2015 at 10:14 AM, Bertram Felgenhauer <
bertram.felgenha...@googlemail.com> wrote:

> George Colpitts wrote:
> > I'm curious why the amount of RAM is relevant as all of our OS have
> virtual
> > memory so it is only the size of the heap and the amount of swap that
> > should be relevant for an Out Of Memory error, right?
>
> The computer may not be your own. VPSs are essentially priced based on
> RAM available to the virtual server, and have limited swapping space,
> so this is an area where increased memory consumption hurts. Building
> binaries elsewhere is usually an option, but more painful than doing
> it on the VPS itself.
>
> Cheers,
>
> Bertram
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Bertram Felgenhauer]

George Colpitts wrote:
> I'm curious why the amount of RAM is relevant as all of our OS have virtual
> memory so it is only the size of the heap and the amount of swap that
> should be relevant for an Out Of Memory error, right?

The computer may not be your own. VPSs are essentially priced based on
RAM available to the virtual server, and have limited swapping space,
so this is an area where increased memory consumption hurts. Building
binaries elsewhere is usually an option, but more painful than doing
it on the VPS itself.

Cheers,

Bertram
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Andrés Sicard-Ramírez]

In a 64-bit machine with Ubuntu 12.04 and 4 GB of RAM, I can compile
Agda using GHC 7.10.1 without problems. Agda's compilation time
increased ~26% with respect to GHC 7.8.4.


On 2 April 2015 at 07:19, Jan Stolarek  wrote:
> An update frrom my second machine, this time with 4GB of RAM. Compiling Agda 
> ran out of memory
> (again Agda.TypeChecking.Serialise module) and I had to kill the build. But 
> once I restarted the
> build the module was compiled succesfully in a matter of minutes and using 
> around 50% of memory.
> This looks like some kind of memory leak in GHC.
>
> Janek
>
> Dnia środa, 1 kwietnia 2015, Jan Stolarek napisał:
>> Forall hi,
>>
>> I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed
>> installations of GHC and this means I had to rebuild Agda and Idris because
>> the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4
>> sandbox. Sadly, I had problems building both Agda and Idris due to GHC
>> taking up all of available memory.
>>
>> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
>> interesting part of the story is that when I do a clean build of Idris GHC
>> consumes all of memory when compiling that module and I have to kill the
>> build. But when I restart the build after killing GHC the module is
>> compiled using a reasonable amount of memory and within reasonable time.
>>
>> With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC).
>> The trick with killing the build and restarting it didn't work in this
>> case. I had to compile Agda with GHC 7.8.4 (which works without problems
>> though the mentioned module still requires a lot of memory) and alter my
>> setup so that Agda binary is not stored inside GHC sandbox.
>>
>> I wonder if any of you came across similar issues with GHC 7.10.1? Do we
>> have any performance data that allows to compare memory usage and
>> performance of GHC 7.10.1 with previous stable releases?
>>
>> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
>>
>> Janek
>>
>> ---
>> Politechnika Łódzka
>> Lodz University of Technology
>>
>> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
>> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
>> pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>>
>> This email contains information intended solely for the use of the
>> individual to whom it is addressed. If you are not the intended recipient
>> or if you have received this message in error, please notify the sender and
>> delete it from your system.
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez 
> pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>
> This email contains information intended solely for the use of the individual 
> to whom it is addressed.
> If you are not the intended recipient or if you have received this message in 
> error,
> please notify the sender and delete it from your system.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



-- 
Andrés
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Michael Jones]

I have run out of memory before when compiling on small machines using GHC 7.8, 
where small machines have 4GB RAM, no swap, say small Dual Core Atom, almost 
embedded design. That forced me to compile on a laptop and mount file systems 
to run it. But since Ubuntu runs well on a NUC, it is nice to be able to run 
the compiler on it, even if a bit slow.


On Apr 2, 2015, at 9:08 AM, George Colpitts  wrote:

> I'm curious why the amount of RAM is relevant as all of our OS have virtual 
> memory so it is only the size of the heap and the amount of swap that should 
> be relevant for an Out Of Memory error, right? How big is your heap? Amount 
> of RAM should only affect speed (i.e. if there is excessive paging) but 
> should not affect Out Of Memory right?
> 
> On Thu, Apr 2, 2015 at 9:47 AM, Jan Stolarek  wrote:
> I will. But I was curious whether this is only me or is anyone else seeing 
> similar behaviour. And
> what about performance comparisson between 7.8.4 and 7.10.1? Do we have any 
> numbers?
> 
> Janek
> 
> Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisał:
> > Post a bug report! :)
> >
> > On Apr 2, 2015, at 8:19 AM, Jan Stolarek  wrote:
> > > An update frrom my second machine, this time with 4GB of RAM. Compiling
> > > Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I
> > > had to kill the build. But once I restarted the build the module was
> > > compiled succesfully in a matter of minutes and using around 50% of
> > > memory. This looks like some kind of memory leak in GHC.
> > >
> > > Janek
> > >
> > > Dnia środa, 1 kwietnia 2015, Jan Stolarek napisał:
> > >> Forall hi,
> > >>
> > >> I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed
> > >> installations of GHC and this means I had to rebuild Agda and Idris
> > >> because the binaries built with GHC 7.8.4 were stored inside deactivated
> > >> 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to
> > >> GHC taking up all of available memory.
> > >>
> > >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
> > >> interesting part of the story is that when I do a clean build of Idris
> > >> GHC consumes all of memory when compiling that module and I have to kill
> > >> the build. But when I restart the build after killing GHC the module is
> > >> compiled using a reasonable amount of memory and within reasonable time.
> > >>
> > >> With Agda the problematic module is Agda.TypeChecking.Serialise
> > >> (~2000LOC). The trick with killing the build and restarting it didn't
> > >> work in this case. I had to compile Agda with GHC 7.8.4 (which works
> > >> without problems though the mentioned module still requires a lot of
> > >> memory) and alter my setup so that Agda binary is not stored inside GHC
> > >> sandbox.
> > >>
> > >> I wonder if any of you came across similar issues with GHC 7.10.1? Do we
> > >> have any performance data that allows to compare memory usage and
> > >> performance of GHC 7.10.1 with previous stable releases?
> > >>
> > >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
> > >>
> > >> Janek
> > >>
> > >> ---
> > >> Politechnika Łódzka
> > >> Lodz University of Technology
> > >>
> > >> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > >> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > >> pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> > >>
> > >> This email contains information intended solely for the use of the
> > >> individual to whom it is addressed. If you are not the intended
> > >> recipient or if you have received this message in error, please notify
> > >> the sender and delete it from your system.
> > >> ___
> > >> Glasgow-haskell-users mailing list
> > >> Glasgow-haskell-users@haskell.org
> > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> > >
> > > ---
> > > Politechnika Łódzka
> > > Lodz University of Technology
> > >
> > > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > > pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> > >
> > > This email contains information intended solely for the use of the
> > > individual to whom it is addressed. If you are not the intended recipient
> > > or if you have received this message in error, please notify the sender
> > > and delete it from your system.
> > > ___
> > > Glasgow-haskell-users mailing list
> > > Glasgow-haskell-users@haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> 
> 
> 
> ---
> Politechnika Łódzka
> Lodz University of Technology
> 
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez 
> pomyłkę
> 

Re: Increased memory usage with GHC 7.10.1

[Jan Stolarek]

> I'm curious why the amount of RAM is relevant as all of our OS have virtual
> memory so it is only the size of the heap and the amount of swap that
> should be relevant for an Out Of Memory error, right? How big is your heap?
> Amount of RAM should only affect speed (i.e. if there is excessive paging)
> but should not affect Out Of Memory right?
Actually, I never allowed GHC to completely run out of memory. I just killed 
the build process 
when it consumed all of physical RAM memory and started growing into swap. At 
that point machine 
becomes barely usable and the build practically stalls as CPU usage drops to 0. 
FYI: both 
machines have size of swap equal to size of RAM.

Janek


---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[George Colpitts]

I'm curious why the amount of RAM is relevant as all of our OS have virtual
memory so it is only the size of the heap and the amount of swap that
should be relevant for an Out Of Memory error, right? How big is your heap?
Amount of RAM should only affect speed (i.e. if there is excessive paging)
but should not affect Out Of Memory right?

On Thu, Apr 2, 2015 at 9:47 AM, Jan Stolarek  wrote:

> I will. But I was curious whether this is only me or is anyone else seeing
> similar behaviour. And
> what about performance comparisson between 7.8.4 and 7.10.1? Do we have
> any numbers?
>
> Janek
>
> Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisał:
> > Post a bug report! :)
> >
> > On Apr 2, 2015, at 8:19 AM, Jan Stolarek  wrote:
> > > An update frrom my second machine, this time with 4GB of RAM. Compiling
> > > Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I
> > > had to kill the build. But once I restarted the build the module was
> > > compiled succesfully in a matter of minutes and using around 50% of
> > > memory. This looks like some kind of memory leak in GHC.
> > >
> > > Janek
> > >
> > > Dnia środa, 1 kwietnia 2015, Jan Stolarek napisał:
> > >> Forall hi,
> > >>
> > >> I just uprgaded both of my machines to use GHC 7.10.1. I keep
> sandboxed
> > >> installations of GHC and this means I had to rebuild Agda and Idris
> > >> because the binaries built with GHC 7.8.4 were stored inside
> deactivated
> > >> 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due
> to
> > >> GHC taking up all of available memory.
> > >>
> > >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
> > >> interesting part of the story is that when I do a clean build of Idris
> > >> GHC consumes all of memory when compiling that module and I have to
> kill
> > >> the build. But when I restart the build after killing GHC the module
> is
> > >> compiled using a reasonable amount of memory and within reasonable
> time.
> > >>
> > >> With Agda the problematic module is Agda.TypeChecking.Serialise
> > >> (~2000LOC). The trick with killing the build and restarting it didn't
> > >> work in this case. I had to compile Agda with GHC 7.8.4 (which works
> > >> without problems though the mentioned module still requires a lot of
> > >> memory) and alter my setup so that Agda binary is not stored inside
> GHC
> > >> sandbox.
> > >>
> > >> I wonder if any of you came across similar issues with GHC 7.10.1? Do
> we
> > >> have any performance data that allows to compare memory usage and
> > >> performance of GHC 7.10.1 with previous stable releases?
> > >>
> > >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
> > >>
> > >> Janek
> > >>
> > >> ---
> > >> Politechnika Łódzka
> > >> Lodz University of Technology
> > >>
> > >> Treść tej wiadomości zawiera informacje przeznaczone tylko dla
> adresata.
> > >> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją
> przez
> > >> pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej
> usunięcie.
> > >>
> > >> This email contains information intended solely for the use of the
> > >> individual to whom it is addressed. If you are not the intended
> > >> recipient or if you have received this message in error, please notify
> > >> the sender and delete it from your system.
> > >> ___
> > >> Glasgow-haskell-users mailing list
> > >> Glasgow-haskell-users@haskell.org
> > >>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> > >
> > > ---
> > > Politechnika Łódzka
> > > Lodz University of Technology
> > >
> > > Treść tej wiadomości zawiera informacje przeznaczone tylko dla
> adresata.
> > > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > > pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej
> usunięcie.
> > >
> > > This email contains information intended solely for the use of the
> > > individual to whom it is addressed. If you are not the intended
> recipient
> > > or if you have received this message in error, please notify the sender
> > > and delete it from your system.
> > > ___
> > > Glasgow-haskell-users mailing list
> > > Glasgow-haskell-users@haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message
> in error,
> please notify the sender and delete it from your system.
> ___
> ghc-devs mailing list
> ghc-d...@

Re: Increased memory usage with GHC 7.10.1

[Dan Doel]

You aren't the only one. The vector test suite also has these kind of
issues. In its case, it's hard for me to tell how big the code is, because
template haskell is being used to generate it. However, I don't think the
template haskell is what's using the additional performance, because the
test suite is compiled with both -O0 and -O2, and only the latter runs into
performance issues.

In vector's case, 7.6.3 compiles significantly faster than 7.8.4, which is
in turn significantly faster than 7.10.1. And memory usage follows the same
pattern (with -O2 at least). 7.6.3 uses ~400MB of memory, 7.8.4 1-2GB and
7.10.1 3-4GB (if I'm remembering correctly). And while I can build the
tests on 7.10 in around 5 minutes, travis times out building them after
around half an hour.

On Thu, Apr 2, 2015 at 8:47 AM, Jan Stolarek  wrote:

> I will. But I was curious whether this is only me or is anyone else seeing
> similar behaviour. And
> what about performance comparisson between 7.8.4 and 7.10.1? Do we have
> any numbers?
>
> Janek
>
> Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisał:
> > Post a bug report! :)
> >
> > On Apr 2, 2015, at 8:19 AM, Jan Stolarek  wrote:
> > > An update frrom my second machine, this time with 4GB of RAM. Compiling
> > > Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I
> > > had to kill the build. But once I restarted the build the module was
> > > compiled succesfully in a matter of minutes and using around 50% of
> > > memory. This looks like some kind of memory leak in GHC.
> > >
> > > Janek
> > >
> > > Dnia środa, 1 kwietnia 2015, Jan Stolarek napisał:
> > >> Forall hi,
> > >>
> > >> I just uprgaded both of my machines to use GHC 7.10.1. I keep
> sandboxed
> > >> installations of GHC and this means I had to rebuild Agda and Idris
> > >> because the binaries built with GHC 7.8.4 were stored inside
> deactivated
> > >> 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due
> to
> > >> GHC taking up all of available memory.
> > >>
> > >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
> > >> interesting part of the story is that when I do a clean build of Idris
> > >> GHC consumes all of memory when compiling that module and I have to
> kill
> > >> the build. But when I restart the build after killing GHC the module
> is
> > >> compiled using a reasonable amount of memory and within reasonable
> time.
> > >>
> > >> With Agda the problematic module is Agda.TypeChecking.Serialise
> > >> (~2000LOC). The trick with killing the build and restarting it didn't
> > >> work in this case. I had to compile Agda with GHC 7.8.4 (which works
> > >> without problems though the mentioned module still requires a lot of
> > >> memory) and alter my setup so that Agda binary is not stored inside
> GHC
> > >> sandbox.
> > >>
> > >> I wonder if any of you came across similar issues with GHC 7.10.1? Do
> we
> > >> have any performance data that allows to compare memory usage and
> > >> performance of GHC 7.10.1 with previous stable releases?
> > >>
> > >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
> > >>
> > >> Janek
> > >>
> > >> ---
> > >> Politechnika Łódzka
> > >> Lodz University of Technology
> > >>
> > >> Treść tej wiadomości zawiera informacje przeznaczone tylko dla
> adresata.
> > >> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją
> przez
> > >> pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej
> usunięcie.
> > >>
> > >> This email contains information intended solely for the use of the
> > >> individual to whom it is addressed. If you are not the intended
> > >> recipient or if you have received this message in error, please notify
> > >> the sender and delete it from your system.
> > >> ___
> > >> Glasgow-haskell-users mailing list
> > >> Glasgow-haskell-users@haskell.org
> > >>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> > >
> > > ---
> > > Politechnika Łódzka
> > > Lodz University of Technology
> > >
> > > Treść tej wiadomości zawiera informacje przeznaczone tylko dla
> adresata.
> > > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > > pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej
> usunięcie.
> > >
> > > This email contains information intended solely for the use of the
> > > individual to whom it is addressed. If you are not the intended
> recipient
> > > or if you have received this message in error, please notify the sender
> > > and delete it from your system.
> > > ___
> > > Glasgow-haskell-users mailing list
> > > Glasgow-haskell-users@haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrz

Re: Increased memory usage with GHC 7.10.1

[Jan Stolarek]

I will. But I was curious whether this is only me or is anyone else seeing 
similar behaviour. And 
what about performance comparisson between 7.8.4 and 7.10.1? Do we have any 
numbers?

Janek

Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisał:
> Post a bug report! :)
>
> On Apr 2, 2015, at 8:19 AM, Jan Stolarek  wrote:
> > An update frrom my second machine, this time with 4GB of RAM. Compiling
> > Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I
> > had to kill the build. But once I restarted the build the module was
> > compiled succesfully in a matter of minutes and using around 50% of
> > memory. This looks like some kind of memory leak in GHC.
> >
> > Janek
> >
> > Dnia środa, 1 kwietnia 2015, Jan Stolarek napisał:
> >> Forall hi,
> >>
> >> I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed
> >> installations of GHC and this means I had to rebuild Agda and Idris
> >> because the binaries built with GHC 7.8.4 were stored inside deactivated
> >> 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to
> >> GHC taking up all of available memory.
> >>
> >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
> >> interesting part of the story is that when I do a clean build of Idris
> >> GHC consumes all of memory when compiling that module and I have to kill
> >> the build. But when I restart the build after killing GHC the module is
> >> compiled using a reasonable amount of memory and within reasonable time.
> >>
> >> With Agda the problematic module is Agda.TypeChecking.Serialise
> >> (~2000LOC). The trick with killing the build and restarting it didn't
> >> work in this case. I had to compile Agda with GHC 7.8.4 (which works
> >> without problems though the mentioned module still requires a lot of
> >> memory) and alter my setup so that Agda binary is not stored inside GHC
> >> sandbox.
> >>
> >> I wonder if any of you came across similar issues with GHC 7.10.1? Do we
> >> have any performance data that allows to compare memory usage and
> >> performance of GHC 7.10.1 with previous stable releases?
> >>
> >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
> >>
> >> Janek
> >>
> >> ---
> >> Politechnika Łódzka
> >> Lodz University of Technology
> >>
> >> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> >> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> >> pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >>
> >> This email contains information intended solely for the use of the
> >> individual to whom it is addressed. If you are not the intended
> >> recipient or if you have received this message in error, please notify
> >> the sender and delete it from your system.
> >> ___
> >> Glasgow-haskell-users mailing list
> >> Glasgow-haskell-users@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed. If you are not the intended recipient
> > or if you have received this message in error, please notify the sender
> > and delete it from your system.
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Richard Eisenberg]

Post a bug report! :)

On Apr 2, 2015, at 8:19 AM, Jan Stolarek  wrote:

> An update frrom my second machine, this time with 4GB of RAM. Compiling Agda 
> ran out of memory 
> (again Agda.TypeChecking.Serialise module) and I had to kill the build. But 
> once I restarted the 
> build the module was compiled succesfully in a matter of minutes and using 
> around 50% of memory. 
> This looks like some kind of memory leak in GHC.
> 
> Janek
> 
> Dnia środa, 1 kwietnia 2015, Jan Stolarek napisał:
>> Forall hi,
>> 
>> I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed
>> installations of GHC and this means I had to rebuild Agda and Idris because
>> the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4
>> sandbox. Sadly, I had problems building both Agda and Idris due to GHC
>> taking up all of available memory.
>> 
>> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
>> interesting part of the story is that when I do a clean build of Idris GHC
>> consumes all of memory when compiling that module and I have to kill the
>> build. But when I restart the build after killing GHC the module is
>> compiled using a reasonable amount of memory and within reasonable time.
>> 
>> With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC).
>> The trick with killing the build and restarting it didn't work in this
>> case. I had to compile Agda with GHC 7.8.4 (which works without problems
>> though the mentioned module still requires a lot of memory) and alter my
>> setup so that Agda binary is not stored inside GHC sandbox.
>> 
>> I wonder if any of you came across similar issues with GHC 7.10.1? Do we
>> have any performance data that allows to compare memory usage and
>> performance of GHC 7.10.1 with previous stable releases?
>> 
>> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
>> 
>> Janek
>> 
>> ---
>> Politechnika Łódzka
>> Lodz University of Technology
>> 
>> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
>> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
>> pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>> 
>> This email contains information intended solely for the use of the
>> individual to whom it is addressed. If you are not the intended recipient
>> or if you have received this message in error, please notify the sender and
>> delete it from your system.
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> 
> 
> 
> ---
> Politechnika Łódzka
> Lodz University of Technology
> 
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez 
> pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> 
> This email contains information intended solely for the use of the individual 
> to whom it is addressed.
> If you are not the intended recipient or if you have received this message in 
> error,
> please notify the sender and delete it from your system.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Jan Stolarek]

An update frrom my second machine, this time with 4GB of RAM. Compiling Agda 
ran out of memory 
(again Agda.TypeChecking.Serialise module) and I had to kill the build. But 
once I restarted the 
build the module was compiled succesfully in a matter of minutes and using 
around 50% of memory. 
This looks like some kind of memory leak in GHC.

Janek

Dnia środa, 1 kwietnia 2015, Jan Stolarek napisał:
> Forall hi,
>
> I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed
> installations of GHC and this means I had to rebuild Agda and Idris because
> the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4
> sandbox. Sadly, I had problems building both Agda and Idris due to GHC
> taking up all of available memory.
>
> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
> interesting part of the story is that when I do a clean build of Idris GHC
> consumes all of memory when compiling that module and I have to kill the
> build. But when I restart the build after killing GHC the module is
> compiled using a reasonable amount of memory and within reasonable time.
>
> With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC).
> The trick with killing the build and restarting it didn't work in this
> case. I had to compile Agda with GHC 7.8.4 (which works without problems
> though the mentioned module still requires a lot of memory) and alter my
> setup so that Agda binary is not stored inside GHC sandbox.
>
> I wonder if any of you came across similar issues with GHC 7.10.1? Do we
> have any performance data that allows to compare memory usage and
> performance of GHC 7.10.1 with previous stable releases?
>
> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
>
> Janek
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed. If you are not the intended recipient
> or if you have received this message in error, please notify the sender and
> delete it from your system.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Increased memory usage with GHC 7.10.1

[Jan Stolarek]

Forall hi,

I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed 
installations of GHC and 
this means I had to rebuild Agda and Idris because the binaries built with GHC 
7.8.4 were stored 
inside deactivated 7.8.4 sandbox. Sadly, I had problems building both Agda and 
Idris due to GHC 
taking up all of available memory.

With Idris the problematic module was Idris.ElabTerm (~2900LOC). The 
interesting part of the story 
is that when I do a clean build of Idris GHC consumes all of memory when 
compiling that module 
and I have to kill the build. But when I restart the build after killing GHC 
the module is 
compiled using a reasonable amount of memory and within reasonable time.

With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). The 
trick with killing 
the build and restarting it didn't work in this case. I had to compile Agda 
with GHC 7.8.4 (which 
works without problems though the mentioned module still requires a lot of 
memory) and alter my 
setup so that Agda binary is not stored inside GHC sandbox.

I wonder if any of you came across similar issues with GHC 7.10.1? Do we have 
any performance data 
that allows to compare memory usage and performance of GHC 7.10.1 with previous 
stable releases?

All of the above happened on 64bit Debian Wheezy with 2GB of RAM.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users