<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 21, 2016 at 5:58 AM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Jun 20, 2016 at 12:22 PM, vivek pandya <<a href="mailto:vivekvpandya@gmail.com">vivekvpandya@gmail.com</a>> wrote:<br>
><br>
><br>
> On Mon, Jun 20, 2016 at 10:06 PM, Davide Italiano <<a href="mailto:davide@freebsd.org">davide@freebsd.org</a>><br>
> wrote:<br>
>><br>
>> On Sun, Jun 19, 2016 at 11:41 AM, vivek pandya via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > I build FireFox-46.0.1 source with llvm to test interprocedural register<br>
>> > allocation.<br>
>> > The build was successful with out any runtime faliures, here are few<br>
>> > stats:<br>
>><br>
>> This is very good, thanks for working on this.<br>
>><br>
>> ><br>
>> > Measure W/O IPRA WITH IPRA<br>
>> > ======= ======== =========<br>
>> > Total Build Time 76 mins 82.3 mins 8% increment<br>
>> > Octane v2.0 JS Benchmark Score (higher is better) 18675.69  19665.16 5%<br>
>> > improvement<br>
>><br>
>> This speedup is kind of amazing, enough to make me a little bit<br>
>> suspicious.<br>
>> From what I can see, Octane is not exactly a microbenchmark but tries<br>
>> to model complex/real-world web applications, so, I think you might<br>
>> want to analyze where this speedup is coming from?<br>
><br>
> Hi Davide,<br>
><br>
> I don't understand much about browser benchmarks but what IPRA is trying to<br>
> do is reduce spill code , and trying to keep values in register where ever<br>
> it can so speed up is comping from improved code quality. But with current<br>
> infrastructure it is hard to tell which particular functions in browser code<br>
> is getting benefitted.<br>
<br>
</div></div>It sounds a little bit weird that you see such a big improvement for a<br>
benchmark that's supposed to exercise JS (which is very likely handled<br>
by a JIT inside FF), that's why I asked. My point (and worry) is that<br>
benchmarks are very hard to get right, and from time to time you might<br>
end up getting better numbers because of noise and not for 'improved<br>
code quality'.<br></blockquote><div>Yes Davide I also get the same concerns from llvm-devs that benchmarks are very hard to get right. </div><div><br></div><div>Does ff ship JIT related code with in FF or it uses some library for that?</div><div><br></div><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In other words, as you're presenting numbers, you should be able to<br>
defend those numbers with an analysis which explains why your pass<br>
makes the code better. Hope this makes sense.<br></blockquote><div>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.</div><div><br></div><div>-Vivek </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br>
</div></div></blockquote></div><br></div></div>