Re: Performance Update
Christian Thalinger wrote: >> No, you don't. On Ubuntu it should be as easy as: >> >> $ setarch i386 make > > Yeah, right :-/ I'm still trying to get it fully built, but I'm almost > there. At least you need the ia32-libs package and a few others (mostly > X, if not already installed). > > Furthermore there are patches required. I will post them here and will > try to push them to the appropriate repositories. Hopefully only > another couple of hours... :-) Sorry, I got sidetracked. Here is a patch that should enable 32-bit builds in 64-bit Linux environments. I will split it and post it to build-dev and bsd-port-dev later. Let me know if it works. -- Christian diff --git a/make/common/Defs-linux.gmk b/make/common/Defs-linux.gmk --- a/make/common/Defs-linux.gmk +++ b/make/common/Defs-linux.gmk @@ -109,9 +109,11 @@ #We need this frame pointer to make it easy to walk the stacks. #This should be the default on X86, but ia64 and amd64 may not have this #as the default. -CFLAGS_REQUIRED_amd64 += -fno-omit-frame-pointer -D_LITTLE_ENDIAN -CFLAGS_REQUIRED_i586+= -fno-omit-frame-pointer -D_LITTLE_ENDIAN +CFLAGS_REQUIRED_amd64 += -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN +CFLAGS_REQUIRED_i586+= -m32 -fno-omit-frame-pointer -D_LITTLE_ENDIAN CFLAGS_REQUIRED_ia64+= -fno-omit-frame-pointer -D_LITTLE_ENDIAN +LDFLAGS_COMMON_amd64+= -m64 +LDFLAGS_COMMON_i586 += -m32 CFLAGS_REQUIRED_sparcv9 += -m64 -mcpu=v9 LDFLAGS_COMMON_sparcv9 += -m64 -mcpu=v9 CFLAGS_REQUIRED_sparc += -m32 -mcpu=v9 diff --git a/src/share/native/com/sun/java/util/jar/pack/main.cpp b/src/share/native/com/sun/java/util/jar/pack/main.cpp --- a/src/share/native/com/sun/java/util/jar/pack/main.cpp +++ b/src/share/native/com/sun/java/util/jar/pack/main.cpp @@ -24,8 +24,6 @@ */ #ifdef _ALLBSD_SOURCE #include -#else -#include #endif #include diff --git a/src/share/native/java/lang/fdlibm/include/fdlibm.h b/src/share/native/java/lang/fdlibm/include/fdlibm.h --- a/src/share/native/java/lang/fdlibm/include/fdlibm.h +++ b/src/share/native/java/lang/fdlibm/include/fdlibm.h @@ -27,7 +27,6 @@ #ifdef __OpenBSD__ #include #endif -#include #include "jfdlibm.h" #ifdef __NEWVALID /* special setup for Sun test regime */ diff --git a/src/share/native/sun/awt/medialib/mlib_image.h b/src/share/native/sun/awt/medialib/mlib_image.h --- a/src/share/native/sun/awt/medialib/mlib_image.h +++ b/src/share/native/sun/awt/medialib/mlib_image.h @@ -30,7 +30,6 @@ #ifdef __OpenBSD__ #include #endif -#include #include #include diff --git a/src/solaris/back/util_md.h b/src/solaris/back/util_md.h --- a/src/solaris/back/util_md.h +++ b/src/solaris/back/util_md.h @@ -31,7 +31,6 @@ #include #include -#include #ifdef _LP64 typedef unsigned long UNSIGNED_JLONG; ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Christian Thalinger wrote: > Jochen Theodorou wrote: >> Christian Thalinger schrieb: >>> Jochen Theodorou wrote: I managed to do the 64bit build, but I did not yet do the 32bit build, because not only do I need the jvm in 32bit, I also need all dependencies in 32bit. But if it is easy I would like you to help me of course >>> What system are you building on? I'm currently trying myself to get a >>> 32-bit build in Ubuntu running in VirtualBox. >> currently I am running 64bit Ubuntu. So I need a 32bit system? Because >> it did sound different before > > No, you don't. On Ubuntu it should be as easy as: > > $ setarch i386 make Yeah, right :-/ I'm still trying to get it fully built, but I'm almost there. At least you need the ia32-libs package and a few others (mostly X, if not already installed). Furthermore there are patches required. I will post them here and will try to push them to the appropriate repositories. Hopefully only another couple of hours... :-) -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Jochen Theodorou wrote: > Christian Thalinger schrieb: >> Jochen Theodorou wrote: >>> I managed to do the 64bit build, but I did not yet do the 32bit build, >>> because not only do I need the jvm in 32bit, I also need all >>> dependencies in 32bit. But if it is easy I would like you to help me of >>> course >> What system are you building on? I'm currently trying myself to get a >> 32-bit build in Ubuntu running in VirtualBox. > > currently I am running 64bit Ubuntu. So I need a 32bit system? Because > it did sound different before No, you don't. On Ubuntu it should be as easy as: $ setarch i386 make -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Christian Thalinger schrieb: > Jochen Theodorou wrote: >> I managed to do the 64bit build, but I did not yet do the 32bit build, >> because not only do I need the jvm in 32bit, I also need all >> dependencies in 32bit. But if it is easy I would like you to help me of >> course > > What system are you building on? I'm currently trying myself to get a > 32-bit build in Ubuntu running in VirtualBox. currently I am running 64bit Ubuntu. So I need a 32bit system? Because it did sound different before bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Jochen Theodorou wrote: > I managed to do the 64bit build, but I did not yet do the 32bit build, > because not only do I need the jvm in 32bit, I also need all > dependencies in 32bit. But if it is easy I would like you to help me of > course What system are you building on? I'm currently trying myself to get a 32-bit build in Ubuntu running in VirtualBox. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Christian Thalinger schrieb: > Christian Thalinger wrote: >> Guillaume Laforge wrote: >>> On Tue, Jul 14, 2009 at 12:19, Christian >>> Thalinger wrote: Jochen Theodorou wrote: > show if it is worth the effort. Well.. cannot use invokedynamic on my > machine yet... Why is that? >>> Only x86 / 32bit if I recall correctly. >>> Not yet working on AMD 64bit. >> That's true, but you can build 32-bit binaries on 64-bit machines and >> run them. > > ...and I would be glad to help you get it running. I managed to do the 64bit build, but I did not yet do the 32bit build, because not only do I need the jvm in 32bit, I also need all dependencies in 32bit. But if it is easy I would like you to help me of course bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Christian Thalinger schrieb: > Jochen Theodorou wrote: >> show if it is worth the effort. Well.. cannot use invokedynamic on my >> machine yet... > > Why is that? that is because I have not yet setup a 32bit env only to test the JVM bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Christian Thalinger wrote: > Guillaume Laforge wrote: >> On Tue, Jul 14, 2009 at 12:19, Christian >> Thalinger wrote: >>> Jochen Theodorou wrote: show if it is worth the effort. Well.. cannot use invokedynamic on my machine yet... >>> Why is that? >> Only x86 / 32bit if I recall correctly. >> Not yet working on AMD 64bit. > > That's true, but you can build 32-bit binaries on 64-bit machines and > run them. ...and I would be glad to help you get it running. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Guillaume Laforge wrote: > On Tue, Jul 14, 2009 at 12:19, Christian > Thalinger wrote: >> Jochen Theodorou wrote: >>> show if it is worth the effort. Well.. cannot use invokedynamic on my >>> machine yet... >> Why is that? > > Only x86 / 32bit if I recall correctly. > Not yet working on AMD 64bit. That's true, but you can build 32-bit binaries on 64-bit machines and run them. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
On Tue, Jul 14, 2009 at 12:19, Christian Thalinger wrote: > Jochen Theodorou wrote: >> show if it is worth the effort. Well.. cannot use invokedynamic on my >> machine yet... > > Why is that? Only x86 / 32bit if I recall correctly. Not yet working on AMD 64bit. -- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Jochen Theodorou wrote: > show if it is worth the effort. Well.. cannot use invokedynamic on my > machine yet... Why is that? -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
On 07/13/2009 01:38 PM, John Rose wrote:
> 3. Make some cases of boxing/unboxing optimizable, by including strong
> escape analysis in the JIT, including Integer.valueOf. This point
> only applies to JVMs with full-power JITs, and requires some special
> pleading for Integer.valueOf, because of its interning behavior.
I think a good start would be escape *annotations*. The idea is that
either a library writer (human) or a compiler can emit @NonEscape
annotates on certain method parameters. Verifying @NonEscape can
be done locally, and hence much more cheaply - even potentially
by less powerful VMs, as on a mobile device.
Here is a strawman proposal I wrote up:
It seems much simpler if @NonEscape is an annotation that the
(library) programmer *explicitly* adds. That makes it part of the
actual ABI of a method, which means a VM can throw a link-time
exception if the annotation "lies". This should be much simpler
so that even a relatively simple VM can implement it.
For the sake of discussion, I'll use @NonEscape as a new anotation
which may be applied to method parameters. It means that the
parameter *may* refer to a stack-allocated object. It can also be
applied to a non-static method, in which case it applies to the
implicit 'this' parameter.
@NonEscape put certain (enforced) restrictions on how a variable is
used. A field can be selected from it. It can be passed as a
parameter, but only if the parameter is @NonEscape. Methods can be
called, but only methods where the 'this' parameter has the @NonEscape
property. No other use of a NonEscape variable is allowed. You
cannot compare it using ==, only by calling (non-default) equals.
You cannot store the variable in a field, nor in an array.
For simplicity, @NonEscape is only allowed on variables that have a
final class type. This allows the object header to be elided, since
we know statically the class of the referenced object.
These restrictions should be easy to check by javac
(or other static compilers), and also the run-time
verifier. (Ideally we want to do both, but the javac
changes are less urgent.)
Consider a local variable:
Complex z = new Complex();
If z satisfies the requirements of a @NonEscape
variable, then we can stack-allocate the
constructed Complex. Or allocate its various
fields in separate registers.
We can explicitly annotate z:
@NonEscape Complex z = new Complex();
This can allow javac to check the programmer's intent. However, note
that (unless I'm missing something) annotations on local variables are
not (in Java6) written to the class files. Hence, unless we extend
the class file format with a new attribute, the VM can't count on this
annotation. But that's probably OK: It more convenient for
programmers to not have to annotate local variables, and it seems
fairly easy for the VM to infer whether a local variable is
non-escaping. That way applications writers don't have to write
@NonEscape annotative, but can still get the performance benefit of
libraries using @NonEscape annotations.
This allows for efficient but verbose code. For example:
public final class Complex {
double re, im;
public static void negate(@NonEscape Complex arg, @NonEscape Complex
result) {
result.re = -arg.re;
result.un = -arg.im;
}
...
}
Using it:
Complex z = new Complex();
...;
Complex zneg = new Complex();
Complex.negate(z, zneg);
Ultimately, we'd like:
zneg = - z;
but just getting rid of the explicit temporaries would help:
Complex zneg = Complex.negate(z);
We can do that with a simple convention. Change the
definition of Complex to:
public final class Complex {
double re, im;
public static void negate$F(@Result Complex result, @NonEscape
Complex arg) {
result.re = -arg.re;
result.un = -arg.im;
}
...
}
Note the "$F" suffix, which is used for new "calling convention".
Note also the new @Result annotation, which extends (subsumes)
@NonEscape, but indicates the "function result". (The @Result
parameter is first, so we can handle varargs methods.)
Now the compiler can translate:
Complex zneg = Complex.negate(z);
to:
Complex zneg = new Complex();
Complex.negate$F(zneg, z);
This gets more interesting with compound expressions:
Complex r = Complex.add(Compile.mul(a, b), c)
would be syntactic sugar for:
@NonEscape Complex temp1 = new Complex();
Complex.mul$F(temp1, a, b);
Complex r = new Complex();
Complex.mul$F(r, temp1, c);
Note that the generated .class files would be
portable even to "legacy" JVMs. However, JVMs
that make use of @NonEscape annotations can
compile the methods to more efficient code.
Clearly, this isn't a precise enough design, but
perhaps it can be the start of something workable.
I think it's important to try it. If this is a dead
end that has been explored and found unworkable or
too difficult, I'd like to know that.
Possible extensions to consider beyond the basic idea:
* Infix operators: 'x + y'
Re: Performance Update
Sorry for that. The dump is probably too big to be a snippet, so it has been deleted. You can get the dump file here: http://files.getdropbox.com/u/381580/mlvm/fib_filtred_asm.dump Chanwit On Mon, Jul 13, 2009 at 22:45, Jochen Theodorou wrote: > Chanwit Kaewkasi schrieb: > [...] >> A very long listing of disassembled Fibonacci is here: >> http://pastebin.com/dfd44507 > > looks like it is no longer available > > bye Jochen > > -- > Jochen "blackdrag" Theodorou > The Groovy Project Tech Lead (http://groovy.codehaus.org) > http://blackdragsview.blogspot.com/ > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Chanwit Kaewkasi PhD Candidate, Centre for Novel Computing School of Computer Science The University of Manchester Oxford Road Manchester M13 9PL, UK ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Chanwit Kaewkasi schrieb: [...] > A very long listing of disassembled Fibonacci is here: > http://pastebin.com/dfd44507 looks like it is no longer available bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
John Rose schrieb: > On Jul 13, 2009, at 12:04 PM, Jochen Theodorou wrote: > >> [boxing] is a problem we should discuss for invokedynamic in more >> depth. >> Especially how to go around that problem to get maximum performance. >> What do you think? > > I might be missing your point, Jochen, but I think we need a three- > point approach: my point is, that in a a=b+c (all being int or Integer) Groovy is currently having two Integer, that are used to call a plus method, which unboxes those and boxes the result again to have an return value. Compared to the usage of Integer this means two times unboxing, and one time boxing. Compared with native ints this means two times boxing for the method call, two times unboxing for the normal plus, one time boxing for the result and one time unboxing for the variable. That is 3 times unboxing and boxing that reduce performance quite a bit. Assuming the unboxing is not expensive, that leaves 3 boxing actions. Using Integer this is still 1 boxing action. I have plans for Groovy to let it use primitive ints with a primitve int using plus method or even direct bytecode to make groovy faster for those things. But that decision also depends a bit on how invokedynamic will proceed. > 1. Make boxing/unboxing less common, by supporting primitives in JSR > 292. This point applies to all sizes and shapes of JVMs. It requires > more smarts in the language implementation, but some languages (e.g., > CAL) already optimize primitive arguments, since the JVM rewards it. > > 2. Make some cases of boxing/unboxing cheaper, by supporting fixnums. > This point applies to all sorts of JVMs, but is not widely in use. > There is an empty mlvm project for this, and it will probably see some > activity, at least for Integer.valueOf specifically. (Any takers?) > > 3. Make some cases of boxing/unboxing optimizable, by including strong > escape analysis in the JIT, including Integer.valueOf. This point > only applies to JVMs with full-power JITs, and requires some special > pleading for Integer.valueOf, because of its interning behavior. Hmm maybe here the tight integration with java becomes a problem. We have all the interger types Java has too, and they have the same meaning. The goal is to reach the same (well almost) performance as native Java of course. Any boxing/unboxing there will have a very negative effect on the performance level. Way 3 could be the most easy way for us, but it depends on the actual usage. If we had to move our object based math to primitive type math, we would have loads of additional code in the groovy runtime for special cases, but then we can avoid boxing completely, so we would not really need that way anyway. The downside, that we cannot use invokeDynamic here is of course still there. A sample implementation would have to show if it is worth the effort. Well.. cannot use invokedynamic on my machine yet... Way 2 is a big change and I am not yet sure how much of it can be used. Assuming Fixnums are kind of objects, then we have to provide additional type information since those fixnums would represent chars, bytes, ints and longs at the same time. To say the truth, I cannot yet imagine the actual usage at the moment very much, so nor sure about the real restrictions. Also if we have to "create" a fixnum with the same costs as an object, then it is probably not worth the effort, since a a+b would then involve creating a new fixnum. Even if that costs only as much as creating an Integer using valueOf (which makes not really a big difference on my machine) it is not worth the effort. It has to be cheaper, preferable much cheaper. But even then we may decide to change to native math, since that is still faster. So it needs to be just as fast, including the JIT inlingin and replacing code! For way 1 I thought that maybe multiple boostrap methods will be supported, so whatever is needed can be used. Not sure if that would be a big project. bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
On Jul 13, 2009, at 12:04 PM, Jochen Theodorou wrote: > [boxing] is a problem we should discuss for invokedynamic in more > depth. > Especially how to go around that problem to get maximum performance. > What do you think? I might be missing your point, Jochen, but I think we need a three- point approach: 1. Make boxing/unboxing less common, by supporting primitives in JSR 292. This point applies to all sizes and shapes of JVMs. It requires more smarts in the language implementation, but some languages (e.g., CAL) already optimize primitive arguments, since the JVM rewards it. 2. Make some cases of boxing/unboxing cheaper, by supporting fixnums. This point applies to all sorts of JVMs, but is not widely in use. There is an empty mlvm project for this, and it will probably see some activity, at least for Integer.valueOf specifically. (Any takers?) 3. Make some cases of boxing/unboxing optimizable, by including strong escape analysis in the JIT, including Integer.valueOf. This point only applies to JVMs with full-power JITs, and requires some special pleading for Integer.valueOf, because of its interning behavior. -- John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Chanwit Kaewkasi schrieb: > Using the debug build and base_hsdis, the code seems to be more > understandable to me. > > For the Fibonacci program, inlining is working great. Numerical > runtime methods, i.e. plus and minus, has been inlined into a compiled > method of Fib.fib. > > However, a lot of boxing/unboxing pairs are still there. This is not a > surprise because the JIT does not seem to have knowledge about the > runtime methods of G7 (of course, for runtime of any other languages > as well). But it would be really great if we can add some knowledge to > JIT to optimize away these boxing/unboxing pairs. > > A very long listing of disassembled Fibonacci is here: > http://pastebin.com/dfd44507 I tend to think that: > On Wed, Jul 8, 2009 at 9:01 PM, Chanwit Kaewkasi wrote: >> On Wed, Jul 8, 2009 at 8:50 PM, Jochen Theodorou wrote: >>> Chanwit Kaewkasi schrieb: [...] >> Currently the bootstrap in G7 does not support primitives, so this is >> possibly true. is a problem we should discuss for invokedynamic in more depth. Especially how to go around that problem to get maximum performance. What do you think? bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Using the debug build and base_hsdis, the code seems to be more understandable to me. For the Fibonacci program, inlining is working great. Numerical runtime methods, i.e. plus and minus, has been inlined into a compiled method of Fib.fib. However, a lot of boxing/unboxing pairs are still there. This is not a surprise because the JIT does not seem to have knowledge about the runtime methods of G7 (of course, for runtime of any other languages as well). But it would be really great if we can add some knowledge to JIT to optimize away these boxing/unboxing pairs. A very long listing of disassembled Fibonacci is here: http://pastebin.com/dfd44507 Cheers, Chanwit On Wed, Jul 8, 2009 at 9:01 PM, Chanwit Kaewkasi wrote: > On Wed, Jul 8, 2009 at 8:50 PM, Jochen Theodorou wrote: >> Chanwit Kaewkasi schrieb: >>> Hi all, >>> >>> I have re-run a Fibonacci benchmark generated by my G7 compiler on the >>> latest mlvm build (also with indy.compiler and indy.compiler.inline >>> patches). >>> And the performance is incredible !!! >>> >>> [r...@andlinux g7]# time `java -cp >>> .:target/classes/:target/test-classes -server -XX:+EnableInvokeDynamic >>> g7.tests.classgen.Fib` >>> >>> real 0m2.230s >>> user 0m1.940s >>> sys 0m0.250s >>> >>> It's very close to *native Java* now, if I correctly remember the figure. >> >> from looking at the produced bytecode you did show I assume there is >> still some potential if boxing of int can be avoided. > > Currently the bootstrap in G7 does not support primitives, so this is > possibly true. > >> Or is that >> optimized away? > > Really do not know what's happening behind the scene. It would be > great if I could be able to dump and see the optimized native codes. > > Cheers, > > Chanwit > >> bye Jochen >> >> -- >> Jochen "blackdrag" Theodorou >> The Groovy Project Tech Lead (http://groovy.codehaus.org) >> http://blackdragsview.blogspot.com/ >> >> ___ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > > > -- > Chanwit Kaewkasi > PhD Candidate, > Centre for Novel Computing > School of Computer Science > The University of Manchester > Oxford Road > Manchester > M13 9PL, UK > -- Chanwit Kaewkasi PhD Candidate, Centre for Novel Computing School of Computer Science The University of Manchester Oxford Road Manchester M13 9PL, UK ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Thank you very much, Christian and John. On Fri, Jul 10, 2009 at 7:46 PM, John Rose wrote: > See also http://wikis.sun.com/display/HotSpotInternals/PrintAssembly . > The plugin required is available (mainly in source form) in a couple > of places; one is http://kenai.com/projects/base-hsdis > Example output is at http://gist.github.com/144362 > > -- John > > On Jul 10, 2009, at 8:36 AM, Christian Thalinger wrote: > >> Chanwit Kaewkasi wrote: Or is that optimized away? >>> >>> Really do not know what's happening behind the scene. It would be >>> great if I could be able to dump and see the optimized native codes. >> >> If you have a debug build you can use -XX:+PrintOptoAssembly (so you >> don't have to build hsdis). It's actually not a real disassembly, but >> it's close. >> >> -- Christian >> ___ >> 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 > -- Chanwit Kaewkasi PhD Candidate, Centre for Novel Computing School of Computer Science The University of Manchester Oxford Road Manchester M13 9PL, UK ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
See also http://wikis.sun.com/display/HotSpotInternals/PrintAssembly . The plugin required is available (mainly in source form) in a couple of places; one is http://kenai.com/projects/base-hsdis Example output is at http://gist.github.com/144362 -- John On Jul 10, 2009, at 8:36 AM, Christian Thalinger wrote: > Chanwit Kaewkasi wrote: >>> Or is that >>> optimized away? >> >> Really do not know what's happening behind the scene. It would be >> great if I could be able to dump and see the optimized native codes. > > If you have a debug build you can use -XX:+PrintOptoAssembly (so you > don't have to build hsdis). It's actually not a real disassembly, but > it's close. > > -- Christian > ___ > 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
Re: Performance Update
Chanwit Kaewkasi wrote: >> Or is that >> optimized away? > > Really do not know what's happening behind the scene. It would be > great if I could be able to dump and see the optimized native codes. If you have a debug build you can use -XX:+PrintOptoAssembly (so you don't have to build hsdis). It's actually not a real disassembly, but it's close. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
On Wed, Jul 8, 2009 at 8:50 PM, Jochen Theodorou wrote: > Chanwit Kaewkasi schrieb: >> Hi all, >> >> I have re-run a Fibonacci benchmark generated by my G7 compiler on the >> latest mlvm build (also with indy.compiler and indy.compiler.inline >> patches). >> And the performance is incredible !!! >> >> [r...@andlinux g7]# time `java -cp >> .:target/classes/:target/test-classes -server -XX:+EnableInvokeDynamic >> g7.tests.classgen.Fib` >> >> real 0m2.230s >> user 0m1.940s >> sys 0m0.250s >> >> It's very close to *native Java* now, if I correctly remember the figure. > > from looking at the produced bytecode you did show I assume there is > still some potential if boxing of int can be avoided. Currently the bootstrap in G7 does not support primitives, so this is possibly true. > Or is that > optimized away? Really do not know what's happening behind the scene. It would be great if I could be able to dump and see the optimized native codes. Cheers, Chanwit > bye Jochen > > -- > Jochen "blackdrag" Theodorou > The Groovy Project Tech Lead (http://groovy.codehaus.org) > http://blackdragsview.blogspot.com/ > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Chanwit Kaewkasi PhD Candidate, Centre for Novel Computing School of Computer Science The University of Manchester Oxford Road Manchester M13 9PL, UK ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Chanwit Kaewkasi schrieb: > Hi all, > > I have re-run a Fibonacci benchmark generated by my G7 compiler on the > latest mlvm build (also with indy.compiler and indy.compiler.inline > patches). > And the performance is incredible !!! > > [r...@andlinux g7]# time `java -cp > .:target/classes/:target/test-classes -server -XX:+EnableInvokeDynamic > g7.tests.classgen.Fib` > > real 0m2.230s > user 0m1.940s > sys 0m0.250s > > It's very close to *native Java* now, if I correctly remember the figure. from looking at the produced bytecode you did show I assume there is still some potential if boxing of int can be avoided. Or is that optimized away? bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Chanwit Kaewkasi wrote: > Hi Christian, > >>> It's very close to *native Java* now, if I correctly remember the figure. >> That's good news! Guessing this is a product build, could you time a >> run it with -XX:-Inline to see if your methods are inlined (with a debug >> build you could do a -XX:+PrintInlining)? > > Yes, it's inlined. Congratulations !! > > Without inlining, it's back to be around 10 secs. Pheew :-) -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Hi Christian, >> >> It's very close to *native Java* now, if I correctly remember the figure. > > That's good news! Guessing this is a product build, could you time a > run it with -XX:-Inline to see if your methods are inlined (with a debug > build you could do a -XX:+PrintInlining)? Yes, it's inlined. Congratulations !! Without inlining, it's back to be around 10 secs. [r...@andlinux g7]# time `java -cp .:target/classes/:target/test-classes -server -XX:-Inline -XX:+EnableInvokeDynamic g7.tests.classgen.Fib` real0m10.430s user0m10.180s sys 0m0.210s Best regards, Chanwit -- Chanwit Kaewkasi PhD Candidate, Centre for Novel Computing School of Computer Science The University of Manchester Oxford Road Manchester M13 9PL, UK ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Performance Update
Chanwit Kaewkasi wrote: > Hi all, > > I have re-run a Fibonacci benchmark generated by my G7 compiler on the > latest mlvm build (also with indy.compiler and indy.compiler.inline > patches). > And the performance is incredible !!! > > [r...@andlinux g7]# time `java -cp > .:target/classes/:target/test-classes -server -XX:+EnableInvokeDynamic > g7.tests.classgen.Fib` > > real 0m2.230s > user 0m1.940s > sys 0m0.250s > > It's very close to *native Java* now, if I correctly remember the figure. That's good news! Guessing this is a product build, could you time a run it with -XX:-Inline to see if your methods are inlined (with a debug build you could do a -XX:+PrintInlining)? -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Performance Update
Hi all, I have re-run a Fibonacci benchmark generated by my G7 compiler on the latest mlvm build (also with indy.compiler and indy.compiler.inline patches). And the performance is incredible !!! [r...@andlinux g7]# time `java -cp .:target/classes/:target/test-classes -server -XX:+EnableInvokeDynamic g7.tests.classgen.Fib` real0m2.230s user0m1.940s sys 0m0.250s It's very close to *native Java* now, if I correctly remember the figure. Best regards, Chanwit ps. It's the same program I posted here last time: http://gist.github.com/133661 -- Chanwit Kaewkasi PhD Candidate, Centre for Novel Computing School of Computer Science The University of Manchester Oxford Road Manchester M13 9PL, UK ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
