
Hello, This is on the recent topic of very eager inlining in ghc-6.8.3. I wrote recently that (1) 6.8.3 takes 7 times more of heap than 6.8.2 to complile under -O a certain small-size module RsePol_ (let us call it M.hs), (2) even the needed ~70 Mb in 6.8.2 looks unnaturally large. After thinking a bit, I take back (2). For `making' M under -Onot -- all right, it must suffice about 20 Mb. But -O allows deeper optimization, this needs more inlining, inlining pieces between modules, inlining instances (to some extent). I expect that -O needs for compilation not more than about 5 times greater expence in memory and time than -Onot. ghc-6.8.2 satisfies this. And 6.8.3 does not, its ratio is about 35 on the example of RsePol_.hs What is the developer's idea abot -O/-Onot cost ratio for RAM and time? What is the difference between ghc-6.8.2 and ghc-6.8.3 ? The former does not inline instances under -O and the latter does inline? As to the 10-20 % of the result code increase, I am calm about this -- if something it bought by this. But I am not an expert and do not see in what point 6.8.3 is better, at least the DoCon performance is not greater. I do not know, maybe some bugs are fixed, and a bug fix often costs some code increase, and a bug fix is good. Regards, ----------------- Serge Mechveliani mechvel@botik.ru

Serge D. Mechveliani wrote:
What is the difference between ghc-6.8.2 and ghc-6.8.3 ?
Compile times were improved by 4.3% over the nofib suite between 6.8.2 and 6.8.3. Code size was unaffected (down 0.2%). Runtime and allocation were also about the same. That's not to say that we don't believe you - we know for sure that DoCon is experiencing a regression with 6.8.3. However, we looked into it and decided to release despite this regression for two reasons - it wasn't possible to fix it quickly, and we don't believe there's a widespread regression here. But any regression is bad, and we'll make it a high priority to fix this for 6.10.1.
But I am not an expert and do not see in what point 6.8.3 is better, at least the DoCon performance is not greater. I do not know, maybe some bugs are fixed, and a bug fix often costs some code increase, and a bug fix is good.
There are 112 ways in which 6.8.3 is better than 6.8.2 :-) http://hackage.haskell.org/trac/ghc/query?status=closed&milestone=6.8.3&order=priority Cheers, Simon
participants (2)
-
Serge D. Mechveliani
-
Simon Marlow