Am 16.03.2010 21:57, schrieb Martin Buchholz:
On Tue, Mar 16, 2010 at 12:48, Ulf Zibis<[email protected]> wrote:
- Same shift magic would enhance isISOControl(), isHighSurrogate(),
isLowSurrogate(), in particular if latter occur consecutive.
isISOControl - yes, others - I am not convinced.
If virtually shifted by 8, HotSpot could use cheaper 1-byte compare on the
high byte.
Additionally, those methods are often used consecutively, so all 4 compares
would benefit from.
8-bit shift + compare would allow HotSpot to compile to smart 1-byte
immediate op-codes.
In encodeBufferLoop() you could use putChar(), putInt() instead put().
Should perform better.
I'm not convinced. You would need to assemble bytes into an
int, and then break them apart into bytes on the other side?
Some time ago, I disassembled such code. I could see, that the int was
copied directly to memory by one 32-bit move instruction.
In case of using put(byte), I saw 4 8-bit move instructions.
Ulf, I'd like to understand this better.
How are you generating the machine code
(pointer to docs?)?
I must prepare it. Takes some time.
Bits.java is doing byte-oriented put instructions in any case.
If the VM can optimize putInt, it should be able to optimize
the equivalent series of put(byte) as well, no?
Yes, it should, but it doesn't.
Can you provide a small patch that gives an observable
performance improvement in a micro-benchmark?
I'll try.
I not have dissassembled if a 3-byte value first would be collected in a
3-byte byte[] and then copied by put(byte[]). Maybe HotSpot could optimize
here too.
Try it out. 2 will see more than 1. Maybe I was in error.
BTW: for the same optimization, I would like to have putInt() and putLong()
in Charbuffer, ShortBuffer and for the latter in IntBuffer.
Perhaps better to get the VM to optimize a series of puts into
a single instruction?
I have such an RFE in mind.
-Ulf
