...

...

The actual measurement is important because I would have expected your
time to be dominated by the conditional branches and/or memory access.
Conditional branches are especially expensive if they are unpredictable.

I would be wrong about that if the integer arithmetic move produces a
significant improvement.

Patricia

Hmm. What is the expected range of values for ux,
and what is the size of the array Arr1 ?

  BugBear

    ... which means that there are 121 pairs of values that
meet the requirement u1 < 9 && u2 < 9.  Of these, 15 pairs
give rise to ux values that are negative.  The ensuing
ArrayIndexOutOfBoundsException is sure to slow you down ...

Sanny <softtanks@hotmail.com> wrote in news:4688ee81-76d9-4c56-ad25-
ae3c0242abb7@t1g2000pra.googlegroups.com:

Logically it is, and I guess performace wise too it is.

Absolutely not. In the first case, if mz is initially 1 then 1st case will
result to BigARRAY[1], but in 2nd case it will be BigARRAY[2]

Whats the difference between i++ and ++i;

I heard u1=i+1;

Can I use ++ Such as u1=i++; But I do not want to increment value of
i; Why is i+1 slower than i++?

Bye
Sanny

Most people in this thread seem to be primarily concerned with the
integer arithmetic, so maybe I should explain my preoccupation with the
conditional branches.

Most processors now have deep, wide pipelines. That means that at any
given time there are dozens of instructions at some stage of being
processed, going through a sort of production line. As long as the work
keeps flowing smoothly, multiple instructions complete each cycle.
Evaluating some small integer expression can be tucked into the corners
of memory accesses, and is practically free.

Now consider what happens when a conditional branch enters the pipeline.
The processor has to decide what to put in the pipeline after it. Should
it carry on fetching the next instruction in memory order, or should it
switch to fetching the branch target and its memory order successors?

The processor does not find out whether it guessed right or not until
the branch condition has been evaluated, much later on in the pipeline.
If it guessed wrong, all the work it has done on later instructions is
wasted. It has to flush out its pipeline and start fetching the other
list of instructions. At that point, it has wasted dozens of instruction
execution opportunities.

To compensate for this, processors take heroic measures to try to
predict branches based on history, but are not always successful. The
easiest are branches that almost always go the same way, such as an
error detection branch or the return to the top of a loop with a high
iteration count. Branches that have no pattern to whether they are taken
or not taken, and go either way about equally often, are really expensive.

We are dealing with a short code snippet with three conditional
branches, including one that depends on a value fetched from an array.
They may all have a high correct prediction rate, in which case each
branch is of similar cost to e.g. an integer add, and small tweaks to
the integer arithmetic will make measurable differences in the code
performance. At the other extreme, the Arr1 test could be being
mispredicted so often that the only thing that matters for the loop
performance is doing it as infrequently as possible.

Only measurements can tell.

Patricia