Strange speed dependency (original) (raw)
Martin Buchholz martinrb at google.com
Tue Feb 3 05:49:17 UTC 2009
- Previous message: Strange speed dependency
- Next message: hg: jdk7/tl/jdk: 2 new changesets
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Feb 2, 2009 at 17:03, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:
Martin,
the reason for my post was to give the HotSpot guys some hint for additional enhancement. BTW, I have used the recent UTF8 decoder for my reference. ... But I have experienced some errors: http://bugs.sun.com/bugdatabase/viewbug.do?bugid=6795537 http://bugs.sun.com/bugdatabase/viewbug.do?bugid=6798514
Oh dear. Thanks for finding these.
Fortunately it only affects erroneous input, so it not so terrible. Still, we should fix them right away, esp. since the fix is in openjdk6.
Martin
Most of them I have repaired yet, and fortunately I could enhance the speed by another ~20 % (on my machine, should be evaluated).
-Ulf
Am 03.02.2009 00:02, Martin Buchholz schrieb:
Ulf, the new UTF8 decoder in very recent jdks is much faster, and the primary trick that was used to achieve that was reducing the size of the bytecode in the hot methods and moving cold code to separate methods. Martin On Mon, Feb 2, 2009 at 14:35, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:
Hi all, I have experienced a strange speed dependency of HotSpot compiled code after little change in code, which is not part of the "hot" loop. Is there any explanation for this behavior? Code before little change: class UTF8new extends Unicode { // .... private static CoderResult malformed(ByteBuffer src, int sp, CharBuffer dst, int dp, int nb) { src.position(sp -= nb - src.arrayOffset()); CoderResult cr = malformedN(src, nb); updatePositions(src, sp, dst, dp); return cr; } // .... while (sp < sl) {_ _// ...._ _int b2 = sa[sp++];_ _int b3 = sa[sp++];_ _int b4 = sa[sp++];_ _if (isMalformed4(b1, b2))_ _return malformed(src, sp-2, dst, dp, 2);_ _if (isNotContinuation(b3))_ _return malformed(src, sp-1, dst, dp, 3);_ _if (isNotContinuation(b4))_ _return malformed(src, sp, dst, dp, 4);_ _if (dp >= dl - 1) return overflow(src, sp-4, dst, dp); int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ 0x00381f80; // .... } The above code has following output (note gain against UTF870$Decoder): time for sun.nio.cs.UTF860$Decoder: 2701 ms time for sun.nio.cs.UTF870$Decoder: 1984 ms time for sun.nio.cs.UTF8new$Decoder: 1720 ms // gain: 264 ms time for sun.nio.cs.UTF8last$Decoder: 2110 ms
Following small code change made the "hot" part of the loop much slower: class UTF8new extends Unicode { // .... private static CoderResult malformed(ByteBuffer src, int sp, CharBuffer dst, int dp, int nb) { src.position(sp - src.arrayOffset()); // removed subtraction of nb CoderResult cr = malformedN(src, nb); updatePositions(src, sp, dst, dp); return cr; } // .... while (sp < sl) {_ _// ...._ _int b2 = sa[sp++];_ _int b3 = sa[sp++];_ _int b4 = sa[sp++];_ _if (isMalformed4(b1, b2))_ _return malformed(src, sp-4, dst, dp, 2);_ _if (isNotContinuation(b3))_ _return malformed(src, sp-4, dst, dp, 3);_ _if (isNotContinuation(b4))_ _return malformed(src, sp-4, dst, dp, 4);_ _if (dp >= dl - 1) return overflow(src, sp-4, dst, dp); int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ 0x00381f80; // .... } time for sun.nio.cs.UTF860$Decoder: 2731 ms time for sun.nio.cs.UTF870$Decoder: 1981 ms time for sun.nio.cs.UTF8new$Decoder: 1872 ms // gain: 109 ms time for sun.nio.cs.UTF8last$Decoder: 2094 ms For complete sources compare following revisions (... and run UTF8Benchmark.java ): https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diffformat=s&rev=613 https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diffformat=s&rev=614 -Ulf
- Previous message: Strange speed dependency
- Next message: hg: jdk7/tl/jdk: 2 new changesets
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]