[cfe-dev] Proposed C++ optimization with big speed gains with big objects

Ronan Keryell Ronan.Keryell at silkan.com
Wed Sep 26 16:24:08 PDT 2012


>>>>> On Wed, 26 Sep 2012 01:47:41 -0700 (PDT), Ladislav Nevery <neuralll at gmail.com> said:

    Ladislav> Now about how relevant is this previous object state when
    Ladislav> exceptions start flying around from constructors ?

    Ladislav> statistically 99% of exception in constructor will happen
    Ladislav> due to memory exhaustion(we are allready doomed) .
    Ladislav> statistically 99% of member pointers in code around you
    Ladislav> were not smart pointers (we are allready doomed)

    Ladislav> So I think it shall be tested since advantages massively
    Ladislav> outweight pretty much hypotetical disadvantages.

This is a side effect of the tyranny of democracy. :-)

So, if you want to do this kind of optimization with soundness, you will
have to program some complex interprocedural analysis, that will be
often intractable anyway. :-(

So, before setting yet-another-religion war, why not considering a
perfect use case for some #pragma ?

- you want to solve an issue ?

- this is too complex to figure out in general ?

- but the programmer knows when it does apply...

- insert the #pragma (may be in one of the constructor declaration ?)

You just have to launch your optimization when the pragma is set.


>From the norm:

16.6 Pragma directive [cpp.pragma]

A preprocessing directive of the form
  # pragma pp-tokensopt new-line
causes the implementation to behave in an implementation-defined manner. The behavior might cause
translation to fail or cause the translator or the resulting program to behave in a non-conforming manner.
Any pragma that is not recognized by the implementation is ignored.



So the last sentence is fine.
If your compiler do not deal with your optimization, that is not worse
than before.

Please, choose a sensible name-space for the pragma to avoid
conflicts. :-)
(I am traumatized by the #pragma simd or #pragma vector found in the
compiler from a well-known processor vendor and others :-( ).

-- 
  Ronan KERYELL                            |\/  Phone:  +1 408 658 9453
  SILKAN Wild Systems                      |/)
  4962 El Camino Real #201                 K    Ronan.Keryell at silkan.com
  Los Altos, CA 94022                      |\   skype:keryell
  USA                                      | \  http://silkan.com



More information about the cfe-dev mailing list