Re: ptr vs ref performance??

[Tim Hollebeek <tim at hollebeek dot com>]

Rob Willis writes ...
> 
> ptr de-ref:
>    value = *tp;
> 
> ref access;
>    value = tr;
> 
> I substracted out the looping and assignment overheads in the
> performance #'s above.  

(difference was 13% over 6 billion ops)

For _really_ tight loops like this, benchmarks are dangerous since
many naive assumptions go out the window.

For example, "subtracting out loop overhead" may not be accurate since
branch prediction, lookahead, pipelining, etc etc etc issues are
likely to be a significant fraction of overall execution speed, and
what instructions are inside the loop (# of instructions, alignment,
data dependencies, delay slots, etc) can change the speed of the loop
instructions.

Similarly, "subtracting out assignment" makes no sense since the
compiled code does not have a distinct assignment step, especially at
high levels of optimization.

For short snippets of code like this, benchmarks may provide
information about what to look at, but one really should be looking at
what assembly code is generated for each fragment and comparing the
differences in generated assembly code instead of comparing timing
differences.  So I suggest compiling your tests with -S and posting
the results.  That will help experts notice how each fragment is being
compiled, what the differences are, if either is suboptimal, etc.