Interesting, yes it does seem counter-intuitive, perhaps the compiler author was a pessimist o.0

It looks like your conditional is fuzzy there? The only explicit value that can be checked is 0, maybe this has a bearing in the algorithm used to generate the resultant instructions (not that it makes a difference in the grand scheme of things in terms of your program).

Mind you, whats counter intuitive, it may seem counter-intuitive to you (with a higher knowledge of the programs intention, and biased to what you think your most important code path is through any particular block), but to a compiler there is no right or wrong with a conditional, just one state and the other. I have no idea tbh, but suspect it's the result of some optimization algorithm which itself resolved to something weird (yet correct... -0.000 == Pessimists version of nothing). What compilation flags were used? if you change the flags, how different (if at all), is this resultant assembly?

Without prior knowledge, there is no reason why one is more intuitive than the other, so the compiler author can implement it either way.

Modern compilers try to guess which one is more likely, and optimize the code so that the jump happens less frequently than non-jump (seeing as 'jump' is an expensive CPU instruction, because it involves flushing most of the pipeline). So if counter is more often non-zero, the code generated by the compiler in your example makes sense.

It gets more complicated, since modern CPUs have branch predictors that try to guess whether a jump is going to happen or not, and optimize the pipeline accordingly. In modern compilers it is also possible to give "hints" that suggest which condition is more likely, e.g., likely() and unlikely() macros.

1if (likely(x>0))
2    do_something();
3else
4    do_something_else();

In the case of the first code in my first post, Visual C++ executes the jz to the else block 15 out of 16 times it reaches that point, resulting in a big performance hit(it jumps 15 out of 16 times, of which the part containing the jump is executed quite a lot: it's generating PWM samples for 6 channels on 2 virtual chips at a rate of 3.57 million times per second(Game Blaster audio softsynth). Each sample jumped 15 out of 16 PWM subsamples, so that's 15x2x6x3.57M cache misses each second. This would be reduced by 14x2x6x3.57M if the compiler would just properly assume most of the time the if isn't followed, executing the return statement(currently not used anymore due to newly createn PDM sampling instead of PWM sampling(which uses a lookup table instead now).

superfury wrote:

In the case of the first code in my first post, Visual C++ executes the jz to the else block 15 out of 16 times it reaches that point, resulting in a big performance hit(it jumps 15 out of 16 times, of which the part containing the jump is executed quite a lot: it's generating PWM samples for 6 channels on 2 virtual chips at a rate of 3.57 million times per second(Game Blaster audio softsynth). Each sample jumped 15 out of 16 PWM subsamples, so that's 15x2x6x3.57M cache misses each second.

Are you sure there are cache misses? Because modern CPUs ("modern" meaning Pentium and later...) have branch prediction mechanisms. If the particular branch is taken 15 out of 16 times, after several iterations the CPU will note itself "aha, this branch is almost always taken, I'll queue whatever there is as if the branch were taken", resulting in a cache miss only once out of 16 times, and the jump being almost free (one cycle or so). Or, if there is a fixed pattern (15 times taken, 1 time not taken) it might notice even that resulting in nearly 100% hit.

dr_st wrote:

It gets more complicated, since modern CPUs have branch predictors that try to guess whether a jump is going to happen or not, and optimize the pipeline accordingly.

Yes, on some CPUs a branch is actually 'free' as long as it was predicted correctly (eg the Motorola 68060), because it is processed by a 'side channel' in the pipeline, so it can be executed alongside regular instructions, not taking any processing time.
I believe on all modern x86 processors the actual 'jcc' instruction still takes 1 cycle/slot in the pipeline, but taken/not-taken doesn't make a difference, it's all about matching prediction or not.

There are some fixed heuristics, such as a jump to a lower address is always assumed to be taken (it is likely a loop), and a jump to a higher address is assumed to be not-taken (probably a special-case like error-handling).

Scali wrote:

There are some fixed heuristics, such as a jump to a lower address is always assumed to be taken (it is likely a loop), and a jump to a higher address is assumed to be not-taken (probably a special-case like error-handling).

These may be the defaults, but x86 CPUs keep history of recent jumps, and if particular jump behaves consistently (e.g. taken - not taken - taken - not taken) it will adapt to that.

Azarien wrote:

These may be the defaults, but x86 CPUs keep history of recent jumps, and if particular jump behaves consistently (e.g. taken - not taken - taken - not taken) it will adapt to that.

Of course. That's what (dynamic) branch prediction actually is.
The heuritiscs are just the 'starting point', the initial prediction.
There's also a thing as 'predication', where you can give hints as to what the starting point should be (which is what the aforementioned macros such as likely() will amount to).
Some CPUs (not x86 of course, too much legacy, too little sophistication) allow you to put an entire bitmask of the behaviour into the jump opcode, so you pre-initialize the prediction. This can be done at compile-time by profiling the code. Eg, you could put 16 bits worth of 'history' into the opcode.