For things like this, it's better to grab hsdis and look at the generated
assembly - it'll answer most of these types of questions.
Sent from my phone
On Sep 28, 2012 2:54 PM, "Ben Evans" <benjamin.john.ev...@gmail.com> wrote:
> Please include a link to your entire project, including the test harness.
>
> Microbenchmarks are tricky things, and it will be easier to have a good
> discussion if others can independently reproduce your results.
>
> Thanks,
>
> Ben
> On 28 Sep 2012 11:42, "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
>
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
