Yes, the immediate is part of the instruction encoding, so takes up space.
However, I believe the CMP instruction allows comparison of an immediate
with a wider register (e.g. cmp $-1, %eax), in which case the immediate
takes up 1 byte and is then sign extended to the size of the register.
But again, let's keep in mind that LinkedList is (likely) going to have
performance problems long before the difference being discussed here. The
JIT compiler emits drastically different (and much more of it in my trials,
so instruction size difference in terms of a byte or two is irrelevant)
code when it's given profiling info (i.e. no -Xcomp flag), for both
ArrayList and LinkedList.
As mentioned before, if we were talking about some tight loop with nothing
but very basic/cheap instructions in there (e.g. integer arithmetic,
shifting, etc) and no memory chasing, then micro optimizations like this
may be interesting and lead to some perf gain. But in the context of this
example, I don't think so.
On Fri, Aug 29, 2014 at 4:05 PM, Ulf Zibis <ulf.zi...@cosoco.de> wrote:
>
> Am 28.08.2014 um 19:46 schrieb Vitaly Davidovich:
>
>
>> There's no register pressure - the immediate (I.e. -1) is encoded
>> directly into the instruction, just like 0 would be. The time when 0 is
>> particularly useful is when you test for it in the zero bit of the flags
>> register (e.g. dec followed by jz, such as when counting a loop down to
>> 0). Otherwise, I don't see any advantage from machine code perspective.
>>
>>
> 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.
>
> So if unifying the code I agree to Martin's opinion.
>
> -Ulf
>
> The aforementioned cmov instruction is not without its own downsides, so
>> it's unclear which is better when branch probability isn't known a priori.
>>
>> The 1 byte code is unlikely to make any difference, unless jit is turned
>> off and you're running this through a tight loop in the interpreter (but if
>> one does that, perf conversation is moot :)).
>>
>> Sent from my phone
>>
>> On Aug 28, 2014 1:28 PM, "Ulf Zibis" <ulf.zi...@cosoco.de <mailto:
>> ulf.zi...@cosoco.de>> wrote:
>>
>>
>> Am 27.08.2014 um 17:51 schrieb Martin Buchholz:
>>
>> The ArrayList version saves one byte of bytecode, and is
>> therefore very
>> slightly better. We should bless that version and use it
>> consistently.
>>
>>
>> +1
>> Additional argument:
>> The LinkedList code requires to load 32/64-Bit -1 into CPU. This may
>> take some time on some
>> CPU and at least wastes memory footprint.
>> Additionally register pressure increases.
>> Vitaly, please correct me, if I'm wrong, just for learning more.
>>
>> Another advantage is that there is no problem if some implementation
>> of indexOf() erroneously
>> returns another negative value than -1. I remember some compare()
>> implementations, which
>> sometimes return different values than only -1, 0, +1.
>>
>> -Ulf
>>
>> ArrayList:
>>
>> public boolean contains(Object o) {
>> return indexOf(o) >= 0;
>> }
>>
>> LinkedList:
>>
>> public boolean contains(Object o) {
>> return indexOf(o) != -1;
>> }
>>
>>
>>
>
