Performance of ranges verses direct

[Marco Leise]

Am Thu, 12 Dec 2013 16:02:28 +0100
schrieb "John Colvin" <john.loughran.colvin at gmail.com>:

> On Wednesday, 11 December 2013 at 16:40:48 UTC, Joseph Rushton 
> Wakeling wrote:
> > [* If I recall right, it's achievable by special-casing iota 
> > when the increment is 1, but don't quote me on that.]
> 
> That shouldn't be necessary if the iota operations are inlined 
> (which, if their not, is a much greater concern!). The increment 
> is then known to be a particular compile-time constant and code 
> generated appropriately.
> 
> Also, on x86 the gcc and llvm backends both prefer to use add 1 
> instead of inc, so you wouldn't even expect to see any difference 
> at that level.

This doesn't seem to be the general case...
http://stackoverflow.com/questions/12163610/why-inc-and-add-1-have-different-performances

"For the x86 architecture, INC updates on a subset of the
condition codes, whereas ADD updates the entire set of
condition codes. (Other architectures have different rules
so this discussion may or may not apply).

So an INC instruction must wait for other previous instructions
that update the condition code bits to finish, before it can
modify that previous value to produce its final condition code
result.

ADD can produce final condition code bits without regard to
previous values of the condition codes, so it doesn't need to
wait for previous instructions to finish computing their value
of the condition codes."

- and -

"On x86 architectures, with variable length instruction
encoding, there could be occasions where either one is
preferable over the other. If the shorter on would fit
in a cache line or decode block where the larger wouldn't,
then it will come out ahead. If the shorter one would leave
half of the next instruction in the window, and the remaining
half in the next window, the larger one might be better by
aligning its successor nicely."

-- 
Marco