Swap should be better done native?

[Martin Buchholz]

On Thu, Apr 1, 2010 at 16:17, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:
> Am 01.04.2010 23:55, schrieb Martin Buchholz:
>>
>> On Thu, Apr 1, 2010 at 05:32, Ulf Zibis<Ulf.Zibis at gmx.de>  wrote:
>>
>>
>>>>
>>>> How can 4 put(byte) be converted into one put(int)?
>>>>
>>>>
>>>
>>> See the following code snippets ...
>>>
>>> ===================================================
>>> Codesnippet from EUC_TW$Encoder:
>>>            dst.put(SS2);
>>>            dst.put((byte)(0xa0 | p));
>>>            dst.put((byte)(db>>  8));
>>>            dst.put((byte)db);
>>>
>>
>>
>>>
>>> ===================================================
>>> Alternative 1 codesnippet:
>>>            dst.putInt((SS2<<  24) | (0xa0<<  16) | (p<<  16) | db);
>>>
>>
>> Ahhh, I see.  Direct buffers are optimized to use Unsafe.putInt
>> on platforms where unaligned writes are possible (i.e. x86).
>>
>> Some problems with that:

>> - this only works on x86
>>
>
> Correct me if I'm wrong: On all platforms 4 put(byte) can be converted into
> one put(int), but the performance win would be different.

No.  In general, we can't assume that the target address is int-aligned,
and non-x86 architectures require alignment for word writes to memory.

> Maybe using put(byte[]) would be better on other platforms ?

But then you'd have to allocate an expensive byte array,
and write to it first?

>> - this doesn't work with other subclasses of ByteBuffer
>>
>
> Not sure, if I understand right. Which subclasses you mean? CharBuffer,
> e.g., is NOT subclass of ByteBuffer.
> But I see an advantage to have putInt/Long in Char/Short/IntegerBuffer.
>
>> - I would think optimizing the case of ByteBuffer with arrays
>>   (ie. hasArray() is true) would be more important.
>>
>
> I don't think, optimizing the case for the direct buffers would harm the
> case for the heap buffers.

charsets have two cases - general Buffer implementation,
and a specialized one if hasArray() is true for both Buffers.
So switching to putInt instead of putByte
might slow things down either on non-x86 or if
transferring between direct buffer and heap buffer.

Martin