const local vs. member

[Chris Forone]

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

 

[Öö Tiib]

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.

 

[kfrank29.c]

Hi Chris!

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: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

 

[Christopher Pisz]

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

 

[Victor Bazarov]

[...] 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

 

[Chris Forone]

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

 

[James Kanze]

[...] 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.

 

[Ian Collins]

[...] 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...

 

[Tony]

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

Or even the tools!

 

[woodbrian77]

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

 

[woodbrian77]

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

 

[Öö Tiib]

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.

 

[Gerald Breuer]

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.

 

[Öö Tiib]

Am 25.04.2013 13:59, schrieb Öö Tiib:

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.