Dear GHC developers, I wonder whether ghc-6.8.3 is better than 6.8.2. Because 6.8.2 makes DoCon-2.11 under -M400m. And 6.8.3 does not suffice -M500m. It breaks with the heap exhaustion at the module RsePol_. -------------------------------------------------- Moreover, repeated make docon again breaks with the heap exhaustion for -M500m. So this memory is spent to compile a single current module. -------------------------------------------------- The last (difficult) module is RsePol_. And `make' is slower than in 6.8.2, at least at this module. I do not believe that a reasonable compiler may need more than 500 Mb for compiling this poor RsePol_. Second, for the candidate version I reported to the e-mail lists the two problems. The second one was about this memory and time strangeness in compiling RsePol_. Now, you issue an official release, without even considering the second problem. I do not know, maybe this RsePol_ is somehow too irregular (with overlapping instance, etc.), maybe, DoCon is guilty. But as ghc-6.8.2 handles DoCon all right, why do not you investigate this difference in 6.8.3 ? Actually, ghc-6.8.3 does not support DoCon. I wonder what to do. Regards, ----------------- Serge Mechveliani mechvel@botik.ru
Hi Serge, On Wed, Jun 18, 2008 at 04:39:57PM +0400, Serge D. Mechveliani wrote:
But as ghc-6.8.2 handles DoCon all right, why do not you investigate this difference in 6.8.3 ?
We did investigate it - the details are in this trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2328 but the conclusion was that overall it was best to leave things as they are. Unfortunately, this means that performance with GHC 6.8.3 is worse for DoCon; hopefully things will be better with 6.10.1! Thanks Ian
On Wed, Jun 18, 2008 at 02:38:40PM +0100, Ian Lynagh wrote:
Hi Serge,
On Wed, Jun 18, 2008 at 04:39:57PM +0400, Serge D. Mechveliani wrote:
But as ghc-6.8.2 handles DoCon all right, why do not you investigate this difference in 6.8.3 ?
We did investigate it - the details are in this trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2328 but the conclusion was that overall it was best to leave things as they are. Unfortunately, this means that performance with GHC 6.8.3 is worse for DoCon; hopefully things will be better with 6.10.1!
Yes, I see. Thank you for paying attention to this problem. I would like to add the following notes about comparison of ghc-6.8.2 and ghc-6.8.3. 1. As you already knew, abot 3 times slow down is visible in making a certain part of DoCon-2.11 -- due to the module RsePol_. 2. RsePol_.hs is only about 400 lines, together with comments. ghc-6.8.2 suffices -M80m to compile RsePol_.hs. ghc-6.8.3 needs more than -M600m for this.
7 times loss in space.
There are many computers which have not 600 Mb RAM. So, DoCon remains with ghc-6.8.2 -- untill GHC fixes the problem. Hm ... a small module needs > 600 Mb instead of 80 Mb to compile, and the release is considered as a progress. All right, this may occur correct -- if the developers know what namely must be fixed, and also know how to fix it. If so, then I could believe. By the way, not only 6.8.3 looks strange: even 80 Mb looks like an un-naturally large minimum for compiling this small RsePol_.hs. In symbolic computation, in the DoCon test running, in my Dumatel prover test, most examples take less than 40 Mb to perform, while I write all this in Haskell and do not care much for the code optimization. Regards, ----------------- Serge Mechveliani mechvel@botik.ru
| So, DoCon remains with ghc-6.8.2 -- untill GHC fixes the problem. | | Hm ... a small module needs > 600 Mb instead of 80 Mb to compile, | and the release is considered as a progress. | All right, this may occur correct -- if the developers know what | namely must be fixed, and also know how to fix it. If so, then I could | believe. I have looked into this a bit. It's because GHC currently inlines every instance declaration bodily, code and all. DoCon has a lot of instance declarations with a lot of code in them, so there's a tremendous amount of code duplication as a result of dictionary construction. I've been working on a fix for this -- it bites every program, but DoCon especially -- but I have not yet managed to complete it. I'm not quite sure why 6.8.3 is worse than 6.8.2, but both are bad. I'm hoping for a dramatic improvement once I've done my fix. Simon
participants (3)
-
Ian Lynagh -
Serge D. Mechveliani -
Simon Peyton-Jones