Re: Quantum Flow Engineering Newsletter #9

[Chris Peterson]

On 2017-05-12 9:55 AM, Ehsan Akhgari wrote:

This reminded me of
https://bugzilla.mozilla.org/show_bug.cgi?id=1332680 (and
https://bugzilla.mozilla.org/show_bug.cgi?id=1332682 )

Adding -Wsuggest-final-types and -Wsuggest-final-methods and looking
at the output seems pretty low-effort to find a lot of more
opportunities for this. (Unless I'm misunderstanding things).

Plus, it benefits security!

Yes, this is indeed a good point.  Even though this will really only
have a measurable impact on performance if the functions are called in
hot code, it seems like a shame to not listen to the compiler when it
tells you I could make your code faster if you added this keyword in a
bunch of places.  :-)


Should the Mozilla Coding Style document recommend that all new classes 
use `final` unless they are designed to be derived? It would be a good 
habit even for simple classes that don't derive from a base class.


Also, Herb Sutter recommends [1] that all base classes should either 
have a public virtual destructor or protected non-virtual destructor. 
This prevents the problem where a derived class's non-virtual destructor 
doesn't get called if the object is deleted through a pointer to a base 
class.


So all classes would either:

- be a final class,
- have a public virtual destructor, or
- have a protected non-virtual dtor (possibly an empty inline dtor)


[1] http://www.gotw.ca/publications/mill18.htm
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Quantum Flow Engineering Newsletter #9

[Cameron Kaiser]

On 5/11/17 11:27 PM, Ehsan Akhgari wrote:


Jan de Mooij optimized Array.prototype.shit to have O(1) rather than
O(n) behavior .


Wow. That's an appropriately named function. ;)

Cameron Kaiser
tier-3 port, tier-1 heart

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

Re: Quantum Flow Engineering Newsletter #9

[Ehsan Akhgari]

On 05/12/2017 12:29 PM, Tom Ritter wrote:

On Fri, May 12, 2017 at 1:27 AM, Ehsan Akhgari  wrote:

I realized we haven't had a performance mini-story for a while -- I sort of
dropped the ball on that.  Running over this bug made me want to talk about
a pretty well known sort of slowness in C++ code, virtual functions.  The
cost of virtual functions comes from several different aspects, firstly they
effectively prevent the compiler from doing inlining the function which
enables a host of compiler optimizations, essentially by enabling the
compiler to see more of the code and optimize more effectively based on
that.  But then there is the runtime cost of the function, which mostly
comes from the indirect call.  The majority of the performance penalty here
on modern hardware is due to branch midpredictions when different
implementations of a virtual function get called at a call site.  You should
remember that on modern desktop processors, the cost of a branch
misprediction can be around 15-20 cycles (depending on the processor) so if
what your function does is very trivial and it has many overrides that can
be called in hot code chances are that you are spending a considerable
amount of time waiting for the instruction cache misses on the calls to the
virtual function in question.  Of course, finding which virtual functions in
your program are these expensive ones requires profiling the workloads you
care about improving, but always keep an eye for this problem as
unfortunately the object-oriented programming model in C++ really encourages
writing code like this.  This is the kind of issue that a native profiler is
probably more suitable for discovering, for example if you are using a
simple native sampling profiler these issues typically show up as a long
amount of time being spent on the first instruction of the virtual function
being called (which is typically an inexpensive instruction otherwise.)

This reminded me of
https://bugzilla.mozilla.org/show_bug.cgi?id=1332680 (and
https://bugzilla.mozilla.org/show_bug.cgi?id=1332682 )

Adding -Wsuggest-final-types and -Wsuggest-final-methods and looking
at the output seems pretty low-effort to find a lot of more
opportunities for this. (Unless I'm misunderstanding things).

Plus, it benefits security!
Yes, this is indeed a good point.  Even though this will really only 
have a measurable impact on performance if the functions are called in 
hot code, it seems like a shame to not listen to the compiler when it 
tells you I could make your code faster if you added this keyword in a 
bunch of places.  :-)

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

Re: Quantum Flow Engineering Newsletter #9

[Tom Ritter]

On Fri, May 12, 2017 at 1:27 AM, Ehsan Akhgari  wrote:
> I realized we haven't had a performance mini-story for a while -- I sort of
> dropped the ball on that.  Running over this bug made me want to talk about
> a pretty well known sort of slowness in C++ code, virtual functions.  The
> cost of virtual functions comes from several different aspects, firstly they
> effectively prevent the compiler from doing inlining the function which
> enables a host of compiler optimizations, essentially by enabling the
> compiler to see more of the code and optimize more effectively based on
> that.  But then there is the runtime cost of the function, which mostly
> comes from the indirect call.  The majority of the performance penalty here
> on modern hardware is due to branch midpredictions when different
> implementations of a virtual function get called at a call site.  You should
> remember that on modern desktop processors, the cost of a branch
> misprediction can be around 15-20 cycles (depending on the processor) so if
> what your function does is very trivial and it has many overrides that can
> be called in hot code chances are that you are spending a considerable
> amount of time waiting for the instruction cache misses on the calls to the
> virtual function in question.  Of course, finding which virtual functions in
> your program are these expensive ones requires profiling the workloads you
> care about improving, but always keep an eye for this problem as
> unfortunately the object-oriented programming model in C++ really encourages
> writing code like this.  This is the kind of issue that a native profiler is
> probably more suitable for discovering, for example if you are using a
> simple native sampling profiler these issues typically show up as a long
> amount of time being spent on the first instruction of the virtual function
> being called (which is typically an inexpensive instruction otherwise.)

This reminded me of
https://bugzilla.mozilla.org/show_bug.cgi?id=1332680 (and
https://bugzilla.mozilla.org/show_bug.cgi?id=1332682 )

Adding -Wsuggest-final-types and -Wsuggest-final-methods and looking
at the output seems pretty low-effort to find a lot of more
opportunities for this. (Unless I'm misunderstanding things).

Plus, it benefits security!

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