> > > > > > > > From my understanding, -fprofile-partial-training is one important > > > > option for PGO performance. > > > > > > I don't think so, speed benefit would be rather small I guess. > > I saw some articles online to introduce this option for gcc10, > > https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html#sec-gcc10-pgo > > Hi. > > Ah, I see. > > > And also based on my previous experience in Studio compiler, I guess that > > this one might have > > Some good performance impact on PGO. Is there any old performance data on > > this option? (I cannot find online) > > Maybe Honza can chime in here? Or Martin who is the author of the white paper.
Main motivation for this was profiling programs that contain specific code paths for different CPUs (such as graphics library in Firefox or Linux kernel). In the situation training machine differs from the machine program is run later, we end up optimizing for size all code paths except ones taken by the specific CPU. This patch essentially tells gcc to consider every non-trained function as built without profile feedback. For Firefox it had important impact on graphics rendering tests back then since the building machined had AVX while the benchmarking did not. Some benchmarks improved several times which is not a surprise if you consider tight graphics rendering loop optimized for size versus vectorized one. The patch has bad effect on code size which in turn impacts performance too, so I think it makes sense to use -fprofile-partial-training with bit of care (i.e. only one code where such scenarios are likely). As for backporting, I do not have checkout of GCC 8 right now. It depends on profile infrastructure that was added in 2017 (so stage1 of GCC 8), so the patch may backport quite easilly. I am not 100% sure what shape the infrastrucure was in the first version, but I am quite convinced it had the necessary bits - it was able to make the difference between 0 profile count and missing profile feedback. Honza > > Martin > > > > > thanks. > > > > Qing > > > > > > > > > I’d like > > > > to see any big technique difficult to prevent it from being back ported > > > > to GCC8. > > > > > > There might be of course some patch dependencies and I don't see a point > > > why should we waste > > > time with that. > > > > > > Cheers, > > > Martin > > > > > > > > > > > Thanks. > > > > > > > > Qing > > > > > > > > > > > > > > Martin > > > > > > > > > > > > > > > > > Can this patch be back ported to GCC8 easily? I am wondering any > > > > > > significant > > > > > > Change between GCC8 and GCC10 that might make the backporting very > > > > > > hard> > > > > > > Thanks a lot for your help. > > > > > > > > > > > > Qing > > >
