Re: The future of PGO on Windows

On 2013-04-20 5:07 AM, papal...@gmail.com wrote: Me commenting on a blog post concerning PGO: You forgot to mention that you need a lot of memory! A problem the for example the Firefox developers ran into. The compiler/linker ran out of virtual memory when doing the 32-bit releases (and cross-co

Re: The future of PGO on Windows

Me commenting on a blog post concerning PGO: > You forgot to mention that you need a lot of memory! A problem the for example > the Firefox developers ran into. The compiler/linker ran out of virtual > memory when doing the 32-bit releases (and cross-compiling from the 64-bit > compiler sadly still

Re: The future of PGO on Windows

On 08/02/2013 21:53, Brian Smith wrote: The assumption here seems to be that it would be OK to ship a significant performance regression for 32-bit users as long as 64-bit users don't see a regression. It's not. The assumption is that it will be unavoidable to turn off PGO for 32 bit builds (a

Re: The future of PGO on Windows

Jean-Marc Desperrier wrote: > The start of the discussion is that PGO for 32-bit builds will be > really hard to maintain soon. If doing 64-bit PGO builds is costly and > impairs the ability to deliver efficient 32-bits non-PGO builds then > it's not compelling. The assumption here seems to be tha

Re: The future of PGO on Windows

On 2/6/2013 12:01 PM, Jean-Marc Desperrier wrote: On W3Schools, XP usage is significantly going down : http://www.w3schools.com/browsers/browsers_os.asp That's not a very good proxy for our users or our target users. W3Schools is a web developer focused site so they're going to reflect that

Re: The future of PGO on Windows

Dave Mandelin a écrit : >Approximately 35% of our installs are on Windows XP. Microsoft has said that >less than 1% of XP installs are 64-bit. About 7% of our users are on Vista. >Microsoft said Vista's 64-bit percentage is about 11%. Just over 50% of our >Windows users are on Windows 7. Microsof

Re: The future of PGO on Windows

On Mon, Feb 4, 2013 at 11:23 PM, Asa Dotzler wrote: > On 2/4/2013 6:59 PM, Dave Mandelin wrote: >> I was talking to Taras and Naveed about this today, and what also >> came up was: >> >> 4. Do the work to make 64-bit JS jit perf as good as 32-bit JS jit >> perf, and then switch to x64 builds for W

Re: The future of PGO on Windows

On 2013-02-05 11:18 AM, Jean-Marc Desperrier wrote: Ehsan Akhgari a écrit : currently we cannot do 64-bit PGO builds because of an internal compiler error on mozilla-central. Also with VS2012 ? I'm not aware if anybody has tried 64-bit PGO builds with VS2012. Cheers, Ehsan

Re: The future of PGO on Windows

Ehsan Akhgari a écrit : currently we cannot do 64-bit PGO builds because of an internal compiler error on mozilla-central. Also with VS2012 ? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: The future of PGO on Windows

On 2013-02-04 10:07 PM, Ryan VanderMeulen wrote: On 2/4/2013 9:59 PM, Dave Mandelin wrote: I was talking to Taras and Naveed about this today, and what also came up was: 4. Do the work to make 64-bit JS jit perf as good as 32-bit JS jit perf, and then switch to x64 builds for Windows. There are

Re: The future of PGO on Windows

On 2013-02-04 9:59 PM, Dave Mandelin wrote: On Friday, February 1, 2013 7:19:04 PM UTC-8, Brian Smith wrote: Ehsan Akhgari wrote: Given the above, I'd like to propose the following long-term solutions: 1. Did we try escalating a support request to Microsoft regarding this issue? I know

Re: The future of PGO on Windows

On 2/4/2013 9:59 PM, Dave Mandelin wrote: I was talking to Taras and Naveed about this today, and what also came up was: 4. Do the work to make 64-bit JS jit perf as good as 32-bit JS jit perf, and then switch to x64 builds for Windows. There are of course many issues involved with such a switc

Re: The future of PGO on Windows

On Monday, February 4, 2013 1:39:46 PM UTC-8, Brian Smith wrote: > Also, I want to echo khuey's comment: It seems like a lot of the argument > against PGO is that, while our benchmarks are faster, users won't actually > notice any difference. If that is true, then I agree with khuey that that is

Re: The future of PGO on Windows

On Friday, February 1, 2013 7:19:04 PM UTC-8, Brian Smith wrote: > Ehsan Akhgari wrote: > > > Given the above, I'd like to propose the following long-term > > > solutions: > > > > 1. Did we try escalating a support request to Microsoft regarding this issue? > I know it is kind of an odd thing

Re: The future of PGO on Windows

On 2013-02-04 4:39 PM, Brian Smith wrote:> Ehsan Akhgari wrote: >> On 2013-02-04 11:44 AM, Ehsan Akhgari wrote: >>> 3. What is the performance difference between Visual Studio >>> 2012 PGO builds and Visual Studio 2010 builds? IMO, before >>> we decide whether to disable PGO on Wind

Re: The future of PGO on Windows

On 2/4/2013 4:27 PM, Brian Smith wrote: Ehsan Akhgari wrote: Brian Smith wrote: 2. AFAICT, we did not seriously investigate the possibility of splitting things out of libxul more. So far we've tried cutting things off the top of the dependency tree. Maybe now we need to try cutting things off t

Re: The future of PGO on Windows

Ehsan Akhgari wrote: > On 2013-02-04 11:44 AM, Ehsan Akhgari wrote: > > 3. What is the performance difference between Visual Studio > > 2012 PGO builds and Visual Studio 2010 builds? IMO, before > > we decide whether to disable PGO on Windows, we need to get > > good benchmark resul

Re: The future of PGO on Windows

On 2013-02-04 4:27 PM, Brian Smith wrote: Ehsan Akhgari wrote: Brian Smith wrote: 2. AFAICT, we did not seriously investigate the possibility of splitting things out of libxul more. So far we've tried cutting things off the top of the dependency tree. Maybe now we need to try cutting things off

Re: The future of PGO on Windows

Ehsan Akhgari wrote: > Brian Smith wrote: > > 2. AFAICT, we did not seriously investigate the possibility of > > splitting things out of libxul more. So far we've tried cutting > > things off the top of the dependency tree. Maybe now we need to try > > cutting things off the bottom of the dependenc

Re: The future of PGO on Windows

On 2013-02-04 11:44 AM, Ehsan Akhgari wrote: 3. What is the performance difference between Visual Studio 2012 PGO builds and Visual Studio 2010 builds? IMO, before we decide whether to disable PGO on Windows, we need to get good benchmark results for Visual Studio **2012** PGO bui

Re: The future of PGO on Windows

On Fri, Feb 1, 2013 at 10:19 PM, Brian Smith wrote: > Ehsan Akhgari wrote: > > Given the above, I'd like to propose the following long-term > > solutions: > > 1. Did we try escalating a support request to Microsoft regarding this > issue? I know it is kind of an odd thing, but it seems like if yo

Re: The future of PGO on Windows

(Re-posting to dev-platform -- I had replied to Nick privately by mistake. On Fri, Feb 1, 2013 at 9:46 PM, Nicholas Nethercote wrote: > On Sat, Feb 2, 2013 at 9:05 AM, Ehsan Akhgari > wrote: > >> > >> Has anyone tried running PGO and non-PGO builds of the same changeset > >> to see how they feel

Re: The future of PGO on Windows

As someone who's maintained a c++ scientific library (eigen.tuxfamily.org) until 2 years ago: - GCC >= 4.4 generated the fastest code of any compiler I tried when it came out (MSVC, ICC, Clang); 4.5 was even better; I stopped tracking after that. ICC had less bad auto-vectorization, but it was sti

Re: The future of PGO on Windows

Ehsan Akhgari wrote: > Given the above, I'd like to propose the following long-term > solutions: 1. Did we try escalating a support request to Microsoft regarding this issue? I know it is kind of an odd thing, but it seems like if you are insistent enough and/or pay enough money, Microsoft engin

Re: The future of PGO on Windows

On Sat, Feb 2, 2013 at 6:26 AM, Ehsan Akhgari wrote: > > Vladan performed the analysis on telemetry measures reported out of a Tp5 > run and the results seem to indicate that the performance of several things > such as GC and CC, image decoding, page loading, session restore, search > service init

Re: The future of PGO on Windows

On 2013-01-30 11:03 PM, Ehsan Akhgari wrote: We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LTCG will result in a regression of about 10-20% on benchmarks which examine DOM and layout perfor

Re: The future of PGO on Windows

On 2/1/2013 1:51 PM, Daniel Veditz wrote: > On 1/30/2013 8:03 PM, Ehsan Akhgari wrote: >> It turns out that disabling PGO but keeping LTCG enabled reduces the >> memory usage by ~200MB, which means that it's not an effective >> measure. Disabling both LTCG and PGO brings down the linker's >> virtu

Re: The future of PGO on Windows

On 1/30/2013 8:03 PM, Ehsan Akhgari wrote: It turns out that disabling PGO but keeping LTCG enabled reduces the memory usage by ~200MB, which means that it's not an effective measure. Disabling both LTCG and PGO brings down the linker's virtual memory usage to around 1GB, which means that we wil

Re: The future of PGO on Windows

On 2/1/13 10:52 AM, Jean-Marc Desperrier wrote: Ehsan Akhgari a écrit : I don't have a lot of experience with mingw32, but to the best of my knowledge, it's based on older versions of gcc (4.6?), and lacks 64-bit support Ehsan, did you forget that there would be no memory problem with 64-bits

Re: The future of PGO on Windows

Boris Zbarsky a écrit : On 2/1/13 10:52 AM, Jean-Marc Desperrier wrote: The trouble with going 64-bits is that the jit would then see some significant regression, for cache pressure/instruction set related reasons Do you have numbers here? I'm aware of some regressions for things that involve

Re: The future of PGO on Windows

On 2013-02-01 10:52 AM, Jean-Marc Desperrier wrote: Ehsan Akhgari a écrit : I don't have a lot of experience with mingw32, but to the best of my knowledge, it's based on older versions of gcc (4.6?), and lacks 64-bit support Ehsan, did you forget that there would be no memory problem with 64-b

Re: The future of PGO on Windows

Nathan Froyd a écrit : Do you have examples that you can point to? I'm sure the GCC folks would be interested in hearing about concrete examples... OK, there was many examples with older GCC versions, but it's not guaranteed to be still true with the newest GCC which had significant enhancem

Re: The future of PGO on Windows

On 2/1/13 10:52 AM, Jean-Marc Desperrier wrote: The trouble with going 64-bits is that the jit would then see some significant regression, for cache pressure/instruction set related reasons Do you have numbers here? I'm aware of some regressions for things that involve traversing DOM trees in

Re: The future of PGO on Windows

On 2/1/13 10:50 AM, Nathan Froyd wrote: Do you have examples that you can point to? This certainly used to be the case for Mozilla code at one point, but it may be worth remeasuring. Lots of gcc (and MSVC, and Mozilla code) changes since then. -Boris ___

Re: The future of PGO on Windows

Ehsan Akhgari a écrit : I don't have a lot of experience with mingw32, but to the best of my knowledge, it's based on older versions of gcc (4.6?), and lacks 64-bit support Ehsan, did you forget that there would be no memory problem with 64-bits MSVC PGO builds ? The trouble with going 64-bi

Re: The future of PGO on Windows

- Original Message - > cja...@gmail.com a écrit : > > Currently the best option for mingw is mingw-w64 for that (besides > > what the name suggests) supports both 32 and 64-bit targets. Also > > it > > works with any version of GCC newer than 4.4, AFAIR. > > The question here is about perf

Re: The future of PGO on Windows

cja...@gmail.com a écrit : I don't have a lot of experience with mingw32, but to the best of my >knowledge, it's based on older versions of gcc (4.6?), >and lacks 64-bit support Currently the best option for mingw is mingw-w64 for that (besides what the name suggests) supports both 32 and 64-b

Re: The future of PGO on Windows

On 1/2/13 00:00, cja...@gmail.com wrote: Also, stupid question time: is it possible to build on Windows with GCC and/or clang? Yes, even better, it's possible to build on Linux for Windows using GCC, see: https://developer.mozilla.org/en-US/docs/Cross_Compile_Mozilla_for_Mingw32 It should be

Re: The future of PGO on Windows

On 31/01/13 17:40, Robert O'Callahan wrote: > Also, reducing the number of directories that are PGO/LTCG should mean that > the rate of growth decreases proportionally. Even more than proportionally, > if we flip our default for entirely new modules to be non-PGO/LTCG, as I > assume we would. Prof

Re: The future of PGO on Windows

> I don't have a lot of experience with mingw32, but to the best of my > knowledge, it's based on older versions of gcc (4.6?), > and lacks 64-bit support Currently the best option for mingw is mingw-w64 for that (besides what the name suggests) supports both 32 and 64-bit targets. Also it works

Re: The future of PGO on Windows

W dniu czwartek, 31 stycznia 2013 14:21:06 UTC+1 użytkownik Joshua Cranmer napisał: > On 1/31/2013 2:37 AM, Nicholas Nethercote wrote: > > > Also, stupid question time: is it possible to build on Windows with > > > GCC and/or clang? > > > It's definitely possible to build with Mingw GCC, but

Re: The future of PGO on Windows

> Also, stupid question time: is it possible to build on Windows with > GCC and/or clang? Yes, even better, it's possible to build on Linux for Windows using GCC, see: https://developer.mozilla.org/en-US/docs/Cross_Compile_Mozilla_for_Mingw32 It should be also possible to build on Windows, but

Re: The future of PGO on Windows

Here are some additional test suites from perftastic for reference. Tp5 from last summer, XP and Win7: http://graphs.mozilla.org/graph.html#tests=[[177,94,12],[177,1,12],[177,94,1],[177,1,1]]&sel=none&displayrange=365&datatype=running Sunspider 2, Win7: http://graphs.mozilla.org/graph.html#tests

Re: The future of PGO on Windows

On Thursday, January 31, 2013 12:40:13 PM UTC-8, Ehsan Akhgari wrote: > On 2013-01-31 2:49 PM, David Anderson wrote: > > > On Thursday, January 31, 2013 8:54:50 AM UTC-8, Ehsan Akhgari wrote: > > >> On 2013-01-31 10:59 AM, ... wrote: > > >> > > As a historical note, when we first enabled P

Re: The future of PGO on Windows

On 2013-01-31 2:49 PM, David Anderson wrote: On Thursday, January 31, 2013 8:54:50 AM UTC-8, Ehsan Akhgari wrote: On 2013-01-31 10:59 AM, ... wrote: As a historical note, when we first enabled PGO support for Windows our profiling scenario was "start Firefox, wait 10 seconds, shut down F

Re: The future of PGO on Windows

Just to echo what David said, PGO builds cause amorphous stability and even graphics/layout bugs (for instance bug 831296) that we're forced to investigate in engineering and QA for a specific release, even though the issues aren't typically caused by actual in-product regressions. Additionally,

Re: The future of PGO on Windows

On Jan 31, 12:04 pm, Chris Peterson wrote: > On 1/31/13 11:21 AM, L. David Baron wrote: > > >> On Thu, Jan 31, 2013 at 1:31 PM, L. David Baron wrote: > >>> Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY > >>> meaningful on Windows (they currently only do anything on gcc or >

Re: The future of PGO on Windows

On 1/31/13 11:21 AM, L. David Baron wrote: On Thu, Jan 31, 2013 at 1:31 PM, L. David Baron wrote: Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY meaningful on Windows (they currently only do anything on gcc or clang builds)? If we did, might that get back some of the gain

Re: The future of PGO on Windows

On Thursday, January 31, 2013 11:44:28 AM UTC-8, Jim Mathies wrote: > > > Our Talos results may be measuring imperfect things, but we have > > > enough datapoints that we can draw statistical conclusions from > > > them confidently. > > > Statistics doesn't help if you're measuring the wrong thing

Re: The future of PGO on Windows

On 2013-01-31 1:07 PM, Ted Mielczarek wrote: > After consideration, I think we ought to just bite the bullet and disable PGO. We have no other way to fix this issue. All other work we can do simply pushes it down the road. As our recent history has shown, we simply don't have the ability to fix

Re: The future of PGO on Windows

On Thursday, January 31, 2013 11:32:52 AM UTC-8, Joshua Cranmer wrote: > On 1/31/2013 12:05 PM, Dave Mandelin wrote: > > On Thursday, January 31, 2013 9:17:44 AM UTC-8, Joshua Cranmer wrote: > >> For what it's worth, reading > >> , I do not get

Re: The future of PGO on Windows

On Thursday, January 31, 2013 8:54:50 AM UTC-8, Ehsan Akhgari wrote: > On 2013-01-31 10:59 AM, ... wrote: > > >> As a historical note, when we first enabled PGO support for Windows our > > >> profiling scenario was "start Firefox, wait 10 seconds, shut down > > >> Firefox". Enabling PGO with thi

Re: The future of PGO on Windows

> Our Talos results may be measuring imperfect things, but we have > enough datapoints that we can draw statistical conclusions from > them confidently. Statistics doesn't help if you're measuring the wrong things. Whether Ts is measuring the wrong thing, I don't know. It would be possible to

Re: The future of PGO on Windows

On 1/31/2013 12:05 PM, Dave Mandelin wrote: On Thursday, January 31, 2013 9:17:44 AM UTC-8, Joshua Cranmer wrote: For what it's worth, reading , I do not get the impression that dmandelin "proved" otherwise. His startup tests have very low s

Re: The future of PGO on Windows

> On Thu, Jan 31, 2013 at 1:31 PM, L. David Baron wrote: > > Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY > > meaningful on Windows (they currently only do anything on gcc or > > clang builds)? If we did, might that get back some of the gain from > > turning off PGO? On Th

Re: The future of PGO on Windows

On Thu, Jan 31, 2013 at 01:59:36PM -0500, Ehsan Akhgari wrote: > MSVC supports __assume, which is similar but not quite the same. I'm very > skeptical that by simply using __assume we'll regain the benchmark hit > resulting from turning PGO off. __assume is not even close to similar, and it's act

Re: The future of PGO on Windows

MSVC supports __assume, which is similar but not quite the same. I'm very skeptical that by simply using __assume we'll regain the benchmark hit resulting from turning PGO off. -- Ehsan On Thu, Jan 31, 2013 at 1:31 PM, L. David Baron wrote: > Is it possible we might

Re: The future of PGO on Windows

- Original Message - > Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY > meaningful on Windows (they currently only do anything on gcc or > clang builds)? If we did, might that get back some of the gain from > turning off PGO? Nope: http://social.msdn.microsoft.com/fo

Re: The future of PGO on Windows

On Thu, Jan 31, 2013 at 12:12 PM, Kyle Huey wrote: > > On Thu, Jan 31, 2013 at 9:09 AM, Ehsan Akhgari wrote: > >> On 2013-01-31 11:58 AM, Kyle Huey wrote: >> >>> On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari >> > wrote: >>> >>> On 2013-01-31 11:43 AM, Kyle

Re: The future of PGO on Windows

Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY meaningful on Windows (they currently only do anything on gcc or clang builds)? If we did, might that get back some of the gain from turning off PGO? -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢

Re: The future of PGO on Windows

On Thu, Jan 31, 2013 at 01:07:39PM -0500, Ted Mielczarek wrote: > After consideration, I think we ought to just bite the bullet and > disable PGO. We have no other way to fix this issue. All other work we > can do simply pushes it down the road. As our recent history has shown, > we simply don't ha

Re: The future of PGO on Windows

On Thursday, January 31, 2013 9:17:44 AM UTC-8, Joshua Cranmer wrote: > On 1/31/2013 10:51 AM, Ehsan Akhgari wrote: > > On 2013-01-31 11:43 AM, Kyle Huey wrote: > >> On Wed, Jan 30, 2013 at 8:03 PM, Ehsan Akhgari >> > wrote: > >> > >> We then tried to get a sens

Re: The future of PGO on Windows

On 1/30/2013 11:03 PM, Ehsan Akhgari wrote: > (Follow-ups to dev-platform, please) > > Dear all, > > This email summarizes the results of our investigation on our options > with regard to the future of PGO optimizations on Windows. I will > first describe the work that happened as part of the inve

Re: The future of PGO on Windows

On 1/31/2013 10:51 AM, Ehsan Akhgari wrote: On 2013-01-31 11:43 AM, Kyle Huey wrote: On Wed, Jan 30, 2013 at 8:03 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by

Re: The future of PGO on Windows

On 01/31/13 12:10 PM, Boris Zbarsky wrote: > Even if we posit the slowdown is the same, the PR loss is not. > > Say browser A takes time T to run a test, browser B takes time 1.2T and > browser C takes time 0.8T. > > Say browsers B and C both suffer a 10% regression on that test. Now the > times

Re: The future of PGO on Windows

On 1/31/13 10:33 AM, Till Schneidereit wrote: Do we think the planned optimizations cause the gains through PGO to be less pronounced? It... depends. There are a few things at play here. First of all, our current profiling at least for DOM and layout stuff is largely looking for the wallet w

Re: The future of PGO on Windows

On Thu, Jan 31, 2013 at 9:09 AM, Ehsan Akhgari wrote: > On 2013-01-31 11:58 AM, Kyle Huey wrote: > >> On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari > > wrote: >> >> On 2013-01-31 11:43 AM, Kyle Huey wrote: >> >> Isn't PGO worth something like 15% on

Re: The future of PGO on Windows

On 01/31/13 10:59 AM, jmath...@mozilla.com wrote: > IMHO, if it's a choice between infra load and better performance > in the end product, performance should win out. We're not talking about infrastructure load here, we're talking about whether or not we can compile at all. ___

Re: The future of PGO on Windows

On 2013-01-31 11:58 AM, Kyle Huey wrote: On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2013-01-31 11:43 AM, Kyle Huey wrote: Isn't PGO worth something like 15% on Ts? That was what I thought, but local measurements performed by d

Re: The future of PGO on Windows

> 3. Try to delay disabling PGO/LTCG until the next time that we hit the > limit, and disable PGO/LTCG then once and for all. In order to > implement this solution, we're going to need: >* A person to own watching the graphs and report back when we step > inside the danger zone again. I th

Re: The future of PGO on Windows

On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari wrote: > On 2013-01-31 11:43 AM, Kyle Huey wrote: > >> Isn't PGO worth something like 15% on Ts? >> > > That was what I thought, but local measurements performed by dmandelin > proved otherwise. > Uh, don't we have a bigger problem then? - Kyle

Re: The future of PGO on Windows

On 2013-01-31 10:59 AM, jmath...@mozilla.com wrote: As a historical note, when we first enabled PGO support for Windows our profiling scenario was "start Firefox, wait 10 seconds, shut down Firefox". Enabling PGO with this profiling run provided us with 20-25% perf improvements in many of our ben

Re: The future of PGO on Windows

On 2013-01-31 11:43 AM, Kyle Huey wrote: On Wed, Jan 30, 2013 at 8:03 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LT

Re: The future of PGO on Windows

On 2013-01-31 11:03 AM, Till Schneidereit wrote: On Thu, Jan 31, 2013 at 4:42 PM, Ehsan Akhgari wrote: On 2013-01-31 10:33 AM, Till Schneidereit wrote: In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? Because we're stil

Re: The future of PGO on Windows

On Wed, Jan 30, 2013 at 8:03 PM, Ehsan Akhgari wrote: > We then tried to get a sense of how much of a win the PGO optimizations > are. Thanks to a series of measurements by dmandelin, we know that > disabling PGO/LTCG will result in a regression of about 10-20% on > benchmarks which examine DOM a

Re: The future of PGO on Windows

On 1/31/2013 11:38 AM, jmath...@mozilla.com wrote: > http://graphs.mozilla.org/graph.html#tests=[[83,94,12],[83,1,12]]&sel=none&displayrange=365&datatype=running > > Ts, Paint shows an improvement of 14%. This is with Firefox and > Firefox-Non-PGO, which I believe to be mc. Also while I can't seem

Re: The future of PGO on Windows

On Thursday, January 31, 2013 8:14:01 AM UTC-6, Gregory Szorc wrote: > My reading of Ehsan's summary is that there is no significant *user* > benefit (read: perf win) of PGO. > > If there is no *user* benefit, then the only data that remains to > justify PGO are the benchmark results. > > There

Re: The future of PGO on Windows

On Thu, Jan 31, 2013 at 4:42 PM, Ehsan Akhgari wrote: > On 2013-01-31 10:33 AM, Till Schneidereit wrote: In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? >>> >>> >>> >>> >>> Because we're still missing plenty of op

Re: The future of PGO on Windows

> As a historical note, when we first enabled PGO support for Windows our > profiling scenario was "start Firefox, wait 10 seconds, shut down > Firefox". Enabling PGO with this profiling run provided us with 20-25% > perf improvements in many of our benchmarks on Talos. We later changed > it to the

Re: The future of PGO on Windows

On 2013-01-31 10:33 AM, Till Schneidereit wrote: In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty of optimizations in our code to be fast in microbenchmarks. It would be quite huge pr loss

Re: The future of PGO on Windows

- Original Message - > We should also remind that there would be an infra load win from > disabling Windows PGO builds. Plus less of a lead time waiting for PGO results before an inbound -> mozilla-central merge can be performed :-D (even if we keep PGO on other platforms, Windows was alw

Re: The future of PGO on Windows

On 2013-01-31 6:39 AM, jmath...@mozilla.com wrote: We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LTCG will result in a regression of about 10-20% on benchmarks which examine DOM and layout

Re: The future of PGO on Windows

On 2013-01-31 5:38 AM, Neil wrote: smaug wrote: On 01/31/2013 10:37 AM, Nicholas Nethercote wrote: If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty of optimizations in our code to be fast in microbenchmarks. Do we know (e.g.

Re: The future of PGO on Windows

>> In the long run, 1 and 3 are the same. If we know we're going to turn >> it off, why not bite the bullet and do it now? > > > > Because we're still missing plenty of optimizations in our code > to be fast in microbenchmarks. It would be quite huge pr loss if we suddenly > were 10-20% slower in

Re: The future of PGO on Windows

On 2013-01-31 3:37 AM, Nicholas Nethercote wrote: On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari wrote: Given the above, I'd like to propose the following long-term solutions: 1. Disable PGO/LTCG now. 2. Try to delay disabling PGO/LTCG as much as possible. 3. Try to delay disabling PGO/LTCG

Re: The future of PGO on Windows

On 1/31/2013 9:14 AM, Gregory Szorc wrote: Given the headaches PGO has caused and will likely continue to cause, I believe KISS applies and it is up to PGO advocates to justify the continued use of PGO with data showing a clear benefit. My reading of Ehsan's summary is that there is no signific

Re: The future of PGO on Windows

On 1/31/2013 8:22 AM, papal...@gmail.com wrote: > How separate the analysis phase from the optimization based on the collected > data? How are the results of the PGO runs stored? Can the optimization part > be run independently? If yes would it be possible to collect the data through > other mea

Re: The future of PGO on Windows

On 1/30/13 8:03 PM, Ehsan Akhgari wrote: We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LTCG will result in a regression of about 10-20% on benchmarks which examine DOM and layout performanc

Re: The future of PGO on Windows

On 1/31/2013 2:37 AM, Nicholas Nethercote wrote: Also, stupid question time: is it possible to build on Windows with GCC and/or clang? It's definitely possible to build with Mingw GCC, but that is a major ABI-breaking change, and I think we lose the ability to compile against any Microsoft ID

Re: The future of PGO on Windows

How separate the analysis phase from the optimization based on the collected data? How are the results of the PGO runs stored? Can the optimization part be run independently? If yes would it be possible to collect the data through other means, let's say by doing a x86-64 build or only statically

Re: The future of PGO on Windows

On 1/31/2013 6:39 AM, jmath...@mozilla.com wrote: >> We then tried to get a sense of how much of a win the PGO optimizations >> are. Thanks to a series of measurements by dmandelin, we know that >> disabling PGO/LTCG will result in a regression of about 10-20% on >> benchmarks which examine DOM

Re: The future of PGO on Windows

> We then tried to get a sense of how much of a win the PGO optimizations > are. Thanks to a series of measurements by dmandelin, we know that > disabling PGO/LTCG will result in a regression of about 10-20% on > benchmarks which examine DOM and layout performance such as Dromaeo and > guimark

Re: The future of PGO on Windows

smaug wrote: On 01/31/2013 10:37 AM, Nicholas Nethercote wrote: If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty of optimizations in our code to be fast in microbenchmarks. Do we know (e.g. via profiling) where these optimisa

Re: The future of PGO on Windows

On 01/31/2013 10:37 AM, Nicholas Nethercote wrote: On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari wrote: Given the above, I'd like to propose the following long-term solutions: 1. Disable PGO/LTCG now. 2. Try to delay disabling PGO/LTCG as much as possible. 3. Try to delay disabling PGO/LTCG

Re: The future of PGO on Windows

On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari wrote: > Given the above, I'd like to propose the following long-term solutions: > > 1. Disable PGO/LTCG now. > > 2. Try to delay disabling PGO/LTCG as much as possible. > > 3. Try to delay disabling PGO/LTCG until the next time that we hit the > limi

Re: The future of PGO on Windows

On Wed, Jan 30, 2013 at 11:49:01PM -0500, Ehsan Akhgari wrote: > The decrease is unfortunately not linear, as it seems like the big > memory eater is LTCG, and unfortunately we cannot opt out of that if > we want to do any PGO. Well, LTCG is only going to compile objects that have been compiled wi

Re: The future of PGO on Windows

On 2013-01-30 11:40 PM, Robert O'Callahan wrote: On Thu, Jan 31, 2013 at 5:34 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2013-01-30 11:11 PM, Robert O'Callahan wrote: What about leaving PGO/LTCG enabled for a subset of our modules? Is that not a pos

Re: The future of PGO on Windows

On Thu, Jan 31, 2013 at 5:34 PM, Ehsan Akhgari wrote: > On 2013-01-30 11:11 PM, Robert O'Callahan wrote: > >> What about leaving PGO/LTCG enabled for a subset of our modules? Is that >> not a possible solution? >> > > I did in fact measure that by disabling PGO/LTCG on all directories except > con

Re: The future of PGO on Windows

On 2013-01-30 11:11 PM, Robert O'Callahan wrote: What about leaving PGO/LTCG enabled for a subset of our modules? Is that not a possible solution? I did in fact measure that by disabling PGO/LTCG on all directories except content, dom, layout and xpcom. I can't seem to find the try push righ

Re: The future of PGO on Windows

What about leaving PGO/LTCG enabled for a subset of our modules? Is that not a possible solution? Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants

  1   2   >