<p dir="ltr">Since we're in wishful thinking territory now :), the two things I'd really like are:</p>
<p dir="ltr">1) value/struct types (i.e. avoid heap and be able to pack data closer together). I don't how much we can rely on EA.<br>
2) more auto-vectorization</p>
<p dir="ltr">I think 2 is being worked on by Vladimir but unclear if there are any concrete plans for 1. I know John Rose has written about it, but don't know if anything's actually planned.</p>
<p dir="ltr">Sent from my phone</p>
<div class="gmail_quote">On Sep 28, 2012 3:59 PM, "Charles Oliver Nutter" <<a href="mailto:headius@headius.com" target="_blank">headius@headius.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now what we need is a way to inject new intrinsics into the JVM, so I<br>
can make an asm version of something and tell hotspot "no no, use<br>
this, not the JVM bytecode" :)<br>
<br>
- Charlie<br>
<br>
On Fri, Sep 28, 2012 at 11:53 AM, Vitaly Davidovich <<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>> wrote:<br>
> Yup, it would have to do extensive pattern matching otherwise. C/C++<br>
> compilers do the same thing (I.e. have intimate knowledge of stdlib calls<br>
> and may optimize more aggressively or replace code with intrinsic<br>
> altogether).<br>
><br>
> In this case, jit uses the bsf x86 assembly instruction whereas hand rolled<br>
> "copy version" generates asm pretty much matching the java code.<br>
><br>
> Sent from my phone<br>
><br>
> On Sep 28, 2012 2:42 PM, "Raffaello Giulietti"<br>
> <<a href="mailto:raffaello.giulietti@gmail.com" target="_blank">raffaello.giulietti@gmail.com</a>> wrote:<br>
>><br>
>> On Fri, Sep 28, 2012 at 8:15 PM, Charles Oliver Nutter<br>
>> <<a href="mailto:headius@headius.com" target="_blank">headius@headius.com</a>> wrote:<br>
>> > On Fri, Sep 28, 2012 at 10:21 AM, Raffaello Giulietti<br>
>> > <<a href="mailto:raffaello.giulietti@gmail.com" target="_blank">raffaello.giulietti@gmail.com</a>> wrote:<br>
>> >> I'm not sure that we are speaking about the same thing.<br>
>> >><br>
>> >> The Java source code of numberOfTrailingZeros() is exactly the same in<br>
>> >> Integer as it is in MyInteger. But, as far as I understand, what<br>
>> >> really runs on the metal upon invocation of the Integer method is not<br>
>> >> JITted code but something else that probably makes use of CPU specific<br>
>> >> instructions. This code is built directly into the JVM and need not<br>
>> >> bear any resemblance with the code that would have been produced by<br>
>> >> JITting the bytecode.<br>
>> ><br>
>> > Regardless of whether the method is implemented in Java or not, the<br>
>> > JVM "knows" native/intrinsic/optimized versions of many java.lang core<br>
>> > methods. numberOfTrailingZeros is one such method.<br>
>> ><br>
>> > Here, the JVM is using its intrinsified version rather than the JITed<br>
>> > version, presumably because the intrinsified version is pre-optimized<br>
>> > and faster than what the JVM JIT can do for the JVM bytecode version.<br>
>> ><br>
>> > system ~/projects/jruby-ruby $ java -XX:+PrintCompilation<br>
>> > -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining Blah<br>
>> > 65 1 java.lang.String::hashCode (55 bytes)<br>
>> > 78 2 Blah::doIt (5 bytes)<br>
>> > 78 3 java.lang.Integer::numberOfTrailingZeros (79<br>
>> > bytes)<br>
>> > @ 1<br>
>> > java.lang.Integer::numberOfTrailingZeros (79 bytes) (intrinsic)<br>
>> > 79 1 % Blah::main @ 2 (29 bytes)<br>
>> > @ 9 Blah::doIt (5 bytes) inline (hot)<br>
>> > @ 1<br>
>> > java.lang.Integer::numberOfTrailingZeros (79 bytes) (intrinsic)<br>
>> > @ 15 Blah::doIt (5 bytes) inline (hot)<br>
>> > @ 1<br>
>> > java.lang.Integer::numberOfTrailingZeros (79 bytes) (intrinsic)<br>
>> ><br>
>> > system ~/projects/jruby-ruby $ cat Blah.java<br>
>> > public class Blah {<br>
>> > public static int value = 0;<br>
>> > public static void main(String[] args) {<br>
>> > for (int i = 0; i < 10_000_000; i++) {<br>
>> > value = doIt(i) + doIt(i * 2);<br>
>> > }<br>
>> > }<br>
>> ><br>
>> > public static int doIt(int i) {<br>
>> > return Integer.numberOfTrailingZeros(i);<br>
>> > }<br>
>> > }<br>
>> > _______________________________________________<br>
>><br>
>><br>
>> Yes, this is what Vitaly stated and what happens behind the curtains.<br>
>><br>
>> In the end, this means there are no chances for the rest of us to<br>
>> implement better Java code as a replacement for the intrinsified<br>
>> methods.<br>
>><br>
>> For example, the following variant is about 2.5 times *faster*,<br>
>> averaged over all integers, than the JITted original method, the one<br>
>> copied verbatim! (Besides, everybody would agree that it is more<br>
>> readable, I hope.)<br>
>><br>
>> But since the Integer version is intrinsified, it still runs about 2<br>
>> times slower than that (mysterious) code.<br>
>><br>
>> public static int numberOfTrailingZeros(int i) {<br>
>> int n = 0;<br>
>> for (; n < 32 && (i & 1 << n) == 0; ++n);<br>
>> return n;<br>
>> }<br>
>> _______________________________________________<br>
>> mlvm-dev mailing list<br>
>> <a href="mailto:mlvm-dev@openjdk.java.net" target="_blank">mlvm-dev@openjdk.java.net</a><br>
>> <a href="http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> mlvm-dev mailing list<br>
> <a href="mailto:mlvm-dev@openjdk.java.net" target="_blank">mlvm-dev@openjdk.java.net</a><br>
> <a href="http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev</a><br>
><br>
_______________________________________________<br>
mlvm-dev mailing list<br>
<a href="mailto:mlvm-dev@openjdk.java.net" target="_blank">mlvm-dev@openjdk.java.net</a><br>
<a href="http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev</a><br>
</blockquote></div>