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