Re: How does one debug uninitialized value usage from JavaScript (TB) ?

On (2013年01月30日 04:30), Gary Kwong wrote: > --enable-valgrind --smc-check=all-non-file I was not clear enough. I was compling with --enable-valgrind, and uses --smc-check=all-non-file when TB was executed under valgrind/memcheck already. The only missing piece was --track-origins=yes, which I i

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: How does one debug uninitialized value usage from JavaScript (TB) ?

On (2013年01月29日 19:02), Neil wrote: > ISHIKAWA, Chiaki wrote: > >> I see some code most notably LDAP code in comm-central is not 64bit clean > > Really? Thunderbird has been releasing 64-bit Mac and Linux code for some > time now... > Now I cannot seem to find the problematic code quickly enou

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

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: How does one debug uninitialized value usage from JavaScript (TB) ?

ishikawa wrote: Neil wrote: ISHIKAWA, Chiaki wrote: I see some code most notably LDAP code in comm-central is not 64bit clean Really? Thunderbird has been releasing 64-bit Mac and Linux code for some time now... Now I cannot seem to find the problematic code quickly enough in th

Re: printerenumeration (nsIPrinterEnumerator)

Thanks to both, this is a must have bit of functionality .. for gadget based interfaces! "Zack Weinberg" wrote in message news:r62dnejc_k946ptmnz2dnuvz_skdn...@mozilla.org... On 2013-01-30 2:23 PM, Daniel Holbert wrote: However, be warned that there are patches in bug 629500 to get rid of

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

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

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 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

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 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/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 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

>> 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 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

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

- 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 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: How does one debug uninitialized value usage from JavaScript (TB) ?

(2013/01/31 19:46), Neil wrote: ishikawa wrote: Neil wrote: ISHIKAWA, Chiaki wrote: I see some code most notably LDAP code in comm-central is not 64bit clean Really? Thunderbird has been releasing 64-bit Mac and Linux code for some time now... Now I cannot seem to find the problematic

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 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

Minimizing Layers churn for refactoring

Hi all, Over the last couple of years there were a lot of new additions and changes to the layers sytems which have caused the current implementation to become hard to maintain with a lot of code duplication. The graphics team has been working hard on re-designing part of the layers system, thi

Re: How does one debug uninitialized value usage from JavaScript (TB) ?

(2013/02/01 0:41), ISHIKAWA, Chiaki wrote: (2013/01/31 19:46), Neil wrote: ishikawa wrote: Neil wrote: ISHIKAWA, Chiaki wrote: I see some code most notably LDAP code in comm-central is not 64bit clean Really? Thunderbird has been releasing 64-bit Mac and Linux code for some time now...

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 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 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 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: How does one debug uninitialized value usage from JavaScript (TB) ?

On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote: Sorry, it may not have been ldap code (my memory is now hazy). But please take a look at this code. I am using comm-central code for development/debugging TB. https://mxr.mozilla.org/comm-central/source/mozilla/security/nss/lib/base/hash.c#53 Th

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 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 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

> 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 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

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 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 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 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/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 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: printerenumeration (nsIPrinterEnumerator)

What are "gadget based interfaces", and why do they need to query the browser to enumerate printers? ~Daniel On 01/31/2013 02:54 AM, rvj wrote: > Thanks to both, > > this is a must have bit of functionality .. > > for gadget based interfaces! > > "Zack Weinberg" wrote in message > news:r62dne

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

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 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

- 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

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

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

> 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 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

> 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 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

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 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 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 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

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 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

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

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

> 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

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

> 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: Using anonymous namespace vs 'static'

On Saturday, November 3, 2012 2:20:59 PM UTC-7, Justin Lebar wrote: > > Since you can't refer to anonymous-namespace symbols at all in the Visual > > Studio debugger... > > Are there compiler annotations we could put on a class so that it > behaves as though it's in an anonymous namespace but also

Re: How does one debug uninitialized value usage from JavaScript (TB) ?

(2013/02/01 1:48), Joshua Cranmer wrote: On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote: Sorry, it may not have been ldap code (my memory is now hazy). But please take a look at this code. I am using comm-central code for development/debugging TB. https://mxr.mozilla.org/comm-central/source/mozi

Re: How does one debug uninitialized value usage from JavaScript (TB) ?

On 1/31/2013 8:26 PM, ISHIKAWA, Chiaki wrote: (2013/02/01 1:48), Joshua Cranmer wrote: On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote: Sorry, it may not have been ldap code (my memory is now hazy). But please take a look at this code. I am using comm-central code for development/debugging TB. h

Re: How does one debug uninitialized value usage from JavaScript (TB) ?

(2013/02/01 11:34), Joshua Cranmer wrote: On 1/31/2013 8:26 PM, ISHIKAWA, Chiaki wrote: (2013/02/01 1:48), Joshua Cranmer wrote: On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote: Sorry, it may not have been ldap code (my memory is now hazy). But please take a look at this code. I am using comm-ce

Re: Question about audio/video tag?

Where can we find the decoders for ff and mp4? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

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