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

[Christian Thalinger]

On Sat, 2009-01-17 at 22:18 +0100, Ulf Zibis wrote:
> Hi,
> 
> do you mean 0.9 % against +128 trick. This would be good result, because 
> then we could get rid of this trick, and the maps must not be swapped 
> before.
> 
> Maybe there is more difference if buffer's are longer?
> Why you choose byte[255] against byte[256] ?
> What's about filling the buffers with values before?:
> 
>     for (int i=0; i<map.length; i++)
>         map[i] = (char)i;
>     for (int i=0; i<src.length; i++)
>         src[i] = (byte)i;

Filling the buffers should not change the runtime.

> 
> Can you also try with map ?:
> 
>     char[] map = new char[256];
>     void foo() {
>         byte[] src = new byte[16384];
>         char[] dst = new char[16384];
>         for (int i=0; i<1000000; i++) {
>             bar(src, dst);
>         }
>     }
> 
>     void bar(byte[] src, char[] dst) {
>         for (int i=0; i<src.length; i++) {
>             dst[i] = decode(src[i]);
>         }
>     }
> 
>     public char decode(byte a) {
>         return map[a & 0xFF];
>     }
> 
> 
> Is there any difference, if you inline the decode method into the for loop?

I tried that one and it's slightly slower with my new version (unsigned
byte loads).  Btw. I ran the benchmarks on an Intel Core 2 Duo.

-- Christian