From voldermort at hotmail.com Wed Apr 1 09:30:49 2015 From: voldermort at hotmail.com (Jeremy) Date: Wed, 1 Apr 2015 02:30:49 -0700 (MST) Subject: Binary bloat in 7.10 Message-ID: <1427880649570-5768067.post@n5.nabble.com> Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with 15M libHSCabal-1.18.1.5.a 17M HSCabal-1.18.1.5.o whereas 7.10 balloons to 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From voldermort at hotmail.com Wed Apr 1 10:57:15 2015 From: voldermort at hotmail.com (Jeremy) Date: Wed, 1 Apr 2015 03:57:15 -0700 (MST) Subject: Binary bloat in 7.10 In-Reply-To: <1427880649570-5768067.post@n5.nabble.com> References: <1427880649570-5768067.post@n5.nabble.com> Message-ID: <1427885835200-5768072.post@n5.nabble.com> It's not just binaries, even hi files have ballooned. (I should note that (stripped) executables appear to be unaffected.) -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768072.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From karel.gardas at centrum.cz Wed Apr 1 11:52:44 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 01 Apr 2015 13:52:44 +0200 Subject: Binary bloat in 7.10 In-Reply-To: <1427880649570-5768067.post@n5.nabble.com> References: <1427880649570-5768067.post@n5.nabble.com> Message-ID: <551BDC0C.9060900@centrum.cz> 7.10.1 should IIRC support some kind of DWARF debugging information and IIRC it was mentioned and decided on ghc devel that the libraries will ship with some DWARF to easy debugging -- but takes me lightly on it and verify if this is the case since I may be completely off and this may apply to GHC HEAD and not to 7.10.x Karel On 04/ 1/15 11:30 AM, Jeremy wrote: > Why do the 7.10 libraries take up so much more space than 7.8? For example, > using the same build options and strip --strip-unneeded, 7.8 leaves me with > > 15M libHSCabal-1.18.1.5.a > 17M HSCabal-1.18.1.5.o > > whereas 7.10 balloons to > > 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o > 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a > > > > -- > View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067.html > Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From voldermort at hotmail.com Wed Apr 1 11:58:01 2015 From: voldermort at hotmail.com (Jeremy) Date: Wed, 1 Apr 2015 04:58:01 -0700 (MST) Subject: Binary bloat in 7.10 In-Reply-To: <551BDC0C.9060900@centrum.cz> References: <1427880649570-5768067.post@n5.nabble.com> <551BDC0C.9060900@centrum.cz> Message-ID: <1427889481911-5768077.post@n5.nabble.com> Karel Gardas wrote > 7.10.1 should IIRC support some kind of DWARF debugging information and > IIRC it was mentioned and decided on ghc devel that the libraries will > ship with some DWARF to easy debugging > > -- but takes me lightly on it and verify if this is the case since I may > be completely off and this may apply to GHC HEAD and not to 7.10.x Stripped all debugging, didn't help. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768077.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From roma at ro-che.info Wed Apr 1 12:23:44 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 01 Apr 2015 15:23:44 +0300 Subject: Binary bloat in 7.10 In-Reply-To: <1427880649570-5768067.post@n5.nabble.com> References: <1427880649570-5768067.post@n5.nabble.com> Message-ID: <551BE350.3080405@ro-che.info> On 01/04/15 12:30, Jeremy wrote: > Why do the 7.10 libraries take up so much more space than 7.8? For example, > using the same build options and strip --strip-unneeded, 7.8 leaves me with > > 15M libHSCabal-1.18.1.5.a > 17M HSCabal-1.18.1.5.o > > whereas 7.10 balloons to > > 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o > 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a I'm not denying (or confirming) your claim, but it would look more legitimate if you compared the same version of Cabal compiled with different versions of GHC. At least some of this bloat could be because Cabal simply gained more code. Roman From jan.stolarek at p.lodz.pl Wed Apr 1 12:26:06 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 1 Apr 2015 14:26:06 +0200 Subject: Increased memory usage with GHC 7.10.1 Message-ID: <201504011426.06628.jan.stolarek@p.lodz.pl> 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. From voldermort at hotmail.com Wed Apr 1 12:36:52 2015 From: voldermort at hotmail.com (Jeremy) Date: Wed, 1 Apr 2015 05:36:52 -0700 (MST) Subject: Binary bloat in 7.10 In-Reply-To: <551BE350.3080405@ro-che.info> References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> Message-ID: <1427891812585-5768080.post@n5.nabble.com> Roman Cheplyaka-2 wrote > I'm not denying (or confirming) your claim, but it would look more > legitimate if you compared the same version of Cabal compiled with > different versions of GHC. > > At least some of this bloat could be because Cabal simply gained more > code. Tricky to test that because of dependencies and global package db. I haven't measured the amount of code in Cabal, but I doubt it's increased that much, and there has been a big jump in the installed size of every library. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768080.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From voldermort at hotmail.com Wed Apr 1 13:40:16 2015 From: voldermort at hotmail.com (Jeremy) Date: Wed, 1 Apr 2015 06:40:16 -0700 (MST) Subject: Binary bloat in 7.10 In-Reply-To: <551BE350.3080405@ro-che.info> References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> Message-ID: <1427895616257-5768083.post@n5.nabble.com> Roman Cheplyaka-2 wrote > I'm not denying (or confirming) your claim, but it would look more > legitimate if you compared the same version of Cabal compiled with > different versions of GHC. > > At least some of this bloat could be because Cabal simply gained more > code. I was going to prove you wrong by identifying packages which have barely changed for 7.10 ... and found that those packages were a similar size to their 7.8 versions. However, the size increase in other packages is huge, and "simply gained more code" doesn't seem like an adequate explanation, with some package more than doubling. Here are the full results: 7.8: 34M Cabal-1.18.1.5 3.8M array-0.5.0.0 50M base-4.7.0.2 52M bin 368K bin-package-db-0.0.0.0 2.7M binary-0.7.1.0 5.4M bytestring-0.10.4.0 9.4M containers-0.5.5.1 196K deepseq-1.3.0.2 608K directory-1.2.1.0 740K filepath-1.3.0.2 105M ghc-7.8.4 2.7M ghc-prim-0.3.1.0 8.7M haskeline-0.7.1.2 3.4M hoopl-3.10.0.1 1020K hpc-0.6.0.1 556K integer-gmp-0.5.1.0 680K pretty-1.1.1.1 684K process-1.2.0.0 1.6M rts-1.0 13M template-haskell-2.9.0.0 1.4M terminfo-0.4.0.0 6.1M time-1.4.2 4.4M transformers-0.3.0.0 5.2M unix-2.7.0.1 7.10: 83M Cabal_HWT8QvVfJLn2ubvobpycJY 3.7M array_FaHmcBFfuRM8kmZLEY8D5S 52M base_I5BErHzyOm07EBNpKBEeUv 56M bin 2.9M binar_EKE3c9Lmxb3DQpU0fPtru6 832K binpa_JNoexmBMuO8C771QaIy3YN 5.7M bytes_6vj5EoliHgNHISHCVCb069 11M conta_47ajk3tbda43DFWyeF3oHQ 432K deeps_FpR4obOZALU1lutWnrBldi 912K direc_3TcTyYedch32o1zTH2MR00 796K filep_5HhyRonfEZoDO205Wm9E4h 113M ghc_EMlWrQ42XY0BNVbSrKixqY 2.9M ghcpr_8TmvWUcS1U1IKHT0levwg3 8.9M haske_IlDhIe25uAn0WJY379Nu1M 3.4M hoopl_JxODiSRz1e84NbH6nnZuUk 1.1M hpc_CmUUQl5bURfBueJrdYfNs3 1.3M integ_2aU3IZNMF9a7mQ0OzsZ0dS 1.8M prett_7jIfj8VCGFf1WS0tIQ1XSZ 764K proce_0hwN3CTKynhHQqQkChnSdH 1.7M rts 19M templ_BVMCZyLwIlfGfcqqzyUAI8 1.4M termi_7qZwBlx3clR8sTBilJl253 6.2M time_Hh2clZW6in4HpYHx5bLtb7 7.3M trans_ALYlebOVzVI4kxbFX5SGhm 5.4M unix_G4Yo1pNtYrk8nCq1cx8P9d -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768083.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From carter.schonwald at gmail.com Wed Apr 1 14:17:33 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 1 Apr 2015 10:17:33 -0400 Subject: Binary bloat in 7.10 In-Reply-To: <1427895616257-5768083.post@n5.nabble.com> References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> Message-ID: How much of this might be attributable to longer linker symbol names? Ghc 7.10 object code does have larger symbols! Is there a way to easily tabulate that? On Apr 1, 2015 9:40 AM, "Jeremy" wrote: > Roman Cheplyaka-2 wrote > > I'm not denying (or confirming) your claim, but it would look more > > legitimate if you compared the same version of Cabal compiled with > > different versions of GHC. > > > > At least some of this bloat could be because Cabal simply gained more > > code. > > I was going to prove you wrong by identifying packages which have barely > changed for 7.10 ... and found that those packages were a similar size to > their 7.8 versions. > > However, the size increase in other packages is huge, and "simply gained > more code" doesn't seem like an adequate explanation, with some package > more > than doubling. > > Here are the full results: > > 7.8: > > 34M Cabal-1.18.1.5 > 3.8M array-0.5.0.0 > 50M base-4.7.0.2 > 52M bin > 368K bin-package-db-0.0.0.0 > 2.7M binary-0.7.1.0 > 5.4M bytestring-0.10.4.0 > 9.4M containers-0.5.5.1 > 196K deepseq-1.3.0.2 > 608K directory-1.2.1.0 > 740K filepath-1.3.0.2 > 105M ghc-7.8.4 > 2.7M ghc-prim-0.3.1.0 > 8.7M haskeline-0.7.1.2 > 3.4M hoopl-3.10.0.1 > 1020K hpc-0.6.0.1 > 556K integer-gmp-0.5.1.0 > 680K pretty-1.1.1.1 > 684K process-1.2.0.0 > 1.6M rts-1.0 > 13M template-haskell-2.9.0.0 > 1.4M terminfo-0.4.0.0 > 6.1M time-1.4.2 > 4.4M transformers-0.3.0.0 > 5.2M unix-2.7.0.1 > > 7.10: > > 83M Cabal_HWT8QvVfJLn2ubvobpycJY > 3.7M array_FaHmcBFfuRM8kmZLEY8D5S > 52M base_I5BErHzyOm07EBNpKBEeUv > 56M bin > 2.9M binar_EKE3c9Lmxb3DQpU0fPtru6 > 832K binpa_JNoexmBMuO8C771QaIy3YN > 5.7M bytes_6vj5EoliHgNHISHCVCb069 > 11M conta_47ajk3tbda43DFWyeF3oHQ > 432K deeps_FpR4obOZALU1lutWnrBldi > 912K direc_3TcTyYedch32o1zTH2MR00 > 796K filep_5HhyRonfEZoDO205Wm9E4h > 113M ghc_EMlWrQ42XY0BNVbSrKixqY > 2.9M ghcpr_8TmvWUcS1U1IKHT0levwg3 > 8.9M haske_IlDhIe25uAn0WJY379Nu1M > 3.4M hoopl_JxODiSRz1e84NbH6nnZuUk > 1.1M hpc_CmUUQl5bURfBueJrdYfNs3 > 1.3M integ_2aU3IZNMF9a7mQ0OzsZ0dS > 1.8M prett_7jIfj8VCGFf1WS0tIQ1XSZ > 764K proce_0hwN3CTKynhHQqQkChnSdH > 1.7M rts > 19M templ_BVMCZyLwIlfGfcqqzyUAI8 > 1.4M termi_7qZwBlx3clR8sTBilJl253 > 6.2M time_Hh2clZW6in4HpYHx5bLtb7 > 7.3M trans_ALYlebOVzVI4kxbFX5SGhm > 5.4M unix_G4Yo1pNtYrk8nCq1cx8P9d > > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768083.html > Sent from the Haskell - Glasgow-haskell-users mailing list archive at > Nabble.com. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Wed Apr 1 14:26:55 2015 From: voldermort at hotmail.com (Jeremy) Date: Wed, 1 Apr 2015 07:26:55 -0700 (MST) Subject: Binary bloat in 7.10 In-Reply-To: References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> Message-ID: <1427898415607-5768095.post@n5.nabble.com> Carter Schonwald wrote > How much of this might be attributable to longer linker symbol names? Ghc > 7.10 object code does have larger symbols! Is there a way to easily > tabulate that? That would explain why the hi files have also increased many-fold. Is there any way to avoid the larger symbols? -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768095.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From ezyang at mit.edu Wed Apr 1 15:12:11 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 01 Apr 2015 08:12:11 -0700 Subject: Binary bloat in 7.10 In-Reply-To: <1427898415607-5768095.post@n5.nabble.com> References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> Message-ID: <1427900698-sup-5266@sabre> Yes, this does seem like a potential culprit, although we did do some measurements and I didn't think it was too bad. Maybe we were wrong! Edward Excerpts from Jeremy's message of 2015-04-01 07:26:55 -0700: > Carter Schonwald wrote > > How much of this might be attributable to longer linker symbol names? Ghc > > 7.10 object code does have larger symbols! Is there a way to easily > > tabulate that? > > That would explain why the hi files have also increased many-fold. Is there > any way to avoid the larger symbols? > From daniel.trstenjak at gmail.com Wed Apr 1 15:13:13 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Wed, 1 Apr 2015 17:13:13 +0200 Subject: Binary bloat in 7.10 In-Reply-To: <1427880649570-5768067.post@n5.nabble.com> References: <1427880649570-5768067.post@n5.nabble.com> Message-ID: <20150401151313.GA27519@machine> On Wed, Apr 01, 2015 at 02:30:49AM -0700, Jeremy wrote: > Why do the 7.10 libraries take up so much more space than 7.8? For example, > using the same build options and strip --strip-unneeded, 7.8 leaves me with That would be some kind of harsh april 1st joke, if everything compiled at that day gets a bloated data section by putting lots "april" strings into it. ;) Greetings, Daniel From carter.schonwald at gmail.com Wed Apr 1 17:53:08 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 1 Apr 2015 13:53:08 -0400 Subject: Binary bloat in 7.10 In-Reply-To: <1427900698-sup-5266@sabre> References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> Message-ID: Mind you I'm just trying to come up with theories we can test, I'm not assigning blame. :) I'm not sure how to do the apples to apples comparison, but it sounds like some sleuthing Is In order. I dont have a 7.10 setup yet, but if someone can put a tarballed dist build folder for a 7.10 and the same for 7.8 for some lib that blows up,I'm happy to try to dig i n. Or I'll get things setup later this week to do the full comparison locally. On Apr 1, 2015 11:12 AM, "Edward Z. Yang" wrote: > Yes, this does seem like a potential culprit, although > we did do some measurements and I didn't think it was too bad. > Maybe we were wrong! > > Edward > > Excerpts from Jeremy's message of 2015-04-01 07:26:55 -0700: > > Carter Schonwald wrote > > > How much of this might be attributable to longer linker symbol names? > Ghc > > > 7.10 object code does have larger symbols! Is there a way to easily > > > tabulate that? > > > > That would explain why the hi files have also increased many-fold. Is > there > > any way to avoid the larger symbols? > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Thu Apr 2 06:35:01 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Thu, 2 Apr 2015 07:35:01 +0100 Subject: [Haskell-cafe] Parallel Profiling In-Reply-To: References: <0CD0B231-DF22-4D83-8334-E44540D1993E@steinitz.org> Message-ID: <32889012-65E8-4AA1-BD96-1A9F3AC9FB53@steinitz.org> Hi Amos, Thanks very much - I am taking a look. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com On 30 Mar 2015, at 22:05, Amos Robinson wrote: > Hi Dominic, > > A few years ago we wrote a program for analysing DPH runs, dph-event-seer. It provides a few general analyses like percent of time with N threads running, time between wake-ups etc. You might find it interesting, but I haven't actually looked at ghc-events-analyse, so I don't know what it provides. > > I'm sorry, but to compile it without DPH you'd have to modify it to remove DphOps*. > > https://github.com/ghc/packages-dph/blob/master/dph-event-seer/src/Main.hs > > Amos > > On Tue, 31 Mar 2015 at 04:38 Dominic Steinitz wrote: > Does anyone know of any tools for analysing parallel program performance? > > I am trying to use threadscope but it keeps crashing with my 100M log file and ghc-events-analyze is not going to help as I have many hundreds of threads all carrying out the same computation. I think I?d like a library that would allow me to construct my own analyses rather than display them via GTK. There is ghc-events but that seems to be just for parsing the logs and I couldn?t find anything that used it in the way I would like to (apart from threadscope and ghc-events-analyze of course). > > Thanks > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Thu Apr 2 09:19:14 2015 From: voldermort at hotmail.com (Jeremy) Date: Thu, 2 Apr 2015 02:19:14 -0700 (MST) Subject: Binary bloat in 7.10 In-Reply-To: References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> Message-ID: <1427966354366-5768133.post@n5.nabble.com> Very strange. If I download Cabal from hackage and build it with 'cabal build' the bloat disappears. cabal build: 18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 21M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a /usr/local/lib/ghc-7.10.1: 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a This is my build.mk: SRC_HC_OPTS = -O -H64m GhcRTSWays = thr HADDOCK_DOCS = NO GhcHcOpts = GhcLibWays = v DYNAMIC_GHC_PROGRAMS = NO This is the same as I used for 7.8 without issue, except the addition of GhcHcOpts (because 7.8 ignored the default). -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768133.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From carter.schonwald at gmail.com Thu Apr 2 11:53:32 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 2 Apr 2015 07:53:32 -0400 Subject: Binary bloat in 7.10 In-Reply-To: <1427966354366-5768133.post@n5.nabble.com> References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> Message-ID: Do you have profiling enabled locally? On Apr 2, 2015 5:19 AM, "Jeremy" wrote: > Very strange. If I download Cabal from hackage and build it with 'cabal > build' the bloat disappears. > > cabal build: > > 18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o > 21M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a > > /usr/local/lib/ghc-7.10.1: > > 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o > 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a > > This is my build.mk: > > SRC_HC_OPTS = -O -H64m > GhcRTSWays = thr > HADDOCK_DOCS = NO > GhcHcOpts = > GhcLibWays = v > DYNAMIC_GHC_PROGRAMS = NO > > This is the same as I used for 7.8 without issue, except the addition of > GhcHcOpts (because 7.8 ignored the default). > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768133.html > Sent from the Haskell - Glasgow-haskell-users mailing list archive at > Nabble.com. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Apr 2 11:53:56 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 2 Apr 2015 07:53:56 -0400 Subject: Binary bloat in 7.10 In-Reply-To: References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> Message-ID: Woops, never mind. On Apr 2, 2015 7:53 AM, "Carter Schonwald" wrote: > Do you have profiling enabled locally? > On Apr 2, 2015 5:19 AM, "Jeremy" wrote: > >> Very strange. If I download Cabal from hackage and build it with 'cabal >> build' the bloat disappears. >> >> cabal build: >> >> 18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o >> 21M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a >> >> /usr/local/lib/ghc-7.10.1: >> >> 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o >> 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a >> >> This is my build.mk: >> >> SRC_HC_OPTS = -O -H64m >> GhcRTSWays = thr >> HADDOCK_DOCS = NO >> GhcHcOpts = >> GhcLibWays = v >> DYNAMIC_GHC_PROGRAMS = NO >> >> This is the same as I used for 7.8 without issue, except the addition of >> GhcHcOpts (because 7.8 ignored the default). >> >> >> >> -- >> View this message in context: >> http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768133.html >> Sent from the Haskell - Glasgow-haskell-users mailing list archive at >> Nabble.com. >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Thu Apr 2 12:12:39 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Thu, 2 Apr 2015 14:12:39 +0200 Subject: Binary bloat in 7.10 In-Reply-To: <1427966354366-5768133.post@n5.nabble.com> References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> Message-ID: Maybe `split-objs` is not applied? * Stray `SplitObjs = NO` in your build.mk? * You're on an old OS X with XCode < 3.2? * Build system bug? On Thu, Apr 2, 2015 at 11:19 AM, Jeremy wrote: > Very strange. If I download Cabal from hackage and build it with 'cabal > build' the bloat disappears. > > cabal build: > > 18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o > 21M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a > > /usr/local/lib/ghc-7.10.1: > > 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o > 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a > > This is my build.mk: > > SRC_HC_OPTS = -O -H64m > GhcRTSWays = thr > HADDOCK_DOCS = NO > GhcHcOpts = > GhcLibWays = v > DYNAMIC_GHC_PROGRAMS = NO > > This is the same as I used for 7.8 without issue, except the addition of > GhcHcOpts (because 7.8 ignored the default). > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768133.html > Sent from the Haskell - Glasgow-haskell-users mailing list archive at > Nabble.com. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Thu Apr 2 12:19:20 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 2 Apr 2015 13:19:20 +0100 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <201504011426.06628.jan.stolarek@p.lodz.pl> References: <201504011426.06628.jan.stolarek@p.lodz.pl> Message-ID: <201504021419.21520.jan.stolarek@p.lodz.pl> 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 at 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. From eir at cis.upenn.edu Thu Apr 2 12:29:55 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 2 Apr 2015 08:29:55 -0400 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <201504021419.21520.jan.stolarek@p.lodz.pl> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> Message-ID: <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> 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 at 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From jan.stolarek at p.lodz.pl Thu Apr 2 12:47:25 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 2 Apr 2015 13:47:25 +0100 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> Message-ID: <201504021447.25480.jan.stolarek@p.lodz.pl> 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 at 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 at 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. From voldermort at hotmail.com Thu Apr 2 13:17:13 2015 From: voldermort at hotmail.com (Jeremy) Date: Thu, 2 Apr 2015 06:17:13 -0700 (MST) Subject: Binary bloat in 7.10 In-Reply-To: References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> Message-ID: <1427980633113-5768155.post@n5.nabble.com> Thomas Miedema wrote: >Maybe `split-objs` is not applied? > >* Stray `SplitObjs = NO` in your build.mk? Tried adding SplitObjs = YES, didn't help > * You're on an old OS X with XCode < 3.2? Debian Jessie -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768155.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From voldermort at hotmail.com Thu Apr 2 13:29:32 2015 From: voldermort at hotmail.com (Jeremy) Date: Thu, 2 Apr 2015 06:29:32 -0700 (MST) Subject: Binary bloat in 7.10 In-Reply-To: <1427980633113-5768155.post@n5.nabble.com> References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> <1427980633113-5768155.post@n5.nabble.com> Message-ID: <1427981372267-5768156.post@n5.nabble.com> Building with https://downloads.haskell.org/~ghc/7.10.1/ghc-7.10.1-src.tar.xz -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768156.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From dan.doel at gmail.com Thu Apr 2 14:00:08 2015 From: dan.doel at gmail.com (Dan Doel) Date: Thu, 2 Apr 2015 10:00:08 -0400 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <201504021447.25480.jan.stolarek@p.lodz.pl> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> Message-ID: 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 at 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 at 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Thu Apr 2 15:08:43 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Thu, 2 Apr 2015 12:08:43 -0300 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <201504021447.25480.jan.stolarek@p.lodz.pl> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> Message-ID: 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 at 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 at 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Thu Apr 2 15:21:34 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 2 Apr 2015 16:21:34 +0100 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021447.25480.jan.stolarek@p.lodz.pl> Message-ID: <201504021721.35386.jan.stolarek@p.lodz.pl> > 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. From mike at proclivis.com Thu Apr 2 15:23:35 2015 From: mike at proclivis.com (Michael Jones) Date: Thu, 2 Apr 2015 09:23:35 -0600 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> Message-ID: 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 at 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 at 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From asr at eafit.edu.co Thu Apr 2 15:37:29 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Thu, 2 Apr 2015 10:37:29 -0500 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <201504021419.21520.jan.stolarek@p.lodz.pl> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> Message-ID: 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 at 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -- Andr?s From thomasmiedema at gmail.com Fri Apr 3 00:48:03 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 3 Apr 2015 02:48:03 +0200 Subject: Binary bloat in 7.10 In-Reply-To: References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> Message-ID: Jeremy, On Thu, Apr 2, 2015 at 2:12 PM, Thomas Miedema wrote: > Maybe `split-objs` is not applied? > That suggestion was completely misguided. Compiling with `-split-objs` makes a library _grow_ in size, but makes executables that link against it _smaller_. Size of `libHSCabal-1.22.2.0` obtained by running `cabal install Cabal==1.22.2.0 --with-ghc=ghc-x.x.x (--enable-split-objs)`, on 64bit Ubuntu: default --enable-split-objs 7.8.4: 19Mb 46Mb 7.10.1: 21Mb 52Mb So the 7.10 versions are indeed somewhat larger, but I wouldn't call it ballooned or bloated. Note that a ghc build compiles the libraries with -O2 , which increases the binary size another 5% or so. All these numbers are not far off from the ones you were getting. I think you have been comparing a 7.8.4 build of Cabal without split objects, with a 7.10.1 build of Cabal with split objects. I don't think there is a bug here. -Thomas P.S. To show that binary sizes not only grow with new ghc releases, here is the same experiment with random: `cabal install random==1.0.1.1 --with-ghc=ghc-x.x.x (--enable-split-objs)` default --enable-split-objs 7.0.4: 0.94M 1.9M 7.2.2: 1.1M 2.1M 7.4.2: 0.86M 1.8M 7.6.3: 0.85M 1.8M 7.8.4: 0.76M 1.7M 7.10.1: 0.69M 1.6M -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Apr 3 01:26:10 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 2 Apr 2015 21:26:10 -0400 Subject: Binary bloat in 7.10 In-Reply-To: References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> Message-ID: Great sleuthing!! Thanks for pinning down whats going on! On Apr 2, 2015 8:48 PM, "Thomas Miedema" wrote: > Jeremy, > > On Thu, Apr 2, 2015 at 2:12 PM, Thomas Miedema > wrote: > >> Maybe `split-objs` is not applied? >> > > That suggestion was completely misguided. Compiling with `-split-objs` > makes a library _grow_ in size, but makes executables that link against it > _smaller_. > > Size of `libHSCabal-1.22.2.0` obtained by running `cabal install > Cabal==1.22.2.0 --with-ghc=ghc-x.x.x (--enable-split-objs)`, on 64bit > Ubuntu: > > default --enable-split-objs > 7.8.4: 19Mb 46Mb > 7.10.1: 21Mb 52Mb > > So the 7.10 versions are indeed somewhat larger, but I wouldn't call it > ballooned or bloated. Note that a ghc build compiles the libraries with > -O2 , which increases the binary size another 5% or so. > > All these numbers are not far off from the ones you were getting. I think > you have been comparing a 7.8.4 build of Cabal without split objects, with > a 7.10.1 build of Cabal with split objects. > > I don't think there is a bug here. > > -Thomas > > > P.S. To show that binary sizes not only grow with new ghc releases, here > is the same experiment with random: > > `cabal install random==1.0.1.1 --with-ghc=ghc-x.x.x (--enable-split-objs)` > > default --enable-split-objs > 7.0.4: 0.94M 1.9M > 7.2.2: 1.1M 2.1M > 7.4.2: 0.86M 1.8M > 7.6.3: 0.85M 1.8M > 7.8.4: 0.76M 1.7M > 7.10.1: 0.69M 1.6M > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwotton at gmail.com Fri Apr 3 05:05:13 2015 From: mwotton at gmail.com (Mark Wotton) Date: Fri, 03 Apr 2015 05:05:13 +0000 Subject: immortal profiling Message-ID: https://ghc.haskell.org/trac/ghc/ticket/10235#ticket Would be really useful to be able to profile code without dying, especially in the context of a long-lived server. Am I missing something that would allow me to do this? cheers mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From davean at xkcd.com Fri Apr 3 05:13:55 2015 From: davean at xkcd.com (davean) Date: Fri, 3 Apr 2015 01:13:55 -0400 Subject: immortal profiling In-Reply-To: References: Message-ID: I'd rather like that too. Also to be able to reset it. On Fri, Apr 3, 2015 at 1:05 AM, Mark Wotton wrote: > https://ghc.haskell.org/trac/ghc/ticket/10235#ticket > > Would be really useful to be able to profile code without dying, > especially in the context of a long-lived server. Am I missing something > that would allow me to do this? > > cheers > mark > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Fri Apr 3 11:36:43 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 3 Apr 2015 06:36:43 -0500 Subject: Help wanted: working on the GHC webpage Message-ID: Hello *, For a while now, I've been wanting to do a facelift on the GHC homepage, but among many other things it's been a low priority. I'd like for people to help, so I've tried to get the ball rolling. The webpages existed in a Darcs repository previously (which wasn't available online), but earlier today I converted them to a git repository which you can find here: https://github.com/haskell-infra/ghc-homepage The site is currently composed of a set of "server side include" files that have a crude form of HTML templating. So it's mostly just pretty verbose to add or refactor anything, and the sites templating and styling is quite old (it dates back at least 10 years!) So, I'm making an official call for some help. At the very least, I'd like to at least end up converting the site to something like Hakyll which is doable without me causing a lot of damage to the stylesheets, but for the actual page itself I'd really appreciate it if anyone could help out! Please send pull requests or file issues, it's much appreciated. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From bertram.felgenhauer at googlemail.com Fri Apr 3 14:14:23 2015 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Fri, 3 Apr 2015 16:14:23 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> Message-ID: <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> 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 From david.feuer at gmail.com Fri Apr 3 14:49:12 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 3 Apr 2015 10:49:12 -0400 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: 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 at 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Sun Apr 5 12:19:13 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Sun, 5 Apr 2015 14:19:13 +0200 Subject: Functional dependencies conflict Message-ID: <20150405121913.GA4309@machine> Hi, I'm getting the compile error: Gamgine/Image/PNG/Internal/Parser.hs:14:10: Functional dependencies conflict between instance declarations: instance Monad m => Stream LB.ByteString m Word8 -- Defined at Gamgine/Image/PNG/Internal/Parser.hs:14:10 instance Monad m => Stream LB.ByteString m Char -- Defined in ?Text.Parsec.Prim? The relevant stuff from the parsec 3.1.9 code[1] is: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleContexts, UndecidableInstances #-} ... import qualified Data.ByteString.Lazy.Char8 as CL import qualified Data.ByteString.Char8 as C ... class (Monad m) => Stream s m t | s -> t where uncons :: s -> m (Maybe (t,s)) instance (Monad m) => Stream CL.ByteString m Char where uncons = return . CL.uncons instance (Monad m) => Stream C.ByteString m Char where uncons = return . C.uncons And from my code[2] is: {-# LANGUAGE BangPatterns, FlexibleInstances, MultiParamTypeClasses, FlexibleContexts #-} ... import qualified Data.ByteString.Lazy as LB ... instance (Monad m) => Stream LB.ByteString m Word8 where uncons = return . LB.uncons As you can see, the instances are for different ByteString types, therefore I don't quite get where GHC sees here any conflicts. Greetings, Daniel [1] https://github.com/aslatter/parsec/blob/master/Text/Parsec/Prim.hs [2] https://github.com/dan-t/Gamgine/blob/master/Gamgine/Image/PNG/Internal/Parser.hs From roma at ro-che.info Sun Apr 5 12:25:01 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 05 Apr 2015 15:25:01 +0300 Subject: [Haskell-cafe] Functional dependencies conflict In-Reply-To: <20150405121913.GA4309@machine> References: <20150405121913.GA4309@machine> Message-ID: <5521299D.3020007@ro-che.info> Data.ByteString.Lazy.Char8 exports the same lazy bytestring type as Data.ByteString.Lazy. Only functions and instances differ. On 05/04/15 15:19, Daniel Trstenjak wrote: > > Hi, > > I'm getting the compile error: > > Gamgine/Image/PNG/Internal/Parser.hs:14:10: > Functional dependencies conflict between instance declarations: > instance Monad m => Stream LB.ByteString m Word8 > -- Defined at Gamgine/Image/PNG/Internal/Parser.hs:14:10 > instance Monad m => Stream LB.ByteString m Char > -- Defined in ?Text.Parsec.Prim? > > > > The relevant stuff from the parsec 3.1.9 code[1] is: > > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleContexts, UndecidableInstances #-} > > ... > > import qualified Data.ByteString.Lazy.Char8 as CL > import qualified Data.ByteString.Char8 as C > > ... > > class (Monad m) => Stream s m t | s -> t where > uncons :: s -> m (Maybe (t,s)) > > instance (Monad m) => Stream CL.ByteString m Char where > uncons = return . CL.uncons > > instance (Monad m) => Stream C.ByteString m Char where > uncons = return . C.uncons > > > > And from my code[2] is: > > {-# LANGUAGE BangPatterns, FlexibleInstances, MultiParamTypeClasses, FlexibleContexts #-} > > ... > > import qualified Data.ByteString.Lazy as LB > > ... > > instance (Monad m) => Stream LB.ByteString m Word8 where > uncons = return . LB.uncons > > > > As you can see, the instances are for different ByteString types, > therefore I don't quite get where GHC sees here any conflicts. > > > Greetings, > Daniel > > > [1] https://github.com/aslatter/parsec/blob/master/Text/Parsec/Prim.hs > [2] https://github.com/dan-t/Gamgine/blob/master/Gamgine/Image/PNG/Internal/Parser.hs > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From roma at ro-che.info Sun Apr 5 12:30:52 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 05 Apr 2015 15:30:52 +0300 Subject: [Haskell-cafe] Functional dependencies conflict In-Reply-To: References: <20150405121913.GA4309@machine> <5521299D.3020007@ro-che.info> Message-ID: <55212AFC.6010002@ro-che.info> To be precise, the sets of instances differ. Eg. the Char8 module exports the IsString instance, which normal Data.ByteString.Lazy doesn't. On 05/04/15 15:25, Ivan Lazar Miljenovic wrote: > On 5 April 2015 at 22:25, Roman Cheplyaka wrote: >> Data.ByteString.Lazy.Char8 exports the same lazy bytestring type as >> Data.ByteString.Lazy. Only functions and instances differ. > > Well, *instances* can't differ... > >> >> On 05/04/15 15:19, Daniel Trstenjak wrote: >>> >>> Hi, >>> >>> I'm getting the compile error: >>> >>> Gamgine/Image/PNG/Internal/Parser.hs:14:10: >>> Functional dependencies conflict between instance declarations: >>> instance Monad m => Stream LB.ByteString m Word8 >>> -- Defined at Gamgine/Image/PNG/Internal/Parser.hs:14:10 >>> instance Monad m => Stream LB.ByteString m Char >>> -- Defined in ?Text.Parsec.Prim? >>> >>> >>> >>> The relevant stuff from the parsec 3.1.9 code[1] is: >>> >>> {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleContexts, UndecidableInstances #-} >>> >>> ... >>> >>> import qualified Data.ByteString.Lazy.Char8 as CL >>> import qualified Data.ByteString.Char8 as C >>> >>> ... >>> >>> class (Monad m) => Stream s m t | s -> t where >>> uncons :: s -> m (Maybe (t,s)) >>> >>> instance (Monad m) => Stream CL.ByteString m Char where >>> uncons = return . CL.uncons >>> >>> instance (Monad m) => Stream C.ByteString m Char where >>> uncons = return . C.uncons >>> >>> >>> >>> And from my code[2] is: >>> >>> {-# LANGUAGE BangPatterns, FlexibleInstances, MultiParamTypeClasses, FlexibleContexts #-} >>> >>> ... >>> >>> import qualified Data.ByteString.Lazy as LB >>> >>> ... >>> >>> instance (Monad m) => Stream LB.ByteString m Word8 where >>> uncons = return . LB.uncons >>> >>> >>> >>> As you can see, the instances are for different ByteString types, >>> therefore I don't quite get where GHC sees here any conflicts. >>> >>> >>> Greetings, >>> Daniel >>> >>> >>> [1] https://github.com/aslatter/parsec/blob/master/Text/Parsec/Prim.hs >>> [2] https://github.com/dan-t/Gamgine/blob/master/Gamgine/Image/PNG/Internal/Parser.hs >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > From daniel.trstenjak at gmail.com Sun Apr 5 12:54:36 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Sun, 5 Apr 2015 14:54:36 +0200 Subject: [Haskell-cafe] Functional dependencies conflict In-Reply-To: <5521299D.3020007@ro-che.info> References: <20150405121913.GA4309@machine> <5521299D.3020007@ro-che.info> Message-ID: <20150405125436.GA15148@machine> On Sun, Apr 05, 2015 at 03:25:01PM +0300, Roman Cheplyaka wrote: > Data.ByteString.Lazy.Char8 exports the same lazy bytestring type as > Data.ByteString.Lazy. Only functions and instances differ. So my only option in this case is to define a newtype wrapper for Data.ByteString.Lazy and then define a Stream instance on this one? Greetings, Daniel From roma at ro-che.info Sun Apr 5 13:04:43 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 05 Apr 2015 16:04:43 +0300 Subject: [Haskell-cafe] Functional dependencies conflict In-Reply-To: <20150405125436.GA15148@machine> References: <20150405121913.GA4309@machine> <5521299D.3020007@ro-che.info> <20150405125436.GA15148@machine> Message-ID: <552132EB.6020101@ro-che.info> On 05/04/15 15:54, Daniel Trstenjak wrote: > > On Sun, Apr 05, 2015 at 03:25:01PM +0300, Roman Cheplyaka wrote: >> Data.ByteString.Lazy.Char8 exports the same lazy bytestring type as >> Data.ByteString.Lazy. Only functions and instances differ. > > So my only option in this case is to define a newtype wrapper > for Data.ByteString.Lazy and then define a Stream instance on this one? You might do that. But if I were you, I'd use attoparsec or even binary/cereal to parse PNG. They are better suited for parsing binary data. Roman From voldermort at hotmail.com Sun Apr 5 19:29:56 2015 From: voldermort at hotmail.com (Jeremy) Date: Sun, 5 Apr 2015 12:29:56 -0700 (MST) Subject: Binary bloat in 7.10 In-Reply-To: References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> Message-ID: <1428262196709-5768274.post@n5.nabble.com> Thomas Miedema wrote > That suggestion was completely misguided. Compiling with `-split-objs` > makes a library _grow_ in size, but makes executables that link against it > _smaller_. > > All these numbers are not far off from the ones you were getting. I think > you have been comparing a 7.8.4 build of Cabal without split objects, with > a 7.10.1 build of Cabal with split objects. > > I don't think there is a bug here. My GHC build is now back to the 7.8-era size. Thank you! I was wondering why programs compiled with my GHC 7.8 build were bigger than if I used an official build. Perhaps a bug in the 7.8 build system had turned off SplitObjs. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768274.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From simonpj at microsoft.com Mon Apr 6 09:49:20 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 6 Apr 2015 09:49:20 +0000 Subject: Binary bloat in 7.10 In-Reply-To: <1428262196709-5768274.post@n5.nabble.com> References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> <1428262196709-5768274.post@n5.nabble.com> Message-ID: <1c3c3a23c4bd4e6d98935e2cb34449b7@DB4PR30MB030.064d.mgd.msft.net> Just to check, can someone summarise the conclusion of this thread? Was it all due to -fsplit-objs? If so, should we add some notes to the user manual to explain what may happen if you use -fsplit-objs? What was the business about Cabal? Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Jeremy | Sent: 05 April 2015 20:30 | To: glasgow-haskell-users at haskell.org | Subject: Re: Binary bloat in 7.10 | | Thomas Miedema wrote | > That suggestion was completely misguided. Compiling with `-split-objs` | > makes a library _grow_ in size, but makes executables that link | > against it _smaller_. | > | > All these numbers are not far off from the ones you were getting. I | > think you have been comparing a 7.8.4 build of Cabal without split | > objects, with a 7.10.1 build of Cabal with split objects. | > | > I don't think there is a bug here. | | My GHC build is now back to the 7.8-era size. Thank you! | | I was wondering why programs compiled with my GHC 7.8 build were bigger | than if I used an official build. Perhaps a bug in the 7.8 build system | had turned off SplitObjs. | | | | -- | View this message in context: | http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10- | tp5768067p5768274.html | Sent from the Haskell - Glasgow-haskell-users mailing list archive at | Nabble.com. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From thomasmiedema at gmail.com Mon Apr 6 10:04:56 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 6 Apr 2015 12:04:56 +0200 Subject: Binary bloat in 7.10 In-Reply-To: <1c3c3a23c4bd4e6d98935e2cb34449b7@DB4PR30MB030.064d.mgd.msft.net> References: <1427880649570-5768067.post@n5.nabble.com> <551BE350.3080405@ro-che.info> <1427895616257-5768083.post@n5.nabble.com> <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> <1428262196709-5768274.post@n5.nabble.com> <1c3c3a23c4bd4e6d98935e2cb34449b7@DB4PR30MB030.064d.mgd.msft.net> Message-ID: It was all due to a missing -split-objs in Jeremy's 7.8 build. I updated the user's guide. The section on -split-objs now reads, with the part that is new in italic: -split-objs Tell the linker to split the single object file that would normally be generated into multiple object files, one per top-level Haskell function or type in the module. This only makes sense for libraries, where it means that executables linked against the library are smaller as they only link against the object files that they need. However, assembling all the sections separately is expensive, so this is slower than compiling normally. *Additionally, the size of the library itself **(the .a file) can be a factor of 2 to 2.5 **larger. *We use this feature for building GHC's libraries. On Mon, Apr 6, 2015 at 11:49 AM, Simon Peyton Jones wrote: > Just to check, can someone summarise the conclusion of this thread? Was > it all due to -fsplit-objs? If so, should we add some notes to the user > manual to explain what may happen if you use -fsplit-objs? What was the > business about Cabal? > > Simon > > | -----Original Message----- > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- > | bounces at haskell.org] On Behalf Of Jeremy > | Sent: 05 April 2015 20:30 > | To: glasgow-haskell-users at haskell.org > | Subject: Re: Binary bloat in 7.10 > | > | Thomas Miedema wrote > | > That suggestion was completely misguided. Compiling with `-split-objs` > | > makes a library _grow_ in size, but makes executables that link > | > against it _smaller_. > | > > | > All these numbers are not far off from the ones you were getting. I > | > think you have been comparing a 7.8.4 build of Cabal without split > | > objects, with a 7.10.1 build of Cabal with split objects. > | > > | > I don't think there is a bug here. > | > | My GHC build is now back to the 7.8-era size. Thank you! > | > | I was wondering why programs compiled with my GHC 7.8 build were bigger > | than if I used an official build. Perhaps a bug in the 7.8 build system > | had turned off SplitObjs. > | > | > | > | -- > | View this message in context: > | http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10- > | tp5768067p5768274.html > | Sent from the Haskell - Glasgow-haskell-users mailing list archive at > | Nabble.com. > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Mon Apr 6 14:34:34 2015 From: voldermort at hotmail.com (Jeremy) Date: Mon, 6 Apr 2015 07:34:34 -0700 (MST) Subject: runghc and GhcWithInterpreter Message-ID: <1428330874009-5768326.post@n5.nabble.com> I've built GHC with GhcWithInterpreter = NO. runghc is built and installed, but errors out with "not built for interactive use". Is runghc supposed to work with such a build? If not, why is it built at all? -- View this message in context: http://haskell.1045720.n5.nabble.com/runghc-and-GhcWithInterpreter-tp5768326.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From voldermort at hotmail.com Mon Apr 6 14:35:44 2015 From: voldermort at hotmail.com (Jeremy) Date: Mon, 6 Apr 2015 07:35:44 -0700 (MST) Subject: skip hpc during build Message-ID: <1428330944573-5768327.post@n5.nabble.com> I'm deleting hpc after building ghc for a vm to save space. Is there an easy way to skip building it in the first place? -- View this message in context: http://haskell.1045720.n5.nabble.com/skip-hpc-during-build-tp5768327.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From ezyang at mit.edu Mon Apr 6 17:17:24 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 06 Apr 2015 10:17:24 -0700 Subject: runghc and GhcWithInterpreter In-Reply-To: <1428330874009-5768326.post@n5.nabble.com> References: <1428330874009-5768326.post@n5.nabble.com> Message-ID: <1428340546-sup-6799@sabre> No, it's not supposed to work, since runghc interprets GHC code. runghc itself is just a little shell script which calls GHC proper with the -f flag, so I suppose the build system was just not set up to not create this link in that case. Edward Excerpts from Jeremy's message of 2015-04-06 07:34:34 -0700: > I've built GHC with GhcWithInterpreter = NO. runghc is built and installed, > but errors out with "not built for interactive use". > > Is runghc supposed to work with such a build? If not, why is it built at > all? > From voldermort at hotmail.com Mon Apr 6 17:46:10 2015 From: voldermort at hotmail.com (Jeremy) Date: Mon, 6 Apr 2015 10:46:10 -0700 (MST) Subject: runghc and GhcWithInterpreter In-Reply-To: <1428340546-sup-6799@sabre> References: <1428330874009-5768326.post@n5.nabble.com> <1428340546-sup-6799@sabre> Message-ID: <1428342370550-5768346.post@n5.nabble.com> Edward Z. Yang wrote > runghc itself is just a little shell script which calls GHC proper > with the -f flag, so I suppose the build system was just not set > up to not create this link in that case. I have a binary called runghc under /usr/local/lib/ghc-7.10.1/bin in addition to the shell script under /usr/local/bin that references it. -- View this message in context: http://haskell.1045720.n5.nabble.com/runghc-and-GhcWithInterpreter-tp5768326p5768346.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From voldermort at hotmail.com Tue Apr 7 07:51:26 2015 From: voldermort at hotmail.com (Jeremy) Date: Tue, 7 Apr 2015 00:51:26 -0700 (MST) Subject: Binary bloat in 7.10 In-Reply-To: References: <1427898415607-5768095.post@n5.nabble.com> <1427900698-sup-5266@sabre> <1427966354366-5768133.post@n5.nabble.com> <1428262196709-5768274.post@n5.nabble.com> <1c3c3a23c4bd4e6d98935e2cb34449b7@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1428393086100-5768377.post@n5.nabble.com> Thomas Miedema wrote > It was all due to a missing -split-objs in Jeremy's 7.8 build. For the record, this appears to have been a bug in the 7.8 build system, as SplitObjs is supposed to be on by default. I only noticed when building 7.10, where the default was correct, and didn't understand why the GHC libraries has ballooned. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768377.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From rwbarton at gmail.com Tue Apr 7 20:16:50 2015 From: rwbarton at gmail.com (Reid Barton) Date: Tue, 7 Apr 2015 16:16:50 -0400 Subject: runghc and GhcWithInterpreter In-Reply-To: <1428342370550-5768346.post@n5.nabble.com> References: <1428330874009-5768326.post@n5.nabble.com> <1428340546-sup-6799@sabre> <1428342370550-5768346.post@n5.nabble.com> Message-ID: On Mon, Apr 6, 2015 at 1:46 PM, Jeremy wrote: > Edward Z. Yang wrote > > runghc itself is just a little shell script which calls GHC proper > > with the -f flag, so I suppose the build system was just not set > > up to not create this link in that case. > > I have a binary called runghc under /usr/local/lib/ghc-7.10.1/bin in > addition to the shell script under /usr/local/bin that references it. > Yes, runghc is actually a small Haskell program that shells out to ghc -e. I filed an issue: https://ghc.haskell.org/trac/ghc/ticket/10261 Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Apr 8 22:34:14 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 8 Apr 2015 22:34:14 +0000 Subject: Typed splices and type checking In-Reply-To: References: Message-ID: Good question! See https://ghc.haskell.org/trac/ghc/ticket/10271. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of J. Garrett Morris | Sent: 27 March 2015 14:30 | To: GHC users | Subject: Typed splices and type checking | | Hello, | | I've run into another misunderstanding with Template Haskell and typed | splices. For example, I was hoping to use typed splices to generate | earlier errors from Printf. Here's the world's least handy printf: | | > class Printf t | > where printf :: String -> Q (TExp String) -> Q (TExp t) | > | > instance Printf String | > where printf s t | '%' `notElem` s = [|| $$t ++ s ||] | > | otherwise = fail ("Unexpected format %" | > ++ [c]) | > where (_, _:c:_) = break ('%' ==) s | > | > instance Printf t => Printf (Char -> t) | > where printf s t | > | c /= 'c' = fail ("Unexpected format %" ++ [c] ++ | > " for character") | > | otherwise = [|| \c -> $$(printf s'' | > [|| $$t ++ s' ++ [c] ||]) | > ||] | > where (s', '%':c:s'') = break ('%' ==) s | | Now, consider these two definitions: | | > f :: Char -> String | > f = $$(printf "foo %c" [||""||]) | | > h :: Char -> String | > h y = $$(printf "foo %c" [||""||]) y | | I would have expected these to be equivalent, from a type checking | perspective. However, while the first types fine, the second generates | the error message: | | > Printing.hs:14:12: | > No instance for (Printf t0) arising from a use of `printf' | > The type variable `t0' is ambiguous | > Note: there are several potential instances: | > instance Printf t => Printf (Char -> t) | > -- Defined at Printf.hs:20:10 | > instance Printf String -- Defined at Printf.hs:9:10 | > In the expression: printf "foo %c" [|| "" ||] | > In the Template Haskell splice | > $$(printf "foo %c" [|| "" ||]) | > In the expression: $$(printf "foo %c" [|| "" ||]) | | Should I have anticipated this? Ought the interaction of typed splices | and eta-expansion be problematic? | | /g | | -- | The University of Edinburgh is a charitable body, registered in | Scotland, with registration number SC005336. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From acrisciu at gmail.com Thu Apr 9 10:51:50 2015 From: acrisciu at gmail.com (acrisciu at gmail.com) Date: Thu, 09 Apr 2015 05:51:50 -0500 Subject: acrisciu@gmail.com has indicated you're a friend. Accept? Message-ID: <0.0.289.9D0.1D072B25EF127A0.37E0@mail10.infoaxe.net> Hi, acrisciu at gmail.com wants to follow you. ****** Is acrisciu at gmail.com you friend? ****** If Yes please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=&email=glasgow-haskell-users at haskell.org&invitername=Adrian+Crisciu&inviterid=18099446&userid=0&token=0&emailmasterid=f539d292-09bf-444a-a7d9-afe59a2f2134&from=acrisciu at gmail.com&template=invite_reg_a&src=txt_yes If No please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=&email=glasgow-haskell-users at haskell.org&invitername=Adrian+Crisciu&inviterid=18099446&userid=0&token=0&emailmasterid=f539d292-09bf-444a-a7d9-afe59a2f2134&from=acrisciu at gmail.com&template=invite_reg_a&src=txt_no Follow the link below to remove yourself from all such emails http://invites.infoaxe.net/uns_inviter.jsp?email=glasgow-haskell-users at haskell.org&iid=f539d292-09bf-444a-a7d9-afe59a2f2134&from=acrisciu at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Sat Apr 11 16:44:38 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Sat, 11 Apr 2015 17:44:38 +0100 Subject: SIMD Message-ID: <326702F2-DD7F-4703-AF7B-2CA9D2E080B5@steinitz.org> What?s the story with this? I tried to follow the instructions here: https://ghc.haskell.org/trac/ghc/wiki/SIMD but I get > ~ $ git clone -b simd http://git.haskell.org/ghc.git > Cloning into 'ghc'... > fatal: Remote branch simd not found in upstream origin Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sat Apr 11 17:28:25 2015 From: david.feuer at gmail.com (David Feuer) Date: Sat, 11 Apr 2015 13:28:25 -0400 Subject: SIMD In-Reply-To: <326702F2-DD7F-4703-AF7B-2CA9D2E080B5@steinitz.org> References: <326702F2-DD7F-4703-AF7B-2CA9D2E080B5@steinitz.org> Message-ID: Last I heard, it was extremely experimental and somewhat broken. Carter was working on some of the worst problems, but he's been kind of busy. On Sat, Apr 11, 2015 at 12:44 PM, Dominic Steinitz wrote: > What?s the story with this? I tried to follow the instructions here: > https://ghc.haskell.org/trac/ghc/wiki/SIMD but I get > > ~ $ git clone -b simd http://git.haskell.org/ghc.git > Cloning into 'ghc'... > fatal: Remote branch simd not found in upstream origin > > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Apr 11 18:51:14 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 11 Apr 2015 14:51:14 -0400 Subject: SIMD In-Reply-To: References: <326702F2-DD7F-4703-AF7B-2CA9D2E080B5@steinitz.org> Message-ID: indeed, dont use it. the current design is only -fllvm, and the choice in api is exactly the wrong one for those who actually want to use SIMD correctly If you want to use Simd today, write C code and ffi call it! https://github.com/wellposed/vector-vectorized is an example effort I did nearly 2 years ago On Sat, Apr 11, 2015 at 1:28 PM, David Feuer wrote: > Last I heard, it was extremely experimental and somewhat broken. Carter > was working on some of the worst problems, but he's been kind of busy. > > On Sat, Apr 11, 2015 at 12:44 PM, Dominic Steinitz > wrote: > >> What?s the story with this? I tried to follow the instructions here: >> https://ghc.haskell.org/trac/ghc/wiki/SIMD but I get >> >> ~ $ git clone -b simd http://git.haskell.org/ghc.git >> Cloning into 'ghc'... >> fatal: Remote branch simd not found in upstream origin >> >> >> Dominic Steinitz >> dominic at steinitz.org >> http://idontgetoutmuch.wordpress.com >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Sun Apr 12 16:28:08 2015 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sun, 12 Apr 2015 16:28:08 +0000 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: 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 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.felgenhauer at 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 at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 13 06:54:31 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 13 Apr 2015 06:54:31 +0000 Subject: SIMD In-Reply-To: <326702F2-DD7F-4703-AF7B-2CA9D2E080B5@steinitz.org> References: <326702F2-DD7F-4703-AF7B-2CA9D2E080B5@steinitz.org> Message-ID: <299c59e6498048eda77377c55d862d3c@DB4PR30MB030.064d.mgd.msft.net> Geoff Mainland is the originator of the SIMD instruction set work. Let?s see what he says. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Dominic Steinitz Sent: 11 April 2015 17:45 To: GHC users Subject: SIMD What?s the story with this? I tried to follow the instructions here: https://ghc.haskell.org/trac/ghc/wiki/SIMD but I get ~ $ git clone -b simd http://git.haskell.org/ghc.git Cloning into 'ghc'... fatal: Remote branch simd not found in upstream origin Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From christiaan.baaij at gmail.com Mon Apr 13 10:20:09 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Mon, 13 Apr 2015 12:20:09 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> 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 > 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 > 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 > 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Mon Apr 13 13:05:25 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Mon, 13 Apr 2015 14:05:25 +0100 Subject: SIMD In-Reply-To: <552BB88E.1080705@cs.drexel.edu> References: <326702F2-DD7F-4703-AF7B-2CA9D2E080B5@steinitz.org> <299c59e6498048eda77377c55d862d3c@DB4PR30MB030.064d.mgd.msft.net> <552BB88E.1080705@cs.drexel.edu> Message-ID: <5BD48E89-355C-4F1F-8BBF-61B1015F5BD3@steinitz.org> Hi Geoff, Thanks for the update. I found this https://ghc.haskell.org/trac/ghc/blog/weekly20141020 > Geoff Mainland stepped up and fixed Data Parallel Haskell to work with a new version of vector and GHC. Austin had disabled DPH a few weeks prior due to its difficulty to upgrade, and divergent source trees. With 7.10, GHC will hopefully ship a more modern vector and dph to boot. From what you say this has been superseded? Also seems that this page https://ghc.haskell.org/trac/ghc/wiki/SIMD should be updated and if I knew what it should say I would volunteer to update it. A bit of background on why I am asking these questions: I am working on a Monte Carlo simulation and performance is a key issue. We are using parallelisation to good effect (after some interesting issues with thread affinity https://ghc.haskell.org/trac/ghc/ticket/10229 ) but I am trying to understand what other options might be available to speed things up. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com > On 13 Apr 2015, at 13:37, Geoffrey Mainland wrote: > > SIMD support was merged to HEAD before the 7.8 release, so any version > of GHC after 7.8 has SIMD support built-in. > > If you want a branch that compiles with DPH, I'm afraid you are out of > luck. DPH no longer builds at all, and I believe Austin actually deleted > the simd branch mentioned on the Wiki. > > Geoff > > On 04/13/2015 02:54 AM, Simon Peyton Jones wrote: >> >> Geoff Mainland is the originator of the SIMD instruction set work. >> Let?s see what he says. >> >> >> >> Simon >> >> >> >> *From:*Glasgow-haskell-users >> [mailto:glasgow-haskell-users-bounces at haskell.org] *On Behalf Of >> *Dominic Steinitz >> *Sent:* 11 April 2015 17:45 >> *To:* GHC users >> *Subject:* SIMD >> >> >> >> What?s the story with this? I tried to follow the instructions >> here: https://ghc.haskell.org/trac/ghc/wiki/SIMD but I get >> >> >> >> ~ $ git clone -b simd http://git.haskell.org/ghc.git >> > >> >> Cloning into 'ghc'... >> >> fatal: Remote branch simd not found in upstream origin >> >> >> >> Dominic Steinitz >> >> dominic at steinitz.org > >> >> http://idontgetoutmuch.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Mon Apr 13 19:09:02 2015 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Mon, 13 Apr 2015 21:09:02 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> Message-ID: 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 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 From christiaan.baaij at gmail.com Mon Apr 13 20:34:08 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Mon, 13 Apr 2015 22:34:08 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> Message-ID: 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Tue Apr 14 19:54:51 2015 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Tue, 14 Apr 2015 21:54:51 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> Message-ID: 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.1 4.5 OccAnal SimplCore 3.1 3.1 StgCmm HscMain 3.0 2.5 occAnalBind.assoc OccurAnal 3.0 3.1 RegAlloc AsmCodeGen 2.6 3.2 tc_rn_src_decls TcRnDriver 2.5 1.8 regLiveness AsmCodeGen 2.4 2.6 Simplify SimplCore 2.3 0.1 FloatOutwards SimplCore 2.3 1.8 sink CmmPipeline 2.2 2.0 genMachCode AsmCodeGen 1.5 1.3 NewStranal SimplCore 1.5 1.7 layoutStack CmmPipeline 1.3 1.3 NativeCodeGen CodeOutput 1.2 1.1 FloatInwards SimplCore 1.0 1.2 Digraph.scc Digraph 0.8 1.2 From austin at well-typed.com Tue Apr 14 19:58:04 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 14 Apr 2015 14:58:04 -0500 Subject: Help wanted: working on the GHC webpage In-Reply-To: <551E9EDA.40301@sigrlami.eu> References: <551E92A8.7020901@sigrlami.eu> <87y4m9conm.fsf@gmail.com> <551E9EDA.40301@sigrlami.eu> Message-ID: Hey Sergey, Sorry for the delay - thanks for all your changes! A few other people have stepped up. But we still need more help of course. :) I'm incorporating your changes into the main Git repository as we speak, and I greatly appreciate it! I'm also incorporating changes from others. Please watch the repo and let me know if you have questions! PS: As for Trac, I agree that at the minimum there should be some kind of syndication or something from the homepage to Trac... the Weekly News *is* user-focused, but the homepage has been severely lacking. I'd appreciate comments here - make an issue about it on the bug tracker! On Fri, Apr 3, 2015 at 9:08 AM, Sergey Bushnyak wrote: > >> Why would it be easier? What's difficult about publishing on >> https://ghc.haskell.org/trac/ghc/blog? > > I'm actually don't know how it's published on track. From my standpoint as > newcomer it's better to see what's happening from one place, with one > design, have some shared git repo where people contribute in markdown. >> >> Moreover, the GHC weekly news are intimately linked to Trac, as they >> reference Trac-tickets and Git commits, which Trac is able to annotate >> with meta-data (ticket-type, -status, and -title for Ticket references, >> as well as part of the Git commit msg for Git-commit refs). > > > Ok, it was just a suggestion. Maybe it's a bad idea, doesn't know about > annotation. > > Anyway, still can help on updating ghc home page. > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mail at joachim-breitner.de Tue Apr 14 20:09:23 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 14 Apr 2015 22:09:23 +0200 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> Message-ID: <1429042163.9101.5.camel@joachim-breitner.de> 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 at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From eir at cis.upenn.edu Tue Apr 14 23:40:01 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 15 Apr 2015 00:40:01 +0100 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <1429042163.9101.5.camel@joachim-breitner.de> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> Message-ID: <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> 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 at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From michal.terepeta at gmail.com Thu Apr 16 20:01:36 2015 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Thu, 16 Apr 2015 20:01:36 +0000 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> Message-ID: 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 at joachim-breitner.de ? http://www.joachim-breitner.de/ > > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > > Debian Developer: nomeata at debian.org > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.laing.80 at gmail.com Thu Apr 16 23:33:39 2015 From: dave.laing.80 at gmail.com (David Laing) Date: Fri, 17 Apr 2015 09:33:39 +1000 Subject: Increased memory usage with GHC 7.10.1 In-Reply-To: References: <201504011426.06628.jan.stolarek@p.lodz.pl> <201504021419.21520.jan.stolarek@p.lodz.pl> <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu> <201504021447.25480.jan.stolarek@p.lodz.pl> <20150403141423.GA16489@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <4368312B-7AF3-402F-9073-E5A90BF74159@gmail.com> <1429042163.9101.5.camel@joachim-breitner.de> <48701D23-C2FB-4373-92E3-31576CAF4A69@cis.upenn.edu> Message-ID: 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 >> > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ >> > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F >> > Debian Developer: nomeata at debian.org >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maoe at foldr.in Wed Apr 29 04:37:04 2015 From: maoe at foldr.in (Mitsutoshi Aoe) Date: Wed, 29 Apr 2015 04:37:04 +0000 Subject: Looking for retainers of PINNED objects Message-ID: Hi all, I'm profiling a fairly large program which seems to have a space leak. The heap profiling (-hc) shows that PINNED objects are accumulated over time. In order to check the retainers of the objects, I ran the retainer profiling. Unfortunately it didn't output anything with -hr -hcPINNED. Also, this is just a guess though, the retainer profiling without any filters (I mean just -hr) doesn't seem to include PINNED objects at all. Is there a way to check what retains the PINNED objects? Thanks, Mitsutoshi -------------- next part -------------- An HTML attachment was scrubbed... URL: