Re: Use of MOZ_ARRAY_LENGTH for static constants?

[Neil]

Ehsan Akhgari wrote:

Wanting faster debug builds is a good thing.  I doubt that the subject 
of this thread will give you those though.  :-)


My suggestions: first, build with --enable-debug --enable-optimize.  
If that is still slow enough, try profiling the build and see what 
jumps at you as the biggest costly things we do, and file bugs about them.


I've come up with a new compromise: --disable-debug --disable-optimize. 
That way, I can still get readable stacks and variables, but I don't 
seem to get the full slowness of debug builds (e.g. bounds checking).


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of MOZ_ARRAY_LENGTH for static constants?

[Ehsan Akhgari]

On 2014-02-28, 6:05 AM, Neil wrote:

Ehsan Akhgari wrote:


does fixing this enable you dogfood debug builds?


I apologize, I think that came out snarky, it wasn't mean to be.  :-)


I'm not expecting it to be a magic bullet. Where do you suggest I start?


By profiling a debug build and see where we spend our time in in the 
workflows that are unacceptably important to you, and then filing bugs 
about them.  I have to admit that I have never been brave enough to 
dogfood debug builds myself as my daily browser, but if some people have 
been and builds today are too slow for them, we should definitely fix 
them!  I don't really know much about your workflow and which things in 
what websites are too slow to prevent you from using the builds, so 
gathering some profiling information would be very helpful for people to 
find out where they can help.


The Gecko Profiler should be able to do a decent job at that, and it 
enables you to upload the profiles so that others can look at them, 
please see 
 
if you have never used it before.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of MOZ_ARRAY_LENGTH for static constants?

[Neil]

Ehsan Akhgari wrote:


does fixing this enable you dogfood debug builds?


I'm not expecting it to be a magic bullet. Where do you suggest I start?

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of MOZ_ARRAY_LENGTH for static constants?

[Ehsan Akhgari]

On 2014-02-27, 7:40 AM, Neil wrote:

On 2014-02-24, 1:25 PM, Chris Peterson wrote:


To avoid developers and reviewers from having to remember special
cases, maybe MOZ_ARRAY_LENGTH should just be the standard everywhere.


They're not quivalent.


Would you mind xpanding on that?


Sure.  mozilla::ArrayLength has a special case for mozilla::Array


That's readily fixed.

template 
char (&ArrayLengthHelper(const Array , N >& arr
ay))[N];

Want me to file a bug?


Sure.

But again, does fixing this enable you dogfood debug builds?

Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of MOZ_ARRAY_LENGTH for static constants?

[Neil]

Ehsan Akhgari wrote:


On 2014-02-26, 4:52 AM, Neil wrote:

The one that I spotted is that MSVC is unable to optimise static 
variables, e.g. when you write static const length = 
ArrayLength(array); If you write this as a local then the compiler is 
able to optimise it away in release builds.


So you mean the problematic cases happen when that variable is at a 
global scope or something?


Doesn't have to be at global scope, could be static function scope (in 
which case you get a static constructor... at least at global scope it 
manages to optimise that away).


Note that I don't think that we need to care about the performance 
of ArrayLength() in non-optimized builds.


Debug builds are now sufficiently slow that I no longer dogfood them, 
but as it happens MSVC is able to optimise MOZ_ARRAY_LENGTH in both 
opt and debug builds.


Wanting faster debug builds is a good thing.  I doubt that the subject 
of this thread will give you those though.  :-)


Well, it was low-hanging fruit.


My suggestions: first, build with --enable-debug --enable-optimize.


That results in an undebuggable build, as the debugger won't be able to 
examine most variables, which rather defeats the object of debugging.



On 2014-02-24, 1:25 PM, Chris Peterson wrote:

To avoid developers and reviewers from having to remember special 
cases, maybe MOZ_ARRAY_LENGTH should just be the standard everywhere.


They're not quivalent.


Would you mind xpanding on that?


Sure.  mozilla::ArrayLength has a special case for mozilla::Array


That's readily fixed.

template 
char (&ArrayLengthHelper(const Array , N >& arr 
ay))[N];


Want me to file a bug?

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of MOZ_ARRAY_LENGTH for static constants?

[Ehsan Akhgari]

On 2014-02-26, 4:52 AM, Neil wrote:

Ehsan Akhgari wrote:


On 2/23/14, 4:05 PM, Neil wrote:


Both ArrayLength and MOZ_ARRAY_LENGTH are typesafe when compiled as
C++, however ArrayLength has the disadvantage that it's not a
constant expression in MSVC. In unoptimised builds this is direly
slow as the templated function does not even get inlined, but even in
optimised builds the MSVC compiler is unable to completely optimise
away static variables. In particular, the variable is treated as if
it is forward-declared: the value is fetched from memory in each
function that uses it. (In my simple test there were enough registers
to avoid fetching the value more than once, but I don't know what
happens if this is not the case. And at least the optimiser was able
to avoid creating any static constructors.) Would it therefore be
preferable to use MOZ_ARRAY_LENGTH in such cases?


