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 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 current set of profiling data[1] (Blueprint CSS samples, the > > >> > > >>>> SunSpider benchmark), and there was almost no visible change in the > > >> > > >>>> Talos numbers. > > >> > > >>> > > >> > > >>> This seems to indicate our current coverage isn't oriented toward > > >> > > >>> performance gains users will see, and that there are potential > > >> > > >>> gains to be found. All the more reason to keep pgo around a while > > >> > > >>> longer and figure out how we can simplify testing with different test > > >> > > >>> runs. > > >> > > >> > > >> > > >> There are costs to keeping PGO enabled, and while we can argue that we > > >> > > >> _could_ be getting more PGO gain by providing a better profile, one > > >> > > >> could counter-argue that engineers can spend more time optimizing other > > >> > > >> things if they didn't need to find the perfect profile (which is sort of > > >> > > >> a black magic.) > > >> > > >> > > >> > > >>>> We should also remind that there would be an infra load win from > > >> > > >>>> disabling Windows PGO builds. > > >> > > >>> > > >> > > >>> IMHO, if it's a choice between infra load and better performance > > >> > > >>> in the end product, performance should win out. > > >> > > >> > > >> > > >> I agree, infrastructure load is not relevant to this conversation. > > >> > > >> There are tons of other ways to improve that besides disabling PGO. > > >> > > >> > > >> > > >> Cheers, > > >> > > >> Ehsan > > > > > > I'm weighing in a little late here, but from the JS team's perspective, PGO > > is a nightmare. It introduces subtle compiler bugs (often topcrashes) that > > are extremely difficult to track down. We end up littering the codebase > > with de-PGO hints. To date I have yet to see a PGO-only crash that > > manifests in the JS engine, that was not directly caused by PGO. > > > > > > Related, I don't think MOZ_LIKELY/UNLIKELY are either a good idea or would > > cover the PGO gap. PGO does way more than just branch prediction, it has > > all sorts of speculative partial inlining and register allocation tricks. > > (That, unfortunately, are buggy.) > > > > > > Anyway, disabling PGO is music to my ears - I'd bet money that our overall > > crash-stats will improve. > > > > As I explained in my first email, this thread does not cover PGO in the > > JS engine. > > > > Cheers, > > Ehsan
I have debugged such crashes outside of JS too. I expect PGO to be unstable everywhere. -David _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
