[Fwd: Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ...]

[Ulf Zibis]

Hi Christian,

here I send you some benchmark, which was written by Sherman, the 
inventor ? of the +128 trick.
I didn't try it yet.

You also can refer to:
Cr #6785335
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/SpeedTest.java?rev=&view=markup
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/bin/

For the latter, I'm afraid, you have to setup my project 
https://java-nio-charset-enhanced.dev.java.net/ by help of NetBeans.

-Ulf


-------- Original-Nachricht --------
Betreff: 	Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte 
Decoders; ...
Datum: 	Mon, 15 Dec 2008 15:39:05 -0800
Von: 	Xueming Shen <Xueming.Shen at Sun.COM>
An: 	Ulf Zibis <Ulf.Zibis at gmx.de>
CC: 	core-libs-dev at openjdk.java.net
Referenzen: 	<20081210221115.6881DD5DA at hg.openjdk.java.net> 
<4946C475.6080609 at gmx.de> <4946C762.8010003 at gmx.de> 
<4946D7EA.2060902 at sun.com> <4946DF38.9030007 at gmx.de>



Ulf, this is a simple benchmark test case I was using for the singlebyte 
stuff, you
can benchmark lots of things with simple tweak. It's  a simple version 
from Martin's
more complicated/sophisticated benchmark.

Sherman

Ulf Zibis wrote:
> one more question, just for interest:
> Can you see any performance difference between
>    sp != sl
> and
>    sp < sl
> ?
>
> -Ulf
>
>
> Am 15.12.2008 23:19, Xueming Shen schrieb:
>>
>> The gain from doing
>>
>> int sr = src.remaining();
>> int dr = dst.remaining();
>>
>> Ulf, thanks for looking into the changes.
>>
>> It might not be a good idea to skip the temporary variable c in the 
>> loop, I'm not sure
>> it's a good idea to put an "un-mappable" char into the output buffer 
>> in case we have
>> a un-mappable though yes we don't not change the buffer position. 
>> This actually is
>> all most all the gain come from in -server vm case when I run my 
>> benchmark.
>>
>> However in "client" vm case, interestingly I do see some performance 
>> gain with
>> your proposed change, though I'm not sure why the loop gets faster 
>> with a quick
>> look. So I have created a new Cr #6785335 to keep trace this issue. 
>> Will consider
>> put this one into 7 later.
>>
>> Thanks again!
>>
>> Sherman
>>
>>
>> Ulf Zibis wrote:
>>> Maybe:
>>>          for (int sl = sp + (sr <= dr ? sr : dr); sp != sl; sp++, dp++)
>>> is little more faster than:
>>>          for (int sl = sp + (sr <= dr ? sr : dr); sp < sl; sp++, dp++)
>>>
>>> -Ulf
>>>
>>>
>>> Am 15.12.2008 21:56, Ulf Zibis schrieb:
>>>> Maybe little faster, especially for short strings:
>>>>
>>>>       private CoderResult decodeArrayLoop(ByteBuffer src, 
>>>> CharBuffer dst) {
>>>>           byte[] sa = src.array();
>>>>           int sp = src.arrayOffset() + src.position();
>>>>           int sr = src.remaining();  // faster than ... 
>>>> src.arrayOffset() + src.limit()
>>>>
>>>>           char[] da = dst.array();
>>>>           int dp = dst.arrayOffset() + dst.position();
>>>>           int dr = dst.remaining(); // dl is never used
>>>>
>>>>           for (int sl = sp + (sr <= dr ? sr : dr); sp < sl; sp++, 
>>>> dp++)
>>>>               if ((da[dp] = decode(sa[sp])) == UNMAPPABLE_DECODING)
>>>>                   return 
>>>> withResult(CoderResult.unmappableForLength(1), src, sp, dst, dp);
>>>>           return withResult(sr <= dr ? CoderResult.UNDERFLOW : 
>>>> CoderResult.OVERFLOW, src, sp, dst, dp);
>>>>       }
>>>>
>>>> Regards,
>>>> Ulf
>>>>
>>>
>>
>>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090117/c4a0d832/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NIOCodingMicroBenchmark.java
Type: text/x-java
Size: 7956 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090117/c4a0d832/attachment.bin