On Jul 28, 2010, at 6:28 PM, Alexey Zinger wrote:
> Have you tried inlining those methods in your benchmark (no field references,
> as was mentioned -- just local variables).
hotspot aggressively inlines. No need to inline but you must warmup the bench.
Variables will be cached regardless of scoping.
Eclipse (or all IDE's for that matter) instrument the JVM that they launch so
they can control it. It does have an effect on performance but 3x isn't normal.
I doubt that there is no real difference in the performance of the two methods
in a single threaded bench. In fact this code is not thread safe so.. the value
will be hoisted into a register and it will sit there. And, I doubt there is
much of a difference if any, in the performance of this code written in C++ or
Java.
Regards,
Kirk
>
> In case anyone cares, did a bit of testing and found:
>
> (1) Running in Eclipse using "Run" was about 3 times slower than running
> "java" on command line (on my particular machine) on the same class files.
> So yes, environment, JVM version etc make a BIG difference straight up.
>
> (2) If you want to write a class reading from a stream with a field holding
> the current index being read from and you want to read 4 bytes, its faster to
> update index once than updating 4 times.
>
> class ByteBuf {
> private int i = 0;
> private byte[] buf = ...;
>
> int slowerReadInt32() {
> byte b1 = buf[i++];
> byte b2 = buf[i++];
> byte b3 = buf[i++];
> byte b4 = buf[i++];
> return (b1 << 24) | ((b2 & 0xff) << 16) | ((b3 & 0xff) << 8) |
> (b4 & 0xff);
> }
>
> int fasterReadInt32() {
> byte b1 = buf[i];
> byte b2 = buf[i+1];
> byte b3 = buf[i+2];
> byte b4 = buf[i+3];
> i += 4;
> return (b1 << 24) | ((b2 & 0xff) << 16) | ((b3 & 0xff) << 8) |
> (b4 & 0xff);
> }
> }
>
> Upon reflection of course it will be faster. The first function has to
> update the field 'i' per increment in case there is an index out of bounds
> exception. The second only updates the field once.
>
>
> Doing Google searches on Java vs C++ performance I found some Wikipedia etc
> pages, that I don't trust much. There were a few subjective sounding
> statements in there, and some comments talked about the new JIT that might
> speed Java up. The only comments I almost trust were Java probably does
> new/delete faster than C++ but tends to consume more memory, and Java JIT
> might get code to same raw execution speed to same as C++ (but 4 times slower
> is not unexpected).
>
> So my next meaningless microbenchmark will be to try Scala with lazy vals
> pulled from a byte[] (and so potentially avoiding the need for converting
> bytes in a buffer into int's in the first place).
>
> Alan
>
> -- You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
