New size data -- hopefully it is sane this time.
Changes in experiment
1) shared libstdc++ is used with trunk gcc
2) bfd linker is used in both trunk and patched 4.4.3 compiler (which
used gold).
The size comparison for all C benchmarks in previous report is still
valid. The following is the corrected SPEC06 C++ number and some new
data (Os).
a) SPEC06 size
1. tot O3 vs tot O2
471.omnetpp/ 564839 579088 2.52%
450.soplex/ 352709 365785 3.71%
483.xalancbmk/ 3357954 3501139 4.26%
444.namd/ 319553 328449 2.78%
473.astar/ 31343 40199 28.26%
size_sum 4626398 4814660 4.07%
2. tot Os vs tot O2
471.omnetpp/ 564839 512157 -9.33%
450.soplex/ 352709 256364 -27.32%
483.xalancbmk/ 3357954 2747152 -18.19%
444.namd/ 319553 261799 -18.07%
473.astar/ 31343 26201 -16.41%
size_sum 4626398 3803673 -17.78%
3. tot O2 lto wpa vs tot O2
471.omnetpp/ 564839 531878 -5.84%
450.soplex/ 352709 319476 -9.42%
483.xalancbmk/ 3357954 2966800 -11.65%
444.namd/ 319553 318099 -0.46%
473.astar/ 31343 28747 -8.28%
size_sum 4626398 4165000 -9.97%
4. tot O3 lto wpa vs O2
471.omnetpp/ 564839 646708 14.49%
450.soplex/ 352709 361895 2.60%
483.xalancbmk/ 3357954 3262255 -2.85%
444.namd/ 319553 327738 2.56%
473.astar/ 31343 41707 33.07%
size_sum 4626398 4640303 0.30%
5. patched 4.43 O2 vs tot O2
471.omnetpp/ 564839 539237 -4.53%
450.soplex/ 352709 373263 5.83%
483.xalancbmk/ 3357954 3476137 3.52%
444.namd/ 319553 329769 3.20%
473.astar/ 31343 35250 12.47%
size_sum 4626398 4753656 2.75%
6. Patched 4.4.3 Os vs tot O2
471.omnetpp/ 564839 486838 -13.81%
450.soplex/ 352709 272146 -22.84%
483.xalancbmk/ 3357954 2769330 -17.53%
444.namd/ 319553 255295 -20.11%
473.astar/ 31343 25852 -17.52%
size_sum 4626398 3809461 -17.66%
7. patched 4.4.3 O2 FDO vs tot O2:
471.omnetpp/ 564839 508676 -9.94%
450.soplex/ 352709 356223 1.00%
483.xalancbmk/ 3357954 2919924 -13.04%
444.namd/ 319553 332664 4.10%
473.astar/ 31343 39738 26.78%
size_sum 4626398 4157225 -10.14%
8. patched 4.43 O2 LIPO vs tot O2:
471.omnetpp/ 564839 552361 -2.21%
450.soplex/ 352709 392106 11.17%
483.xalancbmk/ 3357954 3058259 -8.92%
444.namd/ 319553 334522 4.68%
473.astar/ 31343 38690 23.44%
size_sum 4626398 4375938 -5.41%
SPEC2k Os:
1. tot Os vs tot O2
300.twolf/ 182884 150921 -17.48%
181.mcf/ 11794 10246 -13.13%
164.gzip/ 36705 30983 -15.59%
186.crafty/ 171663 149301 -13.03%
255.vortex/ 463463 398908 -13.93%
256.bzip2/ 28803 24795 -13.92%
176.gcc/ 1422042 1158844 -18.51%
197.parser/ 103225 84814 -17.84%
253.perlbmk/ 563927 457664 -18.84%
175.vpr/ 139321 118330 -15.07%
252.eon/ 314603 258560 -17.81%
254.gap/ 496262 403633 -18.67%
size_sum 3934692 3246999 -17.48%
2. patched 4.4.3 Os vs tot Os:
300.twolf/ 150921 156185 3.49%
181.mcf/ 10246 10062 -1.80%
164.gzip/ 30983 30991 0.03%
186.crafty/ 149301 151477 1.46%
255.vortex/ 398908 402780 0.97%
256.bzip2/ 24795 24619 -0.71%
176.gcc/ 1158844 1177628 1.62%
197.parser/ 84814 82718 -2.47%
253.perlbmk/ 457664 466152 1.85%
175.vpr/ 118330 121446 2.63%
252.eon/ 258560 281061 8.70%
254.gap/ 403633 411540 1.96%
size_sum 3246999 3316659 2.15%
David
On Thu, Nov 18, 2010 at 4:37 PM, Mark Heffernan <meh...@google.com> wrote:
> On Thu, Nov 18, 2010 at 4:12 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
>>
>> Interesting. Coincidentally I recently added logic for this for comdat
>> functions (setting probability to 20%) to deal with problems that a lot of
>> C++
>> programs does template instatiations that produce comdat functoins for now
>> good
>> reason. This indeed helped quite a lot. I didn't got so far to set
>> similar
>> logic for normal external functions, since current toolchain won't
>> eliminate
>> them by default.
>
> For non-static, no-address-taken functions, I found that they are emitted in
> the binary (after linker garbage collection) only about 20% of the time or
> so. Surprisingly small. This is for large c++ programs. I'd guess a fair
> number of these functions are template instantiations which may be
> instantiated a particular way (eg, with the same types) in only one
> compilation unit. Plus if all callsites of a function are inlined in one
> compilation unit, it's more likely that they might be inlined in other
> compilation units too. However, I didn't dive down deep to figure out
> exactly why this number is so low.
>>
>> Did the posted size numbers include function garbage collection and
>> unification
>> that is same for mainline as for google copmiler?
>
> I think the size numbers David posted earlier had some problems (statically
> linking stdc++ vs non-statically linked, I believe), so I'd wait until he
> reposts them to draw any conclusions. Not sure if garbage collection was
> enabled or not. In any case, we found maybe a 2% reduction in code size for
> -Os on x86-64 over our benchmark set comparing our local 4.4.3 vs vanilla
> 4.4.3. -O2 is comparable in size, but faster because we inline more
> aggressively which balances out the code size reduction. I have not done
> the comparison vs trunk.
> Mark
>
>>
>> Honza
>
>
