Expenses of unit-at-a-time (Re: On inlining in C++ with unit-at-a-time code(

[Jan Hubicka <hubicka at ucw dot cz>]

> On Thu, Aug 07, 2003 at 03:23:44PM -0400, Nathanael Nerode wrote:
> > I would also like to see unit-at-a-time enabled by default for GCC 3.4.
> > Given that it's always a valid way to compile C/C++, I'd like to see
> > it enabled at *all* optimization levels (although it makes little 
> > pratical difference at -O0).
> > 
> > Think this will be possible?  :-)
> 
> What's the cost for doing unit-at-a-time in terms of compile time and
> virtual memory consumption?

One would expect unit-at-a-time to be expensive :)
However the measurements shows that when inlining is not done (so we
don't measure effectivity of different inlining heuristics), the
unit-at-a-time enabled mode is both slightly faster and less memory
houngry on setup where it does not GGC.  This is because unit-at-a-time
memory management is slightly more effective by not managing both
backend and frontend data together and also it is somewhat more firendly
to the CPU caches (both code and data)

With inlining, the situation is more dificult.  On GCC bootstrap we get
noticeable slowdown in few files - namely insn-recog, insn-attrtab and
java's interpreter.  In insn-recog there are 10 huge functions each
called just once.  GCC with unit-at-a-time inlines them in a way that no
function doubles it's size as inlining limits allows.  This makes GCSE
to discover much more redundancies that introduces many registers that
appear to take longer cse2 and register allocation pass to cleanup.
Finally the crossjumping takes more time as a lot of code is commonized
resulting in about 200KB code size savings but 20% compile time slowdown.
This is ballanced by faster compile times of produced compiler overall
making bootstrap about equal (sometimes faster sometimes slower in my
tests) on x86-64 and about 0.5% faster on i386.

The problem is the peak of memory allocation that may cause problems for
small systems.  When ggc configure to invoke each time, on combine.c the
memory usage (with inlining) after parsing is 3518Kb and memory peaks at
3651Kb.  Without unit-at-a-time memory peaks at 3744Kb.

When heapsize is set to 1MB so I actually get some GGCing, garbage
collector is invoked 29 times peaking at 4826Kb without unit-at-a-time
and 8 times peaking at 5218Kb with unit-at-a-time.  So I would expect
that on 1MB system the unit-at-a-time GCC will swap less than
non-unit-at-a-time one.

Of course it is possible to construct testcases where unit-at-a-time
takes much more memory than normal mode by creating large file
consisting of many small funcitons but I tend to believe that this is
rare in C and in C++ frontend already deffers most of these so the
difference is even smaller.

Honza