Swap should be better done native?
martinrb at google.com
Fri Apr 2 11:42:09 PDT 2010
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((byte)(0xa0 | p));
>>> dst.put((byte)(db>> 8));
>>> 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.
More information about the nio-dev