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
On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
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 enough in
On 01/31/2013 10:37 AM, Nicholas Nethercote wrote:
On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
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
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
Thanks to both,
this is a must have bit of functionality ..
for gadget based interfaces!
Zack Weinberg za...@panix.com 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
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
guimark2
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 and
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
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
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 means,
On 2013-01-31 3:37 AM, Nicholas Nethercote wrote:
On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
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
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.
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
- 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
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
(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
On Thu, Jan 31, 2013 at 4:42 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
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,
(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
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.
Therefore,
On Wed, Jan 30, 2013 at 8:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
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
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
On 2013-01-31 11:43 AM, Kyle Huey wrote:
On Wed, Jan 30, 2013 at 8:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
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
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
On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
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
On 2013-01-31 11:58 AM, Kyle Huey wrote:
On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
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
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.
On Thu, Jan 31, 2013 at 9:09 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On 2013-01-31 11:58 AM, Kyle Huey wrote:
On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhgari@gmail.**com ehsan.akhg...@gmail.com wrote:
On 2013-01-31 11:43 AM, Kyle Huey
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
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 ehsan.akhg...@gmail.com
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
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 za...@panix.com wrote in message
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 have
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/ 턂
On Thu, Jan 31, 2013 at 12:12 PM, Kyle Huey m...@kylehuey.com wrote:
On Thu, Jan 31, 2013 at 9:09 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On 2013-01-31 11:58 AM, Kyle Huey wrote:
On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhgari@gmail.**com
- 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:
On Thu, Jan 31, 2013 at 1:31 PM, L. David Baron dba...@dbaron.org 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
On 1/31/13 11:21 AM, L. David Baron wrote:
On Thu, Jan 31, 2013 at 1:31 PM, L. David Baron dba...@dbaron.org 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
On Jan 31, 12:04 pm, Chris Peterson cpeter...@mozilla.com wrote:
On 1/31/13 11:21 AM, L. David Baron wrote:
On Thu, Jan 31, 2013 at 1:31 PM, L. David Baron dba...@dbaron.org wrote:
Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY
meaningful on Windows (they currently
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.
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
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=nonedisplayrange=365datatype=running
Sunspider 2, Win7:
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
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
(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.
(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
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.
Profile
49 matches
Mail list logo