Which cases are those exactly?


The one that I spotted is that MSVC is unable to optimise static
variables, e.g. when you write static const length = ArrayLength(array);
If you write this as a local then the compiler is able to optimise it
away in release builds.


So you mean the problematic cases happen when that variable is at a 
global scope or something?



Note that I don't think that we need to care about the performance of
ArrayLength() in non-optimized builds.


Debug builds are now sufficiently slow that I no longer dogfood them,
but as it happens MSVC is able to optimise MOZ_ARRAY_LENGTH in both opt
and debug builds.


Wanting faster debug builds is a good thing.  I doubt that the subject 
of this thread will give you those though.  :-)


My suggestions: first, build with --enable-debug --enable-optimize.  If 
that is still slow enough, try profiling the build and see what jumps at 
you as the biggest costly things we do, and file bugs about them.



On 2014-02-24, 1:25 PM, Chris Peterson wrote:


To avoid developers and reviewers from having to remember special
cases, maybe MOZ_ARRAY_LENGTH should just be the standard everywhere.


They're not quivalent.


Would you mind xpanding on that?


Sure.  mozilla::ArrayLength has a special case for mozilla::Array 
.


Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of MOZ_ARRAY_LENGTH for static constants?

[Neil]

Ehsan Akhgari wrote:


On 2/23/14, 4:05 PM, Neil wrote:

Both ArrayLength and MOZ_ARRAY_LENGTH are typesafe when compiled as 
C++, however ArrayLength has the disadvantage that it's not a 
constant expression in MSVC. In unoptimised builds this is direly 
slow as the templated function does not even get inlined, but even in 
optimised builds the MSVC compiler is unable to completely optimise 
away static variables. In particular, the variable is treated as if 
it is forward-declared: the value is fetched from memory in each 
function that uses it. (In my simple test there were enough registers 
to avoid fetching the value more than once, but I don't know what 
happens if this is not the case. And at least the optimiser was able 
to avoid creating any static constructors.) Would it therefore be 
preferable to use MOZ_ARRAY_LENGTH in such cases?


Which cases are those exactly? 


The one that I spotted is that MSVC is unable to optimise static 
variables, e.g. when you write static const length = ArrayLength(array); 
If you write this as a local then the compiler is able to optimise it 
away in release builds.


Note that I don't think that we need to care about the performance of 
ArrayLength() in non-optimized builds.


Debug builds are now sufficiently slow that I no longer dogfood them, 
but as it happens MSVC is able to optimise MOZ_ARRAY_LENGTH in both opt 
and debug builds.



On 2014-02-24, 1:25 PM, Chris Peterson wrote:

To avoid developers and reviewers from having to remember special 
cases, maybe MOZ_ARRAY_LENGTH should just be the standard everywhere.


They're not quivalent.


Would you mind xpanding on that?

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of MOZ_ARRAY_LENGTH for static constants?

[Ehsan Akhgari]

On 2014-02-24, 1:25 PM, Chris Peterson wrote:

On 2/23/14, 4:05 PM, Neil wrote:

Both ArrayLength and MOZ_ARRAY_LENGTH are typesafe when compiled as C++,
however ArrayLength has the disadvantage that it's not a constant
expression in MSVC. In unoptimised builds this is direly slow as the
templated function does not even get inlined, but even in optimised
builds the MSVC compiler is unable to completely optimise away static
variables. In particular, the variable is treated as if it is
forward-declared: the value is fetched from memory in each function that
uses it. (In my simple test there were enough registers to avoid
fetching the value more than once, but I don't know what happens if this
is not the case. And at least the optimiser was able to avoid creating
any static constructors.) Would it therefore be preferable to use
MOZ_ARRAY_LENGTH in such cases?


Which cases are those exactly?  Note that I don't think that we need to 
care about the performance of ArrayLength() in non-optimized builds.



To avoid developers and reviewers from having to remember special cases,
maybe MOZ_ARRAY_LENGTH should just be the standard everywhere.


They're not quivalent.

Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of MOZ_ARRAY_LENGTH for static constants?

[Chris Peterson]

On 2/23/14, 4:05 PM, Neil wrote:

Both ArrayLength and MOZ_ARRAY_LENGTH are typesafe when compiled as C++,
however ArrayLength has the disadvantage that it's not a constant
expression in MSVC. In unoptimised builds this is direly slow as the
templated function does not even get inlined, but even in optimised
builds the MSVC compiler is unable to completely optimise away static
variables. In particular, the variable is treated as if it is
forward-declared: the value is fetched from memory in each function that
uses it. (In my simple test there were enough registers to avoid
fetching the value more than once, but I don't know what happens if this
is not the case. And at least the optimiser was able to avoid creating
any static constructors.) Would it therefore be preferable to use
MOZ_ARRAY_LENGTH in such cases?


To avoid developers and reviewers from having to remember special cases, 
maybe MOZ_ARRAY_LENGTH should just be the standard everywhere.



chris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform