[llvm-dev] llvm (the middle-end) is getting slower, December edition
Mikhail Zolotukhin via llvm-dev
llvm-dev at lists.llvm.org
Mon Dec 19 15:55:06 PST 2016
> On Dec 17, 2016, at 7:48 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Dec 17, 2016 7:41 PM, "Sean Silva" <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote:
>
>
> On Sat, Dec 17, 2016 at 6:32 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> On Sat, Dec 17, 2016 at 1:35 PM, Davide Italiano <davide at freebsd.org <mailto:davide at freebsd.org>> wrote:
> [...]
>
> > I don't have an infrastructure to measure the runtime performance
> > benefits/regression of clang, but I have for `game7`.
> > I wasn't able to notice any fundamental speedup (at least, not
> > something that justifies a 2x build-time).
> >
>
> Just to provide numbers (using Sean's Mathematica template, thanks),
> here's a plot of the CDF of the frames in a particular level/scene.
> The curves pretty much match, and the picture in the middle shows a
> relative difference of 0.4% between Jun and Dec (which could be very
> possibly be in the noise).
>
> With 5-10 runs per binary you should be able to reliably measure down to 0.5% difference on game7 (50 usec difference per frame). With just one run per binary like you have here I would not trust a 0.4% difference.
>
> Yeah, I agree. This was mostly a sanity check to understand if there was a significant improvement at runtime. I ran the same test 7 times in the last our but the difference is always in the noise, FWIW.
FWIW, opt has an option '-run-twice', which might be helpful if compile time of a particular unit is too small (it would be nice to change it to -run-n-times though to make it more flexible).
Michael
>
> -- Sean Silva
>
> On the same scene, the difference between -O3 and -flto is 12%, FWIW.
> So it seems that at least for this particular case all the compile
> time didn't buy any runtime improvement.
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161219/b5ae2d18/attachment.html>
More information about the llvm-dev
mailing list