Re: VTA merge?

[Richard Guenther <richard dot guenther at gmail dot com>]

2009/6/21 Richard Guenther <richard.guenther@gmail.com>:
> On Sun, Jun 21, 2009 at 7:00 AM, Alexandre Oliva<aoliva@redhat.com> wrote:
>> On Jun 18, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:
>>
>>>> - Memory consumption in cc1/cc1plus at -Ox -g over that set of apps.
>>
>> I had to use a different machine for this test. ?The one I was using had
>> to be taken off line and moved, for reasons beyond my control, and I
>> probably won't be able to get into it to collect the results before I
>> hit the road later this week. ?Sorry.
>>
>>
>> For the total memory uses below, I moved gcc to gcc.actual in both the
>> trunk and vta install trees, and installed a new gcc script that ran
>> maxmem2.sh $0.actual "$@".
>>
>> I modified maxmem-pipe2.py to output to a named pipe, and for maxmem2.sh
>> to wait for the "cat >&2" from the named pipe to complete, just so that
>> I could correlate the memory use output with the command that produced
>> it. ?Without this change, in a number of cases the python script output
>> the totals after make had already printed the following command, which
>> got the output mangled and confusing.
>>
>> Having logged the build output of each of the trees that I had
>> configured before (-O2 is used for all of them), now with the maxmem
>> wrapper, I totaled the "total:" lines it printed for each of the builds,
>> resulting the values in the memory column below.
>>
>> # ?name ? ? ? mem(KiB) %Δ#1 which ?gflags
>> 1 ?g0-trunk ? 58114157 0 ? ?trunk ?-g0
>> 2 ?g0 ? ? ? ? 58114261 0 ? ?vta ? ?-g0
>> 3 ?g-novt ? ? 59722133 2.77 vta ? ?-g -fno-$vt -fno-vta
>> 4 ?g-novta ? ?59840445 2.97 vta ? ?-g -f$vt ? ?-fno-$vta
>> 5 ?g-novt-vta 59764629 2.84 vta ? ?-g -fno-$vt -f$vta
>> 6 ?g ? ? ? ? ?59997781 3.24 vta ? ?-g -f$vt ? ?-f$vta
>>
>> Conclusions: generating debug information incurred a memory penalty of
>> nearly 3% before VTA, for a C-only optimized GCC build.
>>
>> Carrying VTA notes uses very little memory besides that which is
>> required to generate debug info without VT (0.07% more).
>>
>> Actually using VTA notes to emit debug information in the VT pass
>> increases maximum memory use, when compared with VT without VTA, by as
>> little as 0.26%.
>>
>> Wow, this was actually much better than I had anticipated.
>
> The overhead of carrying VTA notes at -g0 vs not doing so would be
> the same 0.07%? ?I'm just curious because I try to be insisting on that
> we do exactly this ;)
>
> I wonder if the above figures apply to compiling a C++ application as well
> (I see a lot of VTA notes - more than 50% of all tree instructions - when
> compiling tramp3d for example).

So I just tested tramp3d for memory usage (I hope I got the same flags as you,
base flags are -O2 -ffast-math -funroll-loops):

-g0 -fno-var-tracking -fno-var-tracking-assignments: 502361 kB
-g -fno-var-tracking -fno-var-tracking-assignments: 615305 kB +18.5%
-g -fno-var-tracking -fvar-tracking-assignments: 647773 kB +5%
-g -fvar-tracking -fvar-tracking-assignments: 655197 kB +1.2%

all %ages relative to the previous line.

So keeping the VTA notes for tramp3d is an overhead of 5%, or
6% on top of -g0 (extrapolated).  The rest may be interesting but
without a trunk build to compare I cannot state anything about
overhead of the branch (var-tracking or -g may be more expensive
due to changes on the branch).

The numbers are from a checking enabled build, so due to more
GC the numbers are artificially low but independent on the amount
of memory in the machine and more realistically reflect the actual
overhead.  Can you specify how you built VTA?

tramp3d certainly is not representative for random C++ applications.
Your GCC testing may be representative for random C applications
(can you check a kernel build to asses compile-time, memory-usage
and debug-size differences?)

Thanks,
Richard.