CPU timing list is just rough idea for current sophisticated CPUs. Those branching and pipeline thingy crunch instruction no more in serial one-by-one way.

If creating large loops for operator testing then random input must be assured. But remember that memory access latency also comes into play... and lots of other factor to constitute a false sense of result.

Just said, knows how objects are passed and optimizing on algorithm benefits more.

A) je, jne, as well as jz, jnz just do one single thing: they branch according to the state of the zero flag. Nothing else. Even though exact circuit timing might differ, it will have no influence on the timing of the opcode. A CPU''s opcode pipelines are synchronized to a central cycle clock, so the time of each opcode is *exactly* known.

B) Executing jnz/jz billions of times in the same code is not very intelligent. In realworld code, branch prediction and cache line fetching will have far more impact than the execution time of a branching opcode.

C) Californium: one more insult, and this thread is closed.

Actually, since your variable (A) is a boolean variable, its value is either true or false. Because of this, the best way to write your code would be:

if (!A)
...proceed to rest of if

This works because if A == false then the statement would be !false, which is true, which leads you to entering the if.

quote: Original post by Name-ing-Way
Actually, since your variable (A) is a boolean variable, its value is either true or false. Because of this, the best way to write your code would be:

if (!A)
...proceed to rest of if

This works because if A == false then the statement would be !false, which is true, which leads you to entering the if.

Would that add to the speed? I wouldn''t think so. You would probably use a compare or and or and probably a jz instruction anyway.

I agree, I usually write things like this too. Sometimes it may be clearer to use the other method though.