Performance of locally copied members ?

[Martin Buchholz]

Osvaldo,

Thanks for the interesting measurements.

I have already assimilated this optimization
into my own coding style, but have hesitated to
publicize it or to require it of others, partly
because one hopes that future JIT improvements
will obsolete it.

It seems likely that we "system programmers"
will need to help the compiler make the best code
forever, but the nature of that help changes (slowly).

Martin

On Mon, May 3, 2010 at 13:13, Osvaldo Doederlein <opinali at gmail.com> wrote:
> 2010/5/3 Martin Buchholz <martinrb at google.com>
>>
>> It's a coding style made popular by Doug Lea.
>> It's an extreme optimization that probably isn't necessary;
>> you can expect the JIT to make the same optimizations.
>
> It certainly is necessary - unfortunately. Testing my particle/octree-based
> 3D renderer without this manual optimization (dumping FPS performance each
> 100 frames, begin at 10th score after startup):
>
> JDK 6u21-b03, Hotspot Client:
> 159.4896331738437fps
> 161.29032258064515fps
> 158.73015873015873fps
> 160.0fps
> 159.23566878980893fps
>
> JDK 6u21-b03, Hotspot Server:
> 197.23865877712032fps
> 204.91803278688525fps
> 196.07843137254903fps
> 200.40080160320642fps
> 198.01980198019803fps
>
> Now let's cache 8 instance variables into local variables (most final, a
> couple non-final ones too):
>
> JDK 6u21-b03, Hotspot Client:
> 169.4915254237288fps
> 172.1170395869191fps
> 168.63406408094434fps
> 168.0672268907563fps
> 170.64846416382252fps
>
> JDK 6u21-b03, Hotspot Server:
> 197.62845849802372fps
> 200.40080160320642fps
> 196.8503937007874fps
> 199.6007984031936fps
> 203.2520325203252fps
>
> So, the manual optimization makes no difference for Hotspot Server; but hell
> it does for Client - 6% better performance in this test; and the test is not
> only the complex, deeply nested rendering loops that use those cacheable
> variables to read the input data and update the output pixel and Z buffers -
> there's also other code that burns significant CPU and doesn't use these
> variables, remarkably buffer filling and copying steps. This means the
> speedup in the optimized code should be much higher than 6%, I only reported
> / cared to measure the application's global performance.
>
> We'll need to deal with HotSpot Client for years to come, not to mention
> smaller platforms (JavaME, JavaFX Mobile&TV) which JIT compilers are even
> lesser than JavaSE's C1. Tuned bytecode is also faster to interpret, which
> benefits warm-up time too. Please keep your dirty purist hands off the API
> code that Doug and others micro-optimized; it is necessary. :)
>
> And my +1 to add the same opts to other perf-critical APIs. Even most
> important for java.nio as under C1, it doesn't currently benefit from
> intrinsic compilation of critical DirectBuffer methods.
>
> A+
> Osvaldo
>
>
>>
>> (you can try to check the machine code yourself!)
>> Nevertheless, copying to locals produces the smallest
>> bytecode, and for low-level code it's nice to write code
>> that's a little closer to the machine.
>>
>> Also, optimizations of finals (can cache even across volatile
>> reads) could be better.  John Rose is working on that.
>>
>> For some algorithms in j.u.c,
>> copying to a local is necessary for correctness.
>>
>> Martin
>>
>> On Mon, May 3, 2010 at 04:40, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:
>> > Hi,
>> >
>> > in class String I often see member variables copied to local variables.
>> > In java.nio.Buffer I don't see that (e.g. for "position" in
>> > nextPutIndex(int
>> > nb)).
>> > Now I'm wondering.
>> >
>> > From JMM (Java-Memory-Model) I learned, that jvm can hold non-volatile
>> > variables in a cache for each thread, so e.g. even in CPU register for
>> > few
>> > ones.
>> > From this knowing, I don't understand, why doing the local caching
>> > manually
>> > in String (and many other classes), instead trusting on the JVM.
>> >
>> > Can anybody help me in understanding this ?
>> >
>> > -Ulf
>> >
>> >
>> >
>
>