Which if faster?

[Frederick Gotham]

Victor Bazarov posted:

Assumption is the mother of all f***-ups.

for (int i = 0; i < len; +i)
blah;

is not semantically equivalent to

int i = 0;
do
blah;
while (++i < len);

, that's all.

I make assumptions all the time -- I belive we call them "pre-conditions" in
the programming world. For instance, I can write an algorithm which deals
with an array, and say:

"The array must have at least two elements."

Then, if somebody gets bogus results when they supply it with either:

(1) A null pointer.
(2) An empty array (if there's such a thing).
(3) A sole-element array.

, then I'll just say tough luck. The C++ Standard seems to agree with me,
guess what happens when you supply "strlen" with a null pointer.

That said though, I do make liberal use of "assert".

 

[Gernot Frisch]

for (int i = 0; i < N; i++)
= ... a...

On most systems, the following is the fastest:

int *p = arr;
int const *const pover = arr+len;

do *p++ = ...
while (pover != p);

Even for N==0 ? :/

 

[Victor Bazarov]

Victor Bazarov posted:

Assumption is the mother of all f***-ups.

for (int i = 0; i < len; +i)
blah;

is not semantically equivalent to

int i = 0;
do
blah;
while (++i < len);

, that's all.

I make assumptions all the time -- I belive we call them
"pre-conditions" in the programming world. For instance, I can write
an algorithm which deals with an array, and say:

"The array must have at least two elements."
[..]
That said though, I do make liberal use of "assert".

Good. The code you posted didn't have any.

V

 

[Frederick Gotham]

Victor Bazarov posted:

Good. The code you posted didn't have any.

But "assert" isn't fool-proof (unless you decide to not define NDEBUG in
Release Mode).

 

[persenaama]

On most systems, the following is the fastest:

int *p = arr;
int const *const pover = arr+len;

do *p++ = ...
while (pover != p);

On systems which have a CPU instruction which takes both a pointer and an
offset, the following is fastest:

size_t i = 0;

do arr[i++] = ...
while (len != i);

Can you back those statements up with documentation?

As "int" is used there as the type the point is less relevant than when
something else is being used. Example:

mytype* p = ...;
p ... ++i
and..
*p++;

Have one major difference from the point of view of large number of
platforms. It's common to have somesort of
register+register*scale(+constant) addressing mode. This works nicely
when the scale can match the size of the type in question.

If however, say, the size isn't a power of two or for some other
practical reason not matching the scale supported by a particular
platform, the p implies multiplication (or efficient implementation
of multiplication by a constant), where as the p++ will imply ADDITION.

This is not really a C++ consideration and off-topic anyways, but a
practical consideration. Even so, I myself prefer the array indexing
over pointer dereference-and-increase. Why? Because it's more readable.

I could loop towards zero. I could use do-while or while loop if I know
some interesting detail about architechture and compiler I am using.
But I still wouldn't take advantage of this so-called knowledge. The
reason is simple: readability and clarity. I'm well aware that most
code that I write isn't performance critical, so I really don't want to
pay the cost of intentionally making code more complicated that it
needs to be.

On a register starved system it might be advantageous to use the
pointer -and- terminating end-of-iteration pointer to avoid spilling if
nothing else. But for the same reason as before, optimizing at cost of
clarity should be avoided unless necessary.. which for most code simply
isn't.

There's more to be said but most points converge to unnecessary
optimization and clarity issues..