Comments for Vladimir Vukićević http://blog.vlad1.com Words Tue, 11 Oct 2011 15:15:55 +0000 hourly 1 http://wordpress.org/?v=3.1.3 Comment on Looking at Java NIO Buffer performance by vladimir http://blog.vlad1.com/2011/10/05/looking-at-java-nio-buffer-performance/comment-page-1/#comment-8943 vladimir Tue, 11 Oct 2011 15:15:55 +0000 http://blog.vlad1.com/?p=399#comment-8943 Actually it is Server, 64-bit; I thought I mentioned that, but it got lost in an edit :-) Specifically: Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode) The (even odder) odd thing is that even if I change the second, currently longer, benchmark to do nothing but the exact same timings as the first, it's still much faster. (Just completely deleting the other tests in the source file.) I've been looking at the disassembly and nothing was jumping out at me... the only thing I could think of is that the codegen and memory alloc just happens to get lucky and generates better aligned code/ops, but that's too big of a perf difference even with that. I can force the interpreter and both benchmarks get significantly slower, as expected; hotspot is definitely kicking in. (I can also see that if I trace method compilation etc.) I'll try the early access version of 7u2, though; but were you able to reproduce the speed difference between the two with the same VM? Actually it is Server, 64-bit; I thought I mentioned that, but it got lost in an edit :-) Specifically:

Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)

The (even odder) odd thing is that even if I change the second, currently longer, benchmark to do nothing but the exact same timings as the first, it’s still much faster. (Just completely deleting the other tests in the source file.) I’ve been looking at the disassembly and nothing was jumping out at me… the only thing I could think of is that the codegen and memory alloc just happens to get lucky and generates better aligned code/ops, but that’s too big of a perf difference even with that. I can force the interpreter and both benchmarks get significantly slower, as expected; hotspot is definitely kicking in. (I can also see that if I trace method compilation etc.)

I’ll try the early access version of 7u2, though; but were you able to reproduce the speed difference between the two with the same VM?

]]> Comment on Looking at Java NIO Buffer performance by Osvaldo Doederlein http://blog.vlad1.com/2011/10/05/looking-at-java-nio-buffer-performance/comment-page-1/#comment-8923 Osvaldo Doederlein Fri, 07 Oct 2011 00:40:54 +0000 http://blog.vlad1.com/?p=399#comment-8923 The original benchmark runs way too fast, so I guess it's just too short to let the JIT do its job. So I only spent real time with the newer bench. First off, have you tested with HotSpot Server or Client? Always an essential information in any Java benchmarking report :) as well as any other relevant VM switches (32-bit vs. 64-bit too). I suppose it's Client, 32-bit, no other switches. Maybe you could test with JDK 7u2-b07 and 6u29-b08, these have updated builds of HotSpot. The most important factor for this benchmark is intrinsic optimization of DirectBuffer methods such as get*() and put*(). HotSpot Server fully optimizes this, meaning that it generates inline code for these operations instead of making JNI invocations to native libraries (bad not only because of JNI overhead, but because the invoked code cannot be inlined into the caller). HotSpot Client traditionally sucked on java.nio because it lacked intrinsification of these methods; but I think they are gradually fixing this. With these latst, EA builds, you will find that JDK 6 and 7 have basically the same performance. Comparing Client to Server, the Server VM still has a significant lead in several tests, but the gap is closing. The original benchmark runs way too fast, so I guess it’s just too short to let the JIT do its job. So I only spent real time with the newer bench. First off, have you tested with HotSpot Server or Client? Always an essential information in any Java benchmarking report :) as well as any other relevant VM switches (32-bit vs. 64-bit too). I suppose it’s Client, 32-bit, no other switches. Maybe you could test with JDK 7u2-b07 and 6u29-b08, these have updated builds of HotSpot.

The most important factor for this benchmark is intrinsic optimization of DirectBuffer methods such as get*() and put*(). HotSpot Server fully optimizes this, meaning that it generates inline code for these operations instead of making JNI invocations to native libraries (bad not only because of JNI overhead, but because the invoked code cannot be inlined into the caller). HotSpot Client traditionally sucked on java.nio because it lacked intrinsification of these methods; but I think they are gradually fixing this. With these latst, EA builds, you will find that JDK 6 and 7 have basically the same performance. Comparing Client to Server, the Server VM still has a significant lead in several tests, but the gap is closing.

]]> Comment on Moving On by John Davis http://blog.vlad1.com/2011/02/15/moving-on/comment-page-1/#comment-8794 John Davis Sun, 27 Feb 2011 11:48:38 +0000 http://blog.vlad1.com/?p=382#comment-8794 Vlad, this stuff is gonna change the world. Thanks! You're the man! If you have a minute checkout my demos at http://www.pcprogramming.com With some of the gpu optimized noise just coming out, things are really gonna start rocking in the next couple months on the ray marching side of things. JD Vlad, this stuff is gonna change the world. Thanks! You’re the man!

