Yup, it would have to do extensive pattern matching otherwise. C/C++
compilers do the same thing (I.e. have intimate knowledge of stdlib calls
and may optimize more aggressively or replace code with intrinsic
altogether).
In this case, jit uses the bsf x86 assembly instruction whereas hand rolled
"copy version" generates asm pretty much matching the java code.
Sent from my phone
On Sep 28, 2012 2:42 PM, "Raffaello Giulietti" <
raffaello.giulie...@gmail.com> wrote:
> On Fri, Sep 28, 2012 at 8:15 PM, Charles Oliver Nutter
> <head...@headius.com> wrote:
> > On Fri, Sep 28, 2012 at 10:21 AM, Raffaello Giulietti
> > <raffaello.giulie...@gmail.com> wrote:
> >> I'm not sure that we are speaking about the same thing.
> >>
> >> The Java source code of numberOfTrailingZeros() is exactly the same in
> >> Integer as it is in MyInteger. But, as far as I understand, what
> >> really runs on the metal upon invocation of the Integer method is not
> >> JITted code but something else that probably makes use of CPU specific
> >> instructions. This code is built directly into the JVM and need not
> >> bear any resemblance with the code that would have been produced by
> >> JITting the bytecode.
> >
> > Regardless of whether the method is implemented in Java or not, the
> > JVM "knows" native/intrinsic/optimized versions of many java.lang core
> > methods. numberOfTrailingZeros is one such method.
> >
> > Here, the JVM is using its intrinsified version rather than the JITed
> > version, presumably because the intrinsified version is pre-optimized
> > and faster than what the JVM JIT can do for the JVM bytecode version.
> >
> > system ~/projects/jruby-ruby $ java -XX:+PrintCompilation
> > -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining Blah
> > 65 1 java.lang.String::hashCode (55 bytes)
> > 78 2 Blah::doIt (5 bytes)
> > 78 3 java.lang.Integer::numberOfTrailingZeros (79
> bytes)
> > @ 1
> > java.lang.Integer::numberOfTrailingZeros (79 bytes) (intrinsic)
> > 79 1 % Blah::main @ 2 (29 bytes)
> > @ 9 Blah::doIt (5 bytes) inline (hot)
> > @ 1
> > java.lang.Integer::numberOfTrailingZeros (79 bytes) (intrinsic)
> > @ 15 Blah::doIt (5 bytes) inline (hot)
> > @ 1
> > java.lang.Integer::numberOfTrailingZeros (79 bytes) (intrinsic)
> >
> > system ~/projects/jruby-ruby $ cat Blah.java
> > public class Blah {
> > public static int value = 0;
> > public static void main(String[] args) {
> > for (int i = 0; i < 10_000_000; i++) {
> > value = doIt(i) + doIt(i * 2);
> > }
> > }
> >
> > public static int doIt(int i) {
> > return Integer.numberOfTrailingZeros(i);
> > }
> > }
> > _______________________________________________
>
>
> Yes, this is what Vitaly stated and what happens behind the curtains.
>
> In the end, this means there are no chances for the rest of us to
> implement better Java code as a replacement for the intrinsified
> methods.
>
> For example, the following variant is about 2.5 times *faster*,
> averaged over all integers, than the JITted original method, the one
> copied verbatim! (Besides, everybody would agree that it is more
> readable, I hope.)
>
> But since the Integer version is intrinsified, it still runs about 2
> times slower than that (mysterious) code.
>
> public static int numberOfTrailingZeros(int i) {
> int n = 0;
> for (; n < 32 && (i & 1 << n) == 0; ++n);
> return n;
> }
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
