On Aug 29, 2014, at 1:05 PM, Ulf Zibis <ulf.zi...@cosoco.de> wrote: > Thanks for explaining this, but a very little nit: the immediate (I.e. -1) > uses additional 32/64 bits in code which must be loaded from memory and > wastes space in CPU cache or am I wrong? This could be saved with >= 0.
I have to say you're more wrong than right about this. Optimizers routinely change the form of constants. For example, a constant 0 will often show up as something like "xor eax,eax", not a 32-bit literal zero that loads from somewhere in memory. A comparison of the form "x > -1" will be freely changed to "x >= 0" and back again; the latter form may (or may not, depending on chip version) transform to "test eax", with no "-1" or "0" in sight. Also, even if you can (on some sunny Friday) detect 32 or more one-bits in an instruction stream, it does not follow that tweaking your source code to make them disappear will prevent them from reappearing (in the dark of the next solstice or the next update release of the JVM). And this won't be a bug, because data loads from instruction cache are extremely cheap, since in most present chips they are pipelined well ahead of any use. Changing source code on based on the difference between 0 and -1 is almost as pointless as removing whitespace and comments, or swapping "a+b" to "b+a", hoping somehow to improve efficiency. Sure, it might happen if you are lucky but because it's luck, your luck will change. I hate to say it, but (as a different example) removing "asserts" is much more likely to improve performance than shuffling constant spellings. And this is because of a more important bug in the JIT, where inline decisions wrongly take into account the presence of inactive asserts. I'm not trying to evade the present subject, but in the grand scheme of things this email thread is shuffling equivalent chunks of furniture, which the JIT is going to reshuffle behind your back anyway. If you really have a measurable performance problem (as with asserts), file a bug against the JIT rather than trying to control code shape by making semantically null changes to source code. — John
