From bool to int: 1 or 0

[Frederick Gotham]

If I wanted a super-efficient algorithm for counting the amount of 6's in
an array, (given the address of the first element and the amount of
elements), I might start off with:

#include <cstddef>

unsigned AmountSixes( const int *p, std::size_t const len )
{
unsigned amount = 0;

const T* const p_over = array + len;

do
{
if( *p++ == 6 ) ++amount;
}
while ( p != p_over );

return amount;
}
However, by my own coding style, I'd probably change the loop to:

do
{
amount += (*p++ == 6);
} while ( p != p_over );
This would rely on the bool to int conversion which would yield 1 or 0.

Any thoughts on which would be likely to be more efficient on the
majority of architectures if I was writing fully portable code to be used
on everything from a wristwatch to a personal computer?


--

Frederick Gotham

[Victor Bazarov]

Frederick Gotham wrote:

If I wanted a super-efficient algorithm for counting the amount of
6's in an array, (given the address of the first element and the
amount of elements), I might start off with:
Or you might use 'std::count'...

#include <cstddef>

unsigned AmountSixes( const int *p, std::size_t const len )
{
unsigned amount = 0;

const T* const p_over = array + len;

do
{
if( *p++ == 6 ) ++amount;
}
while ( p != p_over );

return amount;
}
However, by my own coding style, I'd probably change the loop to:

do
{
amount += (*p++ == 6);
} while ( p != p_over );
Why bother when there is 'std::count'? :-)
This would rely on the bool to int conversion which would yield 1 or
0.
It does.
Any thoughts on which would be likely to be more efficient on the
majority of architectures if I was writing fully portable code to be
used on everything from a wristwatch to a personal computer?

return std::count(p, p + len, 6)

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Frederick Gotham]

Victor Bazarov posted:

return std::count(p, p + len, 6)

Thanks for the input, Victor. Checking for the quantity of instances of a
particular elemental value was just an example.

The main point of my post was to discuss which of the following two
approaches would be preferable in everyday programming:

if( *p++ == 6 ) ++amount;

or:

amount += (*p++ == 6);

--

Frederick Gotham

[Noah Roberts]

Frederick Gotham wrote:

Victor Bazarov posted:

return std::count(p, p + len, 6)

Thanks for the input, Victor. Checking for the quantity of instances of a
particular elemental value was just an example.

The main point of my post was to discuss which of the following two
approaches would be preferable in everyday programming:

if( *p++ == 6 ) ++amount;

or:

amount += (*p++ == 6);

In an effort to say what you mean I prefer the former; it says exactly
what is intended. The later is more cryptic and full of trickery. The
fact that you have to ask only proves the point.

[mlimber]

Frederick Gotham wrote:

The main point of my post was to discuss which of the following two
approaches would be preferable in everyday programming:

if( *p++ == 6 ) ++amount;

or:

amount += (*p++ == 6);

I would say the former since it is more readable and likely of
negligible performance difference. The meaning of the first is obvious
even to a junior programmer, while one must decode the second, and
programmers have enough to worry about without trying to determine if
an unnecessarily clever statement like that is causing problems.

Cheers! --M

[Frederick Gotham]

In response to both Noah and mlimber,

I am not at all bothered with whether one form is easier to understand
than the other -- I am solely concerned with performance.

If I wanted to simplify it, I could write a macro or a template function.

I suppose I could rephrase my question as follows:

Which of the following two macros would be preferable (performance-wise)
for use in portable code?:
#define IncrementIfTrue (amount,true_or _false)\
{ amount += static_cast<boo l>( true_or_false ); }
#define IncrementIfTrue (amount,true_or _false)\
{ if ( true_or_false ) ++amount; }
To be used as follows:

#include <cstddef>

unsigned AmountSixes( const int *p, std::size_t const len )
{
unsigned amount = 0;

const T* const p_over = array + len;

do
{
IncrementIfTrue ( amount, *p++ == 6 );
}
while ( p != p_over );

return amount;
}
--
Frederick Gotham

[Frederick Gotham]

