On Tue, Nov 16, 2010 at 6:35 AM, Jan Hubicka <hubi...@ucw.cz> wrote: >> More FDO related performance numbers >> >> Experiment 1: trunk gcc O2 + FDO vs O2: FDO improves performance >> by 5% geomean >> Experiment 2: our internal gcc compiler (4.4.3 based with many local >> patches) O2 + FDO vs O2 (trunk gcc): FDO improves perf by 6.6% >> geomean >> Experiment 3: our internal gcc (4.4.3 with local patchs) O2 + LIPO vs >> O2 (trunk gcc): LIPO improves by 12% >> Experiment 4: trunk gcc O2 + LTO + fwhole-program + FDO vs O2: LTO + >> FDO improves by 10.8% >> >> >> 1. Trunk gcc FDO vs O2 (5%) >> >> 164.gzip 1324 1302 -1.64% >> 175.vpr 1694 1725 1.84% >> 176.gcc 2293 2387 4.07% >> 181.mcf 1772 1756 -0.88% >> 186.crafty 2320 2280 -1.75% >> 197.parser 1166 1556 33.42% >> 252.eon 2443 2552 4.45% >> 253.perlbmk 2410 2586 7.28% >> 254.gap 1987 2021 1.71% >> 255.vortex 2392 2720 13.71% >> 256.bzip2 1719 1717 -0.12% >> 300.twolf 2288 2331 1.86% >> >> 2. 4.4.3 gcc with local patch FDO vs trunk O2 (6.6%) > > Interesting, any idea from where this 1.6% is comming?
Probably due to local patches (inliner, lrs, etc) we have, but I have not studied it. > I guess LIPO this might > be also reason for that 2% difference in LIPO results (in general LTO > -fwhole-program + FDO should be stronger, but it is not tunned at all yet). > > Since the LIPO branch was updated to mainline some time ago, it would be nice > to compare the LIPO from the branch with mainline LTO. i guess more fair > comparsion > should be O2+FDO+LTO WRT O2+LIPO as LIPO makes no whole program assumptions > at all, right? Yes. Raksit maintains the upstream lipo branch, but it has not been tuned for performance yet. We have open sourced our compiler changes via android. It is better to use that if any one is interested. Thanks, David > > Honza >
