const local vs. member

Discussion in 'C++' started by Chris Forone, Apr 25, 2013.

  1. Chris Forone

    Chris Forone Guest

    hello group,

    what do you think/know is faster:

    Matrix& Matrix::Translate(GLfloat x, GLfloat y, GLfloat z)
    {
    const std::array<GLfloat, 16> translate =
    {
    1.0f, 0.0f, 0.0f, 0.0f,
    0.0f, 1.0f, 0.0f, 0.0f,
    0.0f, 0.0f, 1.0f, 0.0f,
    x, y, z, 1.0f
    };

    return *this *= translate;
    }

    or to use a second std::array<GLfloat, 16> member, clear it every call
    to Matrix::Translate and do the multiply.

    in other words: is to clear/set a member faster than to use a local
    temporary? the methode(s) is/are called very frequently!

    thanks!

    cheers, chris
    Chris Forone, Apr 25, 2013
    #1
    1. Advertising

  2. Chris Forone

    Öö Tiib Guest

    On Thursday, 25 April 2013 14:43:31 UTC+3, Chris Forone wrote:
    > hello group,
    >
    > what do you think/know is faster:
    >
    > Matrix& Matrix::Translate(GLfloat x, GLfloat y, GLfloat z)
    > {
    > const std::array<GLfloat, 16> translate =
    > {
    > 1.0f, 0.0f, 0.0f, 0.0f,
    > 0.0f, 1.0f, 0.0f, 0.0f,
    > 0.0f, 0.0f, 1.0f, 0.0f,
    > x, y, z, 1.0f
    > };
    >
    > return *this *= translate;
    > }
    >
    > or to use a second std::array<GLfloat, 16> member, clear it every call
    > to Matrix::Translate and do the multiply.
    >
    > in other words: is to clear/set a member faster than to use a local
    > temporary? the methode(s) is/are called very frequently!


    On that case the most efficient method is to *write* the Translate and
    not to use some generic multiplication operation. Most multiplications
    that will be done are with zeroes and ones. That is pointless
    performance hole if you call it very frequently.

    > thanks!


    n.p. h.t.h.
    Öö Tiib, Apr 25, 2013
    #2
    1. Advertising

  3. Chris Forone

    Guest

    Hi Chris!

    On Thursday, April 25, 2013 7:43:31 AM UTC-4, Chris Forone wrote:
    > hello group,
    >
    > what do you think/know is faster:
    >
    > Matrix& Matrix::Translate(GLfloat x, GLfloat y, GLfloat z)
    > {
    > const std::array<GLfloat, 16> translate =
    > {
    > 1.0f, 0.0f, 0.0f, 0.0f,
    > 0.0f, 1.0f, 0.0f, 0.0f,
    > 0.0f, 0.0f, 1.0f, 0.0f,
    > x, y, z, 1.0f
    > };
    > return *this *= translate;
    > }


    First off, as Öö said, doing the translation "by hand,"
    rather than performing matrix multiplication with your
    augmented identity matrix will be much faster.

    > or to use a second std::array<GLfloat, 16> member, clear it every call
    > to Matrix::Translate and do the multiply.
    >
    > in other words: is to clear/set a member faster than to use a local
    > temporary? the methode(s) is/are called very frequently!


    To answer your specific question, I think your two approaches,
    the local const with which you use initialization syntax, and
    the local temporary that you presumably initialize procedurally,
    are really the same in terms of what the compiler will do.

    In both cases there is a temporary on the stack, the compiler
    has to set it to the identity plus the translation vector, and
    then call your Matrix::eek:perator*=.

    My bet is -- unless you or the compiler does something very
    wacky or very clever -- you would get the exact same code in
    both cases.

    Stylistically, given that for the purposes of this function,
    your matrix translate is a constant and has an easy to
    understand initialization, I like the first approach.

    But, as as Öö pointed out, the full-blown matrix multiplication
    is inefficient overkill for the case in point of a pure
    translation.

    > thanks!
    > cheers, chris


    Good luck.


    K. Frank
    , Apr 25, 2013
    #3
  4. On 4/25/2013 6:43 AM, Chris Forone wrote:
    > hello group,
    >
    > what do you think/know is faster:
    >
    > Matrix& Matrix::Translate(GLfloat x, GLfloat y, GLfloat z)
    > {
    > const std::array<GLfloat, 16> translate =
    > {
    > 1.0f, 0.0f, 0.0f, 0.0f,
    > 0.0f, 1.0f, 0.0f, 0.0f,
    > 0.0f, 0.0f, 1.0f, 0.0f,
    > x, y, z, 1.0f
    > };
    >
    > return *this *= translate;
    > }
    >
    > or to use a second std::array<GLfloat, 16> member, clear it every call
    > to Matrix::Translate and do the multiply.
    >
    > in other words: is to clear/set a member faster than to use a local
    > temporary? the methode(s) is/are called very frequently!
    >
    > thanks!
    >
    > cheers, chris



    OT
    Why would you want to implement your own 3D matrix for OpenGL?
    I am sure a billion people have already done it for you in a library
    somewhere.

    If it is to learn, then OK. If it is for a project you want to have come
    to realization, I am always of the opinion that one should implement as
    little as possible, so they have as little as possible to maintain, as
    long as the selected alternative is widely used, tested, and documented.
    In this case, I do believe a 3D matrix would fall into that category :)

    I just say this, because I constantly work with people who want to
    implement their own linked lists, their own maps, their own loggers,
    their own XML parsers, and I get to spend 95% of my time debugging their
    code and only 5% making my own bugs. When a project has a backlog of
    defects long enough to last a 20 person team a lifetime, one has to ask,
    why did you write all of this code that is already available and tested
    for you!

    Sorry to rant :)
    Christopher Pisz, Apr 25, 2013
    #4
  5. On 4/25/2013 6:57 PM, Christopher Pisz wrote:
    > [...] When a project has a backlog of
    > defects long enough to last a 20 person team a lifetime, one has to ask,
    > why did you write all of this code that is already available and tested
    > for you!
    >
    > Sorry to rant :)


    I think actions like that should be attributed in part to the sense of
    superiority some people have (believing that they can do it better than
    anyone else, or at least most anyone else) and in part to a severe case
    of distrust ("<gasp> there can be bugs in those third-party libraries
    and components! who's going to fix those, and how?!") At the same
    time, sadly, it's the sign of utter immaturity of the development group.
    Imagine that shoemakers would start by skinning the animals and
    tanning the hides themselves...

    V
    --
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Apr 26, 2013
    #5
  6. Chris Forone

    Chris Forone Guest

    thanks guys for the answers. writing c++/opengl software is a hobby of
    mine, i spent only short time in that. so i write my own pieces of sw to
    learn how it works (how other libs possibly work). its some kind of
    experimenting and comparing different approaches. i use opengl to better
    SEE what happens. and i have no plans to publish the work.

    cheers, chris
    Chris Forone, Apr 26, 2013
    #6
  7. Chris Forone

    James Kanze Guest

    On Friday, April 26, 2013 12:27:40 AM UTC+1, Victor Bazarov wrote:
    > On 4/25/2013 6:57 PM, Christopher Pisz wrote:
    > > [...] When a project has a backlog of
    > > defects long enough to last a 20 person team a lifetime, one has to ask,
    > > why did you write all of this code that is already available and tested
    > > for you!


    > > Sorry to rant :)


    > I think actions like that should be attributed in part to the sense of
    > superiority some people have (believing that they can do it better than
    > anyone else, or at least most anyone else) and in part to a severe case
    > of distrust ("<gasp> there can be bugs in those third-party libraries
    > and components! who's going to fix those, and how?!")


    The distrust is probably justified. Third party librarys fall
    into three categories:

    - Well written. These are very, very rare. In fact, the only
    one I have actually used (not really a library, but) is the
    Python interpreter (despite being written in C).

    - Not necessarily well written, but widely used, so you can
    pretty much count on most bugs having been caught by some
    previous user, and already fixed. You're almost certainly
    using some of these now: Linux would be an example, and
    although I've not seen the source code to confirm it, the
    history of Solaris and Windows makes me think that they are
    also in this category. While the code certainly wouldn't
    meet the quality requirements of any serious company, there
    have been enough victimes before you that any major errors
    have probably been seen and fixed. (Most of Boost also
    falls into this category, although unlike many other
    providers, they do seem to at least test the libraries before
    delivering them.)

    - Junk.

    As it happens, most third party software (open source or not)
    falls into the last category. For reasons that escape me, most
    organizations which know how to write quality software are
    delivering complete systems, and not libraries.

    > At the same
    > time, sadly, it's the sign of utter immaturity of the development group.
    > Imagine that shoemakers would start by skinning the animals and
    > tanning the hides themselves...


    Imagine that the people skinning the animals and tanning the
    hides did it as poorly as most third party software deliverers.

    --
    James
    James Kanze, Apr 27, 2013
    #7
  8. Chris Forone

    Ian Collins Guest

    Victor Bazarov wrote:
    > On 4/25/2013 6:57 PM, Christopher Pisz wrote:
    >> [...] When a project has a backlog of
    >> defects long enough to last a 20 person team a lifetime, one has to ask,
    >> why did you write all of this code that is already available and tested
    >> for you!
    >>
    >> Sorry to rant :)

    >
    > I think actions like that should be attributed in part to the sense of
    > superiority some people have (believing that they can do it better than
    > anyone else, or at least most anyone else) and in part to a severe case
    > of distrust ("<gasp> there can be bugs in those third-party libraries
    > and components! who's going to fix those, and how?!") At the same
    > time, sadly, it's the sign of utter immaturity of the development group.


    In some software, particularly medical devices that can cause death or
    serious injury, the regulatory burden for including third party
    libraries can be more trouble than it is worth.

    > Imagine that shoemakers would start by skinning the animals and
    > tanning the hides themselves...


    If you can't get the quality of materials yon need for the job...

    --
    Ian Collins
    Ian Collins, Apr 27, 2013
    #8
  9. Chris Forone

    Tony Guest

    In article <>, says...
    >
    > Victor Bazarov wrote:
    > > Imagine that shoemakers would start by skinning the animals and
    > > tanning the hides themselves...

    >
    > If you can't get the quality of materials yon need for the job...


    Or even the tools!
    Tony, Apr 28, 2013
    #9
  10. Chris Forone

    Guest

    On Saturday, April 27, 2013 9:03:27 PM UTC, James Kanze wrote:
    >
    > The distrust is probably justified. Third party librarys fall
    >
    > into three categories:
    >
    >
    >
    > - Well written. These are very, very rare. In fact, the only
    >
    > one I have actually used (not really a library, but) is the
    >
    > Python interpreter (despite being written in C).
    >
    >
    >
    > - Not necessarily well written, but widely used, so you can
    >
    > pretty much count on most bugs having been caught by some
    >
    > previous user, and already fixed. You're almost certainly
    >
    > using some of these now: Linux would be an example, and
    >
    > although I've not seen the source code to confirm it, the
    >
    > history of Solaris and Windows makes me think that they are
    >
    > also in this category. While the code certainly wouldn't
    >
    > meet the quality requirements of any serious company, there
    >
    > have been enough victimes before you that any major errors
    >
    > have probably been seen and fixed. (Most of Boost also
    >
    > falls into this category, although unlike many other
    >
    > providers, they do seem to at least test the libraries before
    >
    > delivering them.)
    >
    >
    >
    > - Junk.
    >
    >
    >
    > As it happens, most third party software (open source or not)
    >
    > falls into the last category. For reasons that escape me, most
    >
    > organizations which know how to write quality software are
    >
    > delivering complete systems, and not libraries.
    >
    >


    I don't think there's a good business model for
    C++ libraries these days. Years ago when the
    players were more ethical the traditional model
    worked. Is it surprising that you have to go
    to services? Is there another way?

    I took the systems route, but also have an
    open source library -
    http://webEbenezer.net/build_integration.html
    .. I believe the quality of the library is above
    average. I've whittled it down to around 4,100
    lines. About 1,000 of those lines are from a
    third-party compression library.


    Brian
    Ebenezer Enterprises - So far G-d has helped us.
    http://webEbenezer.net
    , Apr 29, 2013
    #10
  11. Chris Forone

    Guest

    On Sunday, April 28, 2013 9:57:03 PM UTC-5, wrote:
    >
    >
    > I don't think there's a good business model for
    >
    > C++ libraries these days. Years ago when the
    >
    > players were more ethical the traditional model
    >
    > worked. Is it surprising that you have to go
    >
    > to services? Is there another way?
    >
    >
    >


    And all the time—such is the tragi-comedy of our [educational]
    situation—we continue to clamour for those very qualities we
    are rendering impossible. You can hardly open a periodical
    without coming across the statement that our civilization
    needs more ‘drive’, or dynamism, or self-sacrifice, or
    ‘creativity’. In a sort of ghastly simplicity we remove the
    organ and demand the function. We make men without chests [hearts]
    and expect of them virtue and enterprise. We laugh at honour
    and are shocked to find traitors in our midst. We castrate and
    bid the geldings be fruitful.

    — C.S. Lewis, The Abolition of Man

    Brian
    Ebenezer Enterprises - If you can't join 'em, beat 'em.
    http://webEbenezer.net
    , Apr 30, 2013
    #11
  12. Chris Forone

    Öö Tiib Guest

    On Tuesday, 30 April 2013 12:43:46 UTC+3, Juha Nieminen wrote:
    > Chris Forone <> wrote:
    > > or to use a second std::array<GLfloat, 16> member, clear it every call
    > > to Matrix::Translate and do the multiply.

    >
    > In general, it's more efficient to use the stack (ie. function-local
    > objects) than some block of memory elsewhere (even if that block is
    > allocated only once and then operated on repeatedly.) The difference,
    > of course, depends on a ton of things, and is usually relatively small,
    > but measurable. It usually has to do with cache locality.


    Are you sure about that "only once" case? A static
    std::array<GLfloat, 16> that is reused by reassigning the 3 elements
    that change must be somewhat faster than function-local
    whose all elements are reinitialized a lot. I have varying experiences
    with thread-local instead of static however, that depends on implementation.
    Öö Tiib, Apr 30, 2013
    #12
  13. Am 25.04.2013 13:59, schrieb Öö Tiib:

    > On that case the most efficient method is to *write* the Translate and
    > not to use some generic multiplication operation. Most multiplications
    > that will be done are with zeroes and ones.


    I think you can assume the zeroes and ones to be optimized away when
    the multiplication-function/operator is inline.
    Gerald Breuer, May 1, 2013
    #13
  14. Chris Forone

    Öö Tiib Guest

    On Wednesday, 1 May 2013 03:31:03 UTC+3, Gerald Breuer wrote:
    > Am 25.04.2013 13:59, schrieb Öö Tiib:
    > > On that case the most efficient method is to *write* the Translate and
    > > not to use some generic multiplication operation. Most multiplications
    > > that will be done are with zeroes and ones.

    >
    > I think you can assume the zeroes and ones to be optimized away when
    > the multiplication-function/operator is inline.


    Have you any evidence of that? Multiplication of two 4x4 matrixes
    is 64 multiplications and 48 additions. Compilers often ignore inline
    keyword for functions that large, also they seem to optimize floating
    point arithmetics lot less than integer arithmetics.
    Öö Tiib, May 1, 2013
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    11
    Views:
    1,086
  2. Javier
    Replies:
    2
    Views:
    543
    James Kanze
    Sep 4, 2007
  3. 0m
    Replies:
    26
    Views:
    1,090
    Tim Rentsch
    Nov 10, 2008
  4. fungus
    Replies:
    13
    Views:
    871
    fungus
    Oct 31, 2008
  5. Replies:
    2
    Views:
    526
    Andrew Koenig
    Feb 9, 2009
Loading...

Share This Page