#define IncrementIfTrue (amount,true_or _false)\
{ amount += static_cast<boo l>( true_or_false ); }

I must admit that I'm slightly unsure as to whether this will be as
efficient as I think it will. I wonder if the compiler would treat it
something like:

#define IncrementIfTrue (amount,true_or _false)\
{ amount += ( true_or_false ? 1 : 0 ); }
This might even be more costly than a simple "if" statment... Would it?

--

Frederick Gotham

[Victor Bazarov]

Frederick Gotham wrote:

#define IncrementIfTrue (amount,true_or _false)\
{ amount += static_cast<boo l>( true_or_false ); }

I must admit that I'm slightly unsure as to whether this will be as
efficient as I think it will. I wonder if the compiler would treat it
something like:

#define IncrementIfTrue (amount,true_or _false)\
{ amount += ( true_or_false ? 1 : 0 ); }
This might even be more costly than a simple "if" statment... Would
it?

Might. Or might not. If you are "solely concerned with performance",
measure it, don't guess. However, I bet that when the entire program
is measured, the difference between the two methods is going to be
negligible.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[mlimber]

Frederick Gotham wrote:

In response to both Noah and mlimber,

I am not at all bothered with whether one form is easier to understand
than the other -- I am solely concerned with performance.
Different compilers (and optimizers!) will produce different code, and
some CPU architectures and memory/cache configurations may do some
things more efficiently than others. So there's really no way to
determine which is faster in general. You could use a profiler on your
particular system to see which is faster on that system, but I strongly
suspect you're barking up the old "premature optimization" tree (see,
e.g., "Beware Premature Optimization" in
http://www.gotw.ca/publications/mill09.htm).

If I wanted to simplify it, I could write a macro or a template function.

I suppose I could rephrase my question as follows:

Which of the following two macros would be preferable (performance-wise)
for use in portable code?:
#define IncrementIfTrue (amount,true_or _false)\
{ amount += static_cast<boo l>( true_or_false ); }
#define IncrementIfTrue (amount,true_or _false)\
{ if ( true_or_false ) ++amount; }
To be used as follows:

#include <cstddef>

unsigned AmountSixes( const int *p, std::size_t const len )
{
unsigned amount = 0;

const T* const p_over = array + len;

do
{
IncrementIfTrue ( amount, *p++ == 6 );
}
while ( p != p_over );

return amount;
}

First of all, macros should be avoided when possible because of all
their "issues" (see
http://www.parashift.com/c++-faq-lit....html#faq-9.5).

Second, using a macro or inline function or your clever code here just
obfuscates your meaning again. Write code for humans, not the CPU (let
the compiler/optimizer worry about that!), until you have measured (not
intuited!) that hand optimizing would be of significant benefit.

Cheers! --M

[Noah Roberts]

Frederick Gotham wrote:

In response to both Noah and mlimber,

I am not at all bothered with whether one form is easier to understand
than the other -- I am solely concerned with performance.
http://www.flounder.com/optimization.htm
http://en.wikipedia.org/wiki/Optimiz...en_to_optimize

Since you are asking about the performance of these different methods I
must assume you have NOT gathered data yet.
Which of the following two macros would be preferable (performance-wise)
for use in portable code?:
#define IncrementIfTrue (amount,true_or _false)\
{ amount += static_cast<boo l>( true_or_false ); }
#define IncrementIfTrue (amount,true_or _false)\
{ if ( true_or_false ) ++amount; }

Without data I can only guess. My guess is on the later. Reasons:

* In the former the addition is always performed.
* The former requires the loading and addition of two registers, the
later does not.
* The former requires a cast.
* The former requires an additional assignment.

Now, the compiler could eliminate all those differences. The compiler
will have an easier time figuring out how to optimize when the code is
easier to interpret. The compiler was written by a human, therefor
things a human finds easier to interpret are more likely programmed
into the compiler's logic.

Stop trying to second guess your compiler before you even start.
Chances are very high that you are not smarter than the people that
wrote it. By trying to outwhit the experts you are more likely than
not to hinder the compiler's ability to optimize for you.