[llvm-dev] FireFox-46.0.1 build with interprocedural register allocation enabled

[vivek pandya via llvm-dev]

On Tue, Jun 21, 2016 at 5:58 AM, Davide Italiano <davide at freebsd.org> wrote:

> On Mon, Jun 20, 2016 at 12:22 PM, vivek pandya <vivekvpandya at gmail.com>
> wrote:
> >
> >
> > On Mon, Jun 20, 2016 at 10:06 PM, Davide Italiano <davide at freebsd.org>
> > wrote:
> >>
> >> On Sun, Jun 19, 2016 at 11:41 AM, vivek pandya via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >> > Hello,
> >> >
> >> > I build FireFox-46.0.1 source with llvm to test interprocedural
> register
> >> > allocation.
> >> > The build was successful with out any runtime faliures, here are few
> >> > stats:
> >>
> >> This is very good, thanks for working on this.
> >>
> >> >
> >> > Measure W/O IPRA WITH IPRA
> >> > ======= ======== =========
> >> > Total Build Time 76 mins 82.3 mins 8% increment
> >> > Octane v2.0 JS Benchmark Score (higher is better) 18675.69  19665.16
> 5%
> >> > improvement
> >>
> >> This speedup is kind of amazing, enough to make me a little bit
> >> suspicious.
> >> From what I can see, Octane is not exactly a microbenchmark but tries
> >> to model complex/real-world web applications, so, I think you might
> >> want to analyze where this speedup is coming from?
> >
> > Hi Davide,
> >
> > I don't understand much about browser benchmarks but what IPRA is trying
> to
> > do is reduce spill code , and trying to keep values in register where
> ever
> > it can so speed up is comping from improved code quality. But with
> current
> > infrastructure it is hard to tell which particular functions in browser
> code
> > is getting benefitted.
>
> It sounds a little bit weird that you see such a big improvement for a
> benchmark that's supposed to exercise JS (which is very likely handled
> by a JIT inside FF), that's why I asked. My point (and worry) is that
> benchmarks are very hard to get right, and from time to time you might
> end up getting better numbers because of noise and not for 'improved
> code quality'.
>
Yes Davide I also get the same concerns from llvm-devs that benchmarks are
very hard to get right.

Does ff ship JIT related code with in FF or it uses some library for that?

Also IPRA work in llvm is still in progress and this was my very first
experiment building a large software with it. My focus was to check if
there is not any compile time or runtime failures while building such a big
software, but I asked on #firefox IRC about how to measure browser
performance and I got these suggestions, during that chat some one from ff
community asked me to report back the result that is why I just mail this
to ff-dev.

> In other words, as you're presenting numbers, you should be able to
> defend those numbers with an analysis which explains why your pass
> makes the code better. Hope this makes sense.
>
I have noted the points you mentioned and as work progresses I will try to
improve on benchmarking too but this is not the final conclusion.

-Vivek

>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/4f2469e9/attachment.html>