Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   const local vs. member (http://www.velocityreviews.com/forums/t960115-const-local-vs-member.html)

 Chris Forone 04-25-2013 11:43 AM

const local vs. member

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 04-25-2013 11:59 AM

Re: const local vs. member

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.

 kfrank29.c@gmail.com 04-25-2013 01:01 PM

Re: const local vs. member

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!

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

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 04-25-2013 10:57 PM

Re: const local vs. member

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

 Victor Bazarov 04-25-2013 11:27 PM

Re: const local vs. member

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

 Chris Forone 04-26-2013 06:12 AM

Re: const local vs. member

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 04-27-2013 09:03 PM

Re: const local vs. member

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

 Ian Collins 04-27-2013 09:44 PM

Re: const local vs. member

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

 Tony 04-28-2013 10:07 AM

Re: const local vs. member

In article <au2v6aF3bn2U1@mid.individual.net>, ian-news@hotmail.com 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!

 woodbrian77@gmail.com 04-29-2013 02:57 AM

Re: const local vs. member

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

All times are GMT. The time now is 05:07 PM.