If you have a minute checkout my demos at http://www.pcprogramming.com

With some of the gpu optimized noise just coming out, things are really gonna start rocking in the next couple months on the ray marching side of things.

JD

]]> Comment on Moving On by Peter Kasting http://blog.vlad1.com/2011/02/15/moving-on/comment-page-1/#comment-8740 Peter Kasting Fri, 18 Feb 2011 19:20:58 +0000 http://blog.vlad1.com/?p=382#comment-8740 Best wishes Vlad! If you ever want to work on browsers again, we on the Chrome team would be glad to have you :) Best wishes Vlad! If you ever want to work on browsers again, we on the Chrome team would be glad to have you :)

]]> Comment on Moving On by Tweets that mention Moving On at Vladimir Vukićević -- Topsy.com http://blog.vlad1.com/2011/02/15/moving-on/comment-page-1/#comment-8738 Tweets that mention Moving On at Vladimir Vukićević -- Topsy.com Fri, 18 Feb 2011 18:40:10 +0000 http://blog.vlad1.com/?p=382#comment-8738 [...] This post was mentioned on Twitter by Dion Almaer and Planet Mozilla, Zohaib Amin. Zohaib Amin said: RT @dalmaer: Oh man. @vvuk was a favorite engineer at Moz. Sorry to see him leave, but congrats to a new challenge! http://bit.ly/e3yE9X [...] [...] This post was mentioned on Twitter by Dion Almaer and Planet Mozilla, Zohaib Amin. Zohaib Amin said: RT @dalmaer: Oh man. @vvuk was a favorite engineer at Moz. Sorry to see him leave, but congrats to a new challenge! http://bit.ly/e3yE9X [...]

]]> Comment on Moving On by Brian King http://blog.vlad1.com/2011/02/15/moving-on/comment-page-1/#comment-8737 Brian King Fri, 18 Feb 2011 10:03:48 +0000 http://blog.vlad1.com/?p=382#comment-8737 Best of luck in the new job Vlad! Best of luck in the new job Vlad!

]]> Comment on Moving On by Dan http://blog.vlad1.com/2011/02/15/moving-on/comment-page-1/#comment-8734 Dan Fri, 18 Feb 2011 01:28:37 +0000 http://blog.vlad1.com/?p=382#comment-8734 "I might not be hacking on Mozilla’s implementation as frequently" - that sounds like a more-than-zero level of involvement, which makes me happy. Thanks for all the work that you've done. “I might not be hacking on Mozilla’s implementation as frequently” – that sounds like a more-than-zero level of involvement, which makes me happy. Thanks for all the work that you’ve done.

]]> Comment on Moving On by Arun http://blog.vlad1.com/2011/02/15/moving-on/comment-page-1/#comment-8728 Arun Thu, 17 Feb 2011 15:30:14 +0000 http://blog.vlad1.com/?p=382#comment-8728 WOW, does this come as a mixture of heartbreakey and exhilarating news. I can't wait to see what you'll do out there. What an interesting new space! FWIW, working on WebGL with you was an incredible experience, from inception as Canvas3D to much talked about technology in Chrome and Firefox. WOW, does this come as a mixture of heartbreakey and exhilarating news. I can’t wait to see what you’ll do out there. What an interesting new space! FWIW, working on WebGL with you was an incredible experience, from inception as Canvas3D to much talked about technology in Chrome and Firefox.

]]> Comment on Moving On by Brandon http://blog.vlad1.com/2011/02/15/moving-on/comment-page-1/#comment-8726 Brandon Thu, 17 Feb 2011 02:55:38 +0000 http://blog.vlad1.com/?p=382#comment-8726 Wishing you all the best, and more kick-ass innovations in the new venture. Wishing you all the best, and more kick-ass innovations in the new venture.

]]> Comment on Moving On by Giles http://blog.vlad1.com/2011/02/15/moving-on/comment-page-1/#comment-8724 Giles Wed, 16 Feb 2011 19:31:01 +0000 http://blog.vlad1.com/?p=382#comment-8724 Vlad, sorry to hear you're moving away from Mozilla and ultimately further from WebGL -- but it sounds like a great new opportunity, and I hope it goes well. Many many thanks for what you've done to create the WebGL implementation and standard. Vlad, sorry to hear you’re moving away from Mozilla and ultimately further from WebGL — but it sounds like a great new opportunity, and I hope it goes well. Many many thanks for what you’ve done to create the WebGL implementation and standard.

]]>