 |
|
 |
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
 
Osvaldo Pinali Doederlein's BlogMustang's HotSpot Client gets 58% faster!Posted by opinali on November 10, 2005 at 09:13 AM | Comments (7)Mustang is adding new optimizations to HotSpot, not news, we expect the JVM to learn new tricks at every release. But the great news is that Sun just added a great performance enhancement to HotSpot Client. Yep, the other HotSpot... the one that never appears in benchmarks aimed to make Java or particular JVMs look good. Unfortunately, you can't realistically use the Server VM in most client apps, from simple database front-ends to action games, as it loads slower, eats more RAM, and it's not included in the more ubiquitous JRE package. Well, good news: Build 59 includes an improvement recorded as Bug 6320351: new register allocator for C1. ("C1" means HotSpot Client; C2 is Server.) The bug description is short, so there it goes in full: "The existing register allocator for C1 is very primitive and doesn't take very good advantage of the registers available. It also doesn't allow values to live across blocks. Along with the high level IR models locals in such an explicit manner that the code quality for inlining is fairly bad." A good register allocator is even more important in the Intel x86 platform because it's got so few architectural registers. How cool is this new optimization? I tested with SciMark2, a good benchmark for that kind of stuff because it runs tight loops of complex arithmetic expressions, array access and similar operations that benefit enormously from good register allocation. Results (on Windows / Pentium-IV 2,25GHz) are:
Notice the remarkable improvement in HotSpot Client, a 58% boost over 5.0 (the best stable HotSpot) or Mustang b58 (the previous build without the new optimization). The Server VM is also improving in Mustang, but only by a modest 5% over 5.0 (that's already good enough to produce near-ideal code; SciMark2 doesn't need most new tricks of Server 6.0, from lock coarsening to the [still upcoming] benefits of escape analysis). The improvement in the sub-tests Sparse matmult (2,9X faster) and LU factorization (2,8X faster) are even more noticeable; these two tests are heavy in array manipulation. I'm not sure why arrays improve so much, but my bet is that the better register allocation, causing fewer reloads of array and index variables, plays well with CPU optimizations like data prefetching and instruction-level parallelism. This all spells good news for Java clients. The improved code generation is good not just for action games with sophisticated geometry calculations. Complex algorithms like Java2D's blt loops, Swing's painting and layout code, chart renders, XML parsers, middleware stacks and others, lie below our vanilla CRUD & reporting application. HotSpot Client is doomed to always lag behind Server, but Moore's Law allows to continuously package more tricks even in the JVM for low-end machines and user-time sensitive apps. CommentsComments are listed in date ascending order (oldest first) | Post Comment
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 java.net RSS Feeds
|
