Serge D. Mechveliani | 20 Jun 16:13

-O in 6.8.3

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 
(Continue reading)

Simon Marlow | 20 Jun 17:21

Re: -O in 6.8.3

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

Gmane