Am Thu, 12 Dec 2013 16:02:28 +0100 schrieb "John Colvin" <john.loughran.col...@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
