Why pass doubles as const references?

[Ian Collins]

Just use:

#include <type_traits>
#include "X.hpp" // your header that declares type X
static_assert( std::is_pod<X>::value && sizeof(X)<25
, "X must be POD and less than 25 bytes long!" );

For me such trivial stuff that is under 25 bytes long is fine to pass by
value, it is never show-stopper defect AND the performance issues are
elsewhere as rule.

So if someone adds a double to a common 24 byte long class, you have to
change a lot of code?

I agree with James, keep to the simple rules.

 

[Öö Tiib]

So if someone adds a double to a common 24 byte long class, you have to
change a lot of code?

No. There is always some budget for performance analyze and improvement
and if something matters then it will be changed, not because of few bytes here
or there.

In practice even passing say std::string by value is usually not affecting the
performance that much. It is not POD and it often is implemented bigger than
24 bytes. Reviewing that as anything more than low importance typo
is overestimation. Same is about bool passed by reference. Cost of it can
be measured; it is very low ... so significance is close to nonexistent.

I agree with James, keep to the simple rules.

I actually agree too. ;-) The whole complex rule of mine is good to know
when writing code generators or static analyze tools. Simple is better in
coding standard.

 

[Rui Maciel]

I'm not sure if you are being obtuse, an arse or a troll.

All I did was compile the code *you posted* with the *same compiler* you
used and post the results. I made no mention of any corner case. If
you make another attempt at reading the few simple words that appear to
be causing you trouble, you'll see I contradicted the assumption the
function were inlined. Just to help you out, I'll quote them again:

"The calls are still made, the function bodies are optimised."

There, do you get it now?

Ian,

I don't take you for a moron, but you aren't adding any confidence to that
assumption. Here's why.

Read the thread, and try to understand where and why I've posted the example
you've referred to. Here's a hint: if someone makes a baseless assertion
regarding how most likely something doesn't affect performance and a trivial
example is enough to show a significant performance penalty, even when
squeezing some implementation-dependent optimization tricks from a specific
compiler, as even you've showed with the tests you did yourself, then what
can you say about that baseless assertion?

Then, please try not to forget that every time you talk about any specific
compiler and any specific optimization trick it is able to pull on specific
types of functions being called in specific ways, you are talking about
corner cases which are implementation dependent. You simply can't
extrapolate the results of your corner cases to C++, as defined in the
standard. If you believe you can then simply think about this: why does the
C++ standard specifies that when a function is declared with the inline
specifier, all compilers are free to ignore that hint? In other words, why
are you expecting that all C++ compilers inline functions which aren't
declared to be inline if it isn't even possible to expect that any compiler
will inline a function specifically declared to be inlined?

Finally, if you feel compelled to throw a string of insults at others you
disagree with, maybe it's time to spend a moment or to to think about what
you are doing and what you are saying.


Rui Maciel

 

[Rui Maciel]

I think passing one or more arrays of doubles in references or addresses
for numeric computations is the default way in heavy number crunching
jobs.

Arrays yes, but scalar values that aren't supposed to change tend to be
passed by value. As an example, take AXPY-type calls[1].


Rui Maciel

[1] http://www.gnu.org/software/gsl/manual/html_node/Level-1-GSL-BLAS-
Interface.html

 

[Öö Tiib]

Here's a hint: if someone makes a baseless assertion
regarding how most likely something doesn't affect performance and a trivial
example is enough to show a significant performance penalty, even when
squeezing some implementation-dependent optimization tricks from a specific
compiler, as even you've showed with the tests you did yourself, then what
can you say about that baseless assertion?

Here's a counter hint: I have seen tens of claims that iterating over array
with pointer is cheaper and vector's iterators have penalty. With debug build
(that adds unneeded instructions) measurement as "proof". Yours "example"
was not better. Same problem.

Usually the people making such claims are newbies and later understand
and admit their error. You can't. You still stand firmly in your "logic" and
claim that there is some black magic of optimizations. No one measures
performance of debug builds. Whole standard library is tens of times less
efficient in not optimized builds. Standard library would be terribly wrong
thing to use by your logic.

Stop demonstrating that lack of ability to learn. That is hard to believe that
software developer can be devoid of ability to learn and so it, yes, feels like
trolling.

 

[Ian Collins]

Ian,

I don't take you for a moron, but you aren't adding any confidence to that
assumption. Here's why.

Read the thread, and try to understand where and why I've posted the example
you've referred to. Here's a hint: if someone makes a baseless assertion
regarding how most likely something doesn't affect performance and a trivial
example is enough to show a significant performance penalty, even when
squeezing some implementation-dependent optimization tricks from a specific
compiler, as even you've showed with the tests you did yourself, then what
can you say about that baseless assertion?

Let's get one thing straight: all I did was post the result of a
compilation with a basic level of optimisation that *does not* inline
functions. I did this because comparing the performance of unoptimised
code is pointless. I made it very clear in subsequent posts that there
wasn't any inlining. I even went as far as posting the generated
assembly code. You then accused me of forgetfulness and dishonesty:

"Or did you already forgot that you are talking about a very specific
corner case, [which I had excluded] where you were only able to
fabricate [which I certainly didn't] the result you intended by forcing
a specific compiler to optimize a specific function in a very specific
way, [which I hadn't, another compiler produced identical results] and
even then you had to do at least 3 separate attempts? [I used the same
compiler and options as you as a baseline to provide context]"

After all that, I thought my response was rather restrained.

Then, please try not to forget that every time you talk about any specific
compiler and any specific optimization trick it is able to pull on specific
types of functions being called in specific ways, you are talking about
corner cases which are implementation dependent. You simply can't
extrapolate the results of your corner cases to C++, as defined in the
standard. If you believe you can then simply think about this: why does the
C++ standard specifies that when a function is declared with the inline
specifier, all compilers are free to ignore that hint? In other words, why
are you expecting that all C++ compilers inline functions which aren't
declared to be inline if it isn't even possible to expect that any compiler
will inline a function specifically declared to be inlined?

Where did I express such an expectation? I most certainly wouldn't use
a compiler that didn't inline the likes of std::vector's operator[]
(would you?) and I would (and have in the past) go as far as calling
that a serious bug. But I didn't introduce function inlining into this
discussion, so the point is moot.

Finally, if you feel compelled to throw a string of insults at others you
disagree with, maybe it's time to spend a moment or to to think about what
you are doing and what you are saying.

They weren't insults, just observations. I don't like being accused of
saying things I didn't say and being dishonest.

 

[Jorgen Grahn]

]
Just use:

#include <type_traits>
#include "X.hpp" // your header that declares type X
static_assert( std::is_pod<X>::value && sizeof(X)<25
, "X must be POD and less than 25 bytes long!" );

For me such trivial stuff that is under 25 bytes long is fine to pass by
value, it is never show-stopper defect AND the performance issues are
elsewhere as rule.

Why be so complicated? The usual rule (at least everywhere I've
been) is "class types by const reference, everything else by
value". There are a few obvious exceptions [...]

I don't like the rule, because it cements the idea that class types
are big things. A lot of the time, things which would be an unsigned
char or an int in a C program, is better given its own type in C++,
even if it's in the critical path. Say, an IP address or a pixel in a
bitmapped image, or one of a hundred different tiny IE types in a
telecoms standard.

But I don't think the complication is needed, either. Usually it's
obvious what's small and what's not, and as you both say:

and as you say, the performance issues are generally elsewhere

/Jorgen