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.

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

...

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ą

Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisał: 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-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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ę 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-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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.felgenhauer@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

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 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 lintAnnots CoreLint 4.5 4.6 CoreTidy HscMain 4.5 5.1 pprNativeCode AsmCodeGen 3.2 3.4 OccAnal SimplCore 3.2 3.1 occAnalBind.assoc OccurAnal 2.6 2.5 StgCmm HscMain 2.3 1.9 Simplify SimplCore 2.1 0.2 RegAlloc AsmCodeGen 2.1 2.4 FloatOutwards SimplCore 2.0 1.6 regLiveness AsmCodeGen 1.9 1.9 tc_rn_src_decls TcRnDriver 1.8 1.3 sink CmmPipeline 1.7 1.5 NewStranal SimplCore 1.3 1.5 genMachCode AsmCodeGen 1.1 1.0 layoutStack CmmPipeline 1.0 1.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 SimplCore 37.2 36.6 CoreTidy HscMain 6.0 7.3 lintAnnots CoreLint 5.8 6.5 pprNativeCode AsmCodeGen 4.1 4.8 OccAnal SimplCore 3.6 3.8 occAnalBind.assoc OccurAnal 2.9 3.2 StgCmm HscMain 2.9 2.6 RegAlloc AsmCodeGen 2.6 3.4 FloatOutwards SimplCore 2.6 2.3 regLiveness AsmCodeGen 2.5 2.8 tc_rn_src_decls TcRnDriver 2.4 1.9 Simplify SimplCore 2.4 0.3 sink CmmPipeline 2.1 2.2 NewStranal SimplCore 1.7 2.1 genMachCode AsmCodeGen 1.4 1.4 layoutStack CmmPipeline 1.4 1.4 NativeCodeGen CodeOutput 1.1 1.2 FloatInwards SimplCore 1.1 1.4 do_block Hoopl.Dataflow 1.0 0.6 Digraph.scc Digraph 0.8 1.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.2 7.2 StgCmm HscMain 3.9 4.2 RegAlloc AsmCodeGen 3.7 5.1 occAnalBind.assoc OccurAnal 3.3 3.6 OccAnal SimplCore 3.3 3.6 regLiveness AsmCodeGen 3.1 3.4 FloatOutwards SimplCore 2.9 2.4 sink CmmPipeline 2.8 2.8 Simplify SimplCore 2.6 0.3 tc_rn_src_decls TcRnDriver 2.4 2.1 genMachCode AsmCodeGen 1.9 2.0 NewStranal SimplCore 1.8 2.1 layoutStack CmmPipeline 1.8 1.8 Core2Core HscMain 1.3 1.2 deSugar HscMain 1.1 1.1 do_block Hoopl.Dataflow 1.1 0.7 CoreTidy HscMain 1.0 1.1 CorePrep HscMain 1.0 1.1 Digraph.scc Digraph 0.9 1.5 versioninfo MkIface 0.9 1.0 zonkEvBndr_zonkTcTypeToType TcHsSyn 0.6 1.4

On Fri, Apr 3, 2015 at 4:49 PM David Feuer mailto:david.feuer@gmail.com> 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 mailto:bertram.felgenhauer@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 mailto:Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users 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 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

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

...

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

terms/types/coercions created by the specialiser as documented in: 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 SimplCore 38.7 38.6 pprNativeCode AsmCodeGen 5.1 5.9 StgCmm HscMain 3.7 3.3 occAnalBind.assoc OccurAnal 3.2 3.6 OccAnal SimplCore 3.2 3.6 tc_rn_src_decls TcRnDriver 3.1 2.5 RegAlloc AsmCodeGen 3.1 4.2 regLiveness AsmCodeGen 3.0 3.5 FloatOutwards SimplCore 2.7 2.4 sink CmmPipeline 2.6 2.7 Simplify SimplCore 2.5 0.1 NewStranal SimplCore 1.9 2.3 genMachCode AsmCodeGen 1.8 1.7 layoutStack CmmPipeline 1.6 1.7 NativeCodeGen CodeOutput 1.4 1.5 FloatInwards SimplCore 1.2 1.6 CoreTidy HscMain 1.2 1.2 deSugar HscMain 1.2 1.2 do_block Hoopl.Dataflow 1.1 0.7 CorePrep HscMain 1.0 1.1 versioninfo MkIface 0.9 1.0 Parser HscMain 0.9 1.2 Digraph.scc Digraph 0.9 1.5 canEvVar TcCanonical 0.7 1.0

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 mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

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 mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@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

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-Rend.... 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...

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < michal.terepeta@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 mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@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

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-bounces@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-Rend.... 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...

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < michal.terepeta@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 mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@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

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-bounces@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-Rend.... 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...

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < michal.terepeta@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 mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@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

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-Rend.... 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...

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta < michal.terepeta@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 mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@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

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-bounces@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/raste... 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.colpitts@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.veronelli@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.Functionshttps://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rend.... 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.80@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... Cheers, Dave On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta mailto:michal.terepeta@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:eir@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:mail@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.baaij@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 mail@joachim-breitner.demailto:mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.demailto:nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.orgmailto:nomeata@debian.org _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.orgmailto: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.orgmailto: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.orgmailto: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.orgmailto: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.orgmailto:Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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:greg@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:simonpj@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-bounces@haskell.orgmailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Paolino Sent: 01 May 2015 15:30 To: George Colpitts Cc: glasgow-haskell-users@haskell.orgmailto: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/raste... 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.colpitts@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.veronelli@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.Functionshttps://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rend.... 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.80@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... Cheers, Dave On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta mailto:michal.terepeta@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:eir@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:mail@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.baaij@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 mail@joachim-breitner.demailto:mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.demailto:nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.orgmailto:nomeata@debian.org _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.orgmailto: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.orgmailto: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.orgmailto: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.orgmailto: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.orgmailto: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.orgmailto:Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Hello, I succeded in compiling https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rend... 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

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-Rend...

...

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

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