Re: [Mono-list] Re: The Mauve unicode testcase and VM performance
Below... On Wed, 2004-04-14 at 10:30, Anthony Green wrote: On Tue, 2004-04-13 at 15:08, Jonathan Pryor wrote: AOT (or pre-JITing) assemblies is not as useful as you'd think. It has two primary effects: - Reduce memory requirements, as memory doesn't need to be allocated for the JITed code - Decrease startup time, as (again) the JITing doesn't need to be done. Are you saying that mono doesn't have the ability to create shared libraries? How did you get that interpretation from my statements? It boggles my mind... Mono AOT creates shared libraries. That's how startup time is reduced -- the shared libraries contain the AOT code, so the code doesn't need to be JITted. - Jon ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Mono-list] Re: The Mauve unicode testcase and VM performance
No, he is not. YOu can run mono -O=shared my.exe or, if you would like to aot: mono -O=shared --aot my.exe However, as miguel stated earlier, the need for shared code is very rare. What shared means here is that the same code can be used by multiple appdomains (look that up if you are not familar with the .NET appdomain system). The use of this functionality is pretty rare, the only example I can think of is ASP.net. -- Ben Anthony Green [EMAIL PROTECTED] 04/15/04 04:21 AM On Tue, 2004-04-13 at 15:08, Jonathan Pryor wrote: AOT (or pre-JITing) assemblies is not as useful as you'd think. It has two primary effects: - Reduce memory requirements, as memory doesn't need to be allocated for the JITed code - Decrease startup time, as (again) the JITing doesn't need to be done. Are you saying that mono doesn't have the ability to create shared libraries? AG -- Anthony Green [EMAIL PROTECTED] Red Hat, Inc. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Mono-list] Re: The Mauve unicode testcase and VM performance
On Wed, 2004-04-14 at 19:47, Jonathan Pryor wrote: Below... On Wed, 2004-04-14 at 10:30, Anthony Green wrote: On Tue, 2004-04-13 at 15:08, Jonathan Pryor wrote: AOT (or pre-JITing) assemblies is not as useful as you'd think. It has two primary effects: - Reduce memory requirements, as memory doesn't need to be allocated for the JITed code - Decrease startup time, as (again) the JITing doesn't need to be done. Are you saying that mono doesn't have the ability to create shared libraries? How did you get that interpretation from my statements? It boggles my mind... Because you didn't mention the key advantage that you get from AOT-compiled shared libraries: saving memory from sharing library code between processes. You're only two points were about saving time and memory from not having to JIT compile code. AG -- Anthony Green [EMAIL PROTECTED] Red Hat, Inc. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Mono-list] Re: The Mauve unicode testcase and VM performance
Hello, Because you didn't mention the key advantage that you get from AOT-compiled shared libraries: saving memory from sharing library code between processes. You're only two points were about saving time and memory from not having to JIT compile code. Ah, that is correct, and I had at least completely ignored that fact. Using --aot will indeed use shared mapping between various Mono processes, so it is an extra advantage. Miguel ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
Sigh. Building a development version of Jikes RVM is pretty stressful on the hosting VM. It's found bugs in more than one product VM in the past. This looks like one of the nastier forms; the host VM managed to write the RVM.image file without any obvious error, but the image file is slightly wrong with the result being that Jikes RVM crashes some of the time when you try to run it. I know Steve Augart was looking into a similar failure last week, but it's often a long and painful process unless one can get lucky (especially as building the development image on kaffe is _slow_ so the turnaround time for each injecting of debugging code is a couple of hours). I'm sure this will work eventually, but maybe stick with prototype versions of Jikes RVM for now. --dave Created a development build and tried it. But... $ time echo gnu.testlet.java.lang.Character.unicode | ~/src/rvm/bin/rvm gnu.testlet.SimpleTestHarness -debug Reading unicode database... OPT_Compiler failure during compilation of gnu.testlet.java.lang.Character.UnicodeBase.getNext (Ljava/io/Reader;)Ljava/lang/String; Ljava/lang/ClassCastException; VM_StackTrace.print(): *UNEXPECTED* Throwable while displaying stack trace # 24 The Throwable was: Ljava/lang/NullPointerException; VM_StackTrace.print(): And its stack trace was: Ljava/lang/NullPointerException;___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Mono-list] Re: The Mauve unicode testcase and VM performance
On Tue, 2004-04-13 at 15:08, Jonathan Pryor wrote: AOT (or pre-JITing) assemblies is not as useful as you'd think. It has two primary effects: - Reduce memory requirements, as memory doesn't need to be allocated for the JITed code - Decrease startup time, as (again) the JITing doesn't need to be done. Are you saying that mono doesn't have the ability to create shared libraries? AG -- Anthony Green [EMAIL PROTECTED] Red Hat, Inc. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Mono-list] Re: The Mauve unicode testcase and VM performance
Hello, snip/ Interestingly, my installation of mono (from debian sid) doesn't even come with its own libraries AOT'd. I'd have thought that you'd get the best performance by AOT'ing *all* the libraries, including (and especially) the low-level platform ones such as System.dll and System.Xml.dll. AOT (or pre-JITing) assemblies is not as useful as you'd think. It has two primary effects: - Reduce memory requirements, as memory doesn't need to be allocated for the JITed code - Decrease startup time, as (again) the JITing doesn't need to be done. Another effect is that you can run the most time consuming optimizations on those assemblies. For example, using AOT with -O=all on mcs.exe gives about 15% performance increase: mono --aot -O=all /usr/bin/mcs.exe If you also apply this to mscorlib and System, you get another 7-12%. Useful when you are doing a lot of compilations. Miguel ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: The Mauve unicode testcase and VM performance
Stuart Ballard wrote: Mark Wielaard wrote: and overhead. Hope I have time next week to update it with at least rvm development results and maybe IKVM ahead of time results (Jeroen, any hints on how to do that in this case?) I don't know whether you have a zip/jar or individual classfiles but assuming it's a single jar file, presumably it would be (commands separated by blank lines - ignore any mailer-induced wordwrapping): mono ikvmc.exe -target:exe -out:mauve.exe -reference:classpath.dll -main:gnu.testlet.SimpleTestHarness mauve.jar This is what I did: #cd mauve #mono ../ikvm/bin/ikvmc.exe -out:mauve.exe -main:gnu.testlet.SimpleTestHarness `find | grep -v altered | grep .*class$` -reference:../ikvm/bin/classpath.dll #cp ../ikvm/bin/*.dll . #time echo gnu.testlet.java.lang.Character.unicode | mono mauve.exe -debug Reading unicode database... done Benchmark : load:2151ms tests:328ms 0 of 3578944 tests failed real0m2.979s user0m0.030s sys 0m0.050s On Windows I got: C:\mauveecho gnu.testlet.java.lang.Character.unicode| mono mauve.exe -debug Reading unicode database... done Benchmark : load:1763ms tests:731ms 0 of 3578944 tests failed C:\mauveecho gnu.testlet.java.lang.Character.unicode| mauve.exe -debug Reading unicode database... done Benchmark : load:180ms tests:170ms 0 of 3578944 tests failed C:\mauveecho gnu.testlet.java.lang.Character.unicode| ikvm gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:180ms tests:170ms 0 of 3578944 tests failed So for the run time it doesn't make any difference if it is precompiled or not, total time is a bit longer though (about 1.5 second versus 1.0 seconds). Note also that IKVM running on the Microsoft framework is faster than Hotspot (but overall elapsed time for Hotspot is less, about 0.7 seconds): C:\mauveecho gnu.testlet.java.lang.Character.unicode| \j2re1.4.1\bin\java gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:220ms tests:250ms 0 of 3578944 tests failed All tests are on a 1.7 GHz Pentium M, the Linux test was running in a VMWare session. The other thing to try would be using Mono's --aot option to pre-JIT (as it were) the generated exe and dlls. I couldn't get that to work. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
Mark Wielaard wrote: You then still need the original exe for execution. The man page says about --aot: This option is used to precompile the CIL code in the specified assembly to native code. The generated code is stored in a file with the extension .so. This file will be automatically picked up by the runtime when the assembly is executed. This pre-compiles the methods, but the original assembly is still required to execute as this one contains the metadata and exception information which is not availble on the generated file. When precompiling code, you might want to compile with all optimizations (-O=all). Pre-compiled code is position inde- pendent code. load test overhead total Old: 1703 1292 3174 6169 New: 2944 1337 624 4905 Oat: 2944 1312 626 4882 So that doesn't seem to help in this case (or I did something wrong and it isn't picking up the mauve.exe.so after all). Did you try --aot'ing classpath.dll, IK.VM.NET.dll etc? I'd imagine that this particular microbenchmark spends a large proportion of its time inside classpath itself, suggesting that merely JITing the mauve part wouldn't help much. The man page you cited says that --aot precompiles the CIL code in the specified assembly. In .NET terminology, each dll or exe is a separate assembly. So I take that doc to imply that you need to separately AOT each dll as well as the exe itself. Interestingly, my installation of mono (from debian sid) doesn't even come with its own libraries AOT'd. I'd have thought that you'd get the best performance by AOT'ing *all* the libraries, including (and especially) the low-level platform ones such as System.dll and System.Xml.dll. CC'ing mono-list for any insight they might have into why (or why not) you might want to AOT the platform libraries... Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
Hi, On Tue, 2004-04-13 at 20:55, Stuart Ballard wrote: Did you try --aot'ing classpath.dll, IK.VM.NET.dll etc? I'd imagine that this particular microbenchmark spends a large proportion of its time inside classpath itself, suggesting that merely JITing the mauve part wouldn't help much. Should have thought about that. Just tried it, but: $ for i in *.dll; do mono --aot -O=all $i; done Mono Ahead of Time compiler - compiling assembly OpenSystem.Java.dll Executing the native assembler: as /tmp/mono_aot_ZNn0Pd -o /tmp/mono_aot_ZNn0Pd.o Executing the native linker: ld -shared -o OpenSystem.Java.dll.so /tmp/mono_aot_ZNn0Pd.o Compiled 12 out of 12 methods (100%) 0 methods contain absolute addresses (0%) 0 methods contain wrapper references (0%) 0 methods contain lmf pointers (0%) 0 methods have other problems (0%) AOT RESULT 0 Mono Ahead of Time compiler - compiling assembly SharpZipLib.dll Executing the native assembler: as /tmp/mono_aot_SVrc0t -o /tmp/mono_aot_SVrc0t.o Executing the native linker: ld -shared -o SharpZipLib.dll.so /tmp/mono_aot_SVrc0t.o Compiled 508 out of 540 methods (94%) 31 methods contain absolute addresses (5%) 1 methods contain wrapper references (0%) 0 methods contain lmf pointers (0%) 0 methods have other problems (0%) AOT RESULT 0 Mono Ahead of Time compiler - compiling assembly awt.dll Executing the native assembler: as /tmp/mono_aot_DbmJ3s -o /tmp/mono_aot_DbmJ3s.o Executing the native linker: ld -shared -o awt.dll.so /tmp/mono_aot_DbmJ3s.o Compiled 320 out of 342 methods (93%) 0 methods contain absolute addresses (0%) 22 methods contain wrapper references (6%) 0 methods contain lmf pointers (0%) 0 methods have other problems (0%) AOT RESULT 0 Mono Ahead of Time compiler - compiling assembly classpath.dll Executing the native assembler: as /tmp/mono_aot_NrbGZa -o /tmp/mono_aot_NrbGZa.o Executing the native linker: ld -shared -o classpath.dll.so /tmp/mono_aot_NrbGZa.o Compiled 18338 out of 18766 methods (97%) 0 methods contain absolute addresses (0%) 428 methods contain wrapper references (2%) 0 methods contain lmf pointers (0%) 0 methods have other problems (0%) AOT RESULT 0 Mono Ahead of Time compiler - compiling assembly ik.vm.jni.dll ** ERROR **: file object.c: line 466 (mono_class_vtable): assertion failed: (fklass-byval_arg.type == MONO_TYPE_PTR) aborting... Aborted Mono Ahead of Time compiler - compiling assembly ik.vm.net.dll Executing the native assembler: as /tmp/mono_aot_PGuh22 -o /tmp/mono_aot_PGuh22.o Executing the native linker: ld -shared -o ik.vm.net.dll.so /tmp/mono_aot_PGuh22.o Compiled 1067 out of 1092 methods (97%) 0 methods contain absolute addresses (0%) 25 methods contain wrapper references (2%) 0 methods contain lmf pointers (0%) 0 methods have other problems (0%) AOT RESULT 0 [EMAIL PROTECTED]:~/src/mauve] $ time echo gnu.testlet.java.lang.Character.unicode | mono mauve.exe -debug Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for java.io.File --- System.TypeInitializationException: An exception was thrown by the type initializer for java.lang.System --- System.TypeInitializationException: An exception was thrown by the type initializer for gnu.java.io.EncodingManager --- System.TypeInitializationException: An exception was thrown by the type initializer for java.lang.Class --- System.ArrayTypeMismatchException: Source array type cannot be assigned to destination array type. in 0x000dc MethodDescriptor:FromMethodBase (System.Reflection.MethodBase) in 0x00011 CompiledTypeWrapper:CreateMethodWrapper (System.Reflection.MethodBase) in 0x000c9 CompiledTypeWrapper:LazyPublishMembers () in 0x00041 LazyTypeWrapper:Finish () in 0x0004d NativeCode.java.lang.VMClass:CreateClassInstance (TypeWrapper) in 0x00063 NativeCode.java.lang.VMClass:getClassFromWrapper (TypeWrapper) in 0x00022 NativeCode.java.lang.VMClass:getClassFromType (System.Type) in 0x00025 java.lang.Object:instancehelper_getClass (object) in 0x000cd java.security.Permissions:add (java.security.Permission) in 0x00055 java.lang.Class:.cctor () --- End of inner exception stack trace --- in 0x00429 gnu.java.io.EncodingManager:.cctor () --- End of inner exception stack trace --- in (unmanaged) gnu.java.io.EncodingManager:getEncoder (java.io.OutputStream) in 0x0003a java.io.OutputStreamWriter:.ctor (java.io.OutputStream) in 0x0003c java.io.PrintWriter:.ctor (java.io.OutputStream) in 0x00019 java.io.PrintWriter:.ctor (java.io.OutputStream,bool) in 0x00073 java.io.PrintStream:.ctor (java.io.OutputStream,bool) in 0x0006d java.lang.VMSystem:makeStandardOutputStream () in 0x00899 java.lang.System:.cctor () --- End of inner exception stack trace --- in (unmanaged) java.lang.System:getProperty (string) in 0x00010 java.io.File:.cctor () --- End of inner exception stack trace --- in (unmanaged) java.io.File:.ctor (string) in 0x0003e java.io.FileReader:.ctor (string) in 0x000bf gnu.testlet.SimpleTestHarness:.ctor (bool,bool,bool) in
Re: The Mauve unicode testcase and VM performance
Hi, On Mon, 2004-04-12 at 16:43, David P Grove wrote: Development Jikes RVM can take a while to build, but does buy some performance. Probably not worth it for classpath development or mauve tests, but if you want to run some apps it can pay off. I have prototype and development 2.3.2 images sitting around on my machine, so just for fun. Created a development build and tried it. But... $ time echo gnu.testlet.java.lang.Character.unicode | ~/src/rvm/bin/rvm gnu.testlet.SimpleTestHarness -debug Reading unicode database... OPT_Compiler failure during compilation of gnu.testlet.java.lang.Character.UnicodeBase.getNext (Ljava/io/Reader;)Ljava/lang/String; Ljava/lang/ClassCastException; VM_StackTrace.print(): *UNEXPECTED* Throwable while displaying stack trace # 24 The Throwable was: Ljava/lang/NullPointerException; VM_StackTrace.print(): And its stack trace was: Ljava/lang/NullPointerException; VM_StackTrace.print(): *UNEXPECTED* Throwable while displaying stack trace # 26 The Throwable was: Ljava/lang/NullPointerException; VM_StackTrace.print(): And its stack trace was: Ljava/lang/NullPointerException; VM_StackTrace.print(): *UNEXPECTED* Throwable while displaying stack trace # 27 The Throwable was: Ljava/lang/NullPointerException; VM_StackTrace.print(): And its stack trace was: We got 7 deep in printing stack traces; trouble. Aborting. JikesRVM: exit 99 This is a development build bootstrap with a prototype build which was build with kaffe 1.1.4 though. Some other mauve tests do run with it. Will post a bigger report to jikesrvnm-core later. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Mono-list] Re: The Mauve unicode testcase and VM performance
Below... On Tue, 2004-04-13 at 14:55, Stuart Ballard wrote: snip/ Interestingly, my installation of mono (from debian sid) doesn't even come with its own libraries AOT'd. I'd have thought that you'd get the best performance by AOT'ing *all* the libraries, including (and especially) the low-level platform ones such as System.dll and System.Xml.dll. AOT (or pre-JITing) assemblies is not as useful as you'd think. It has two primary effects: - Reduce memory requirements, as memory doesn't need to be allocated for the JITed code - Decrease startup time, as (again) the JITing doesn't need to be done. This isn't without consequence. Here are some highlights, but see Chris Brumme's blog[1] for *lots* of details: - Fewer opportunities to inline during the JIT, as many methods you'd like to inline will already have been compiled. - The real killer: AOT/pre-JIT code is AppDomain-neutral - Builds on the above inlining issue - Slows down access to class statics fields, as you need to go through an indirection (for AppDomain lookup) - The JIT can't emit a direct function call to AOT code You should (obviously) always run a performance analysis to see what the impacts of AOT/pre-JIT are, but the general consensus from the .NET developers is that it should be avoided unless you really can't afford the startup penalty or the memory requirements. Personally, I haven't had any problems with startup time under Mono, so I don't see the point in shipping AOT-compiled assemblies. - Jon [1] http://blogs.msdn.com/cbrumme/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
Hi, On Thu, 2004-04-08 at 18:44, Stephen Crawley wrote: The testcase now runs clean for JDK 1.4.2 as well as Kissme/Classpath from CVS. Thanks a lot for that! The interesting thing is that the test run 200 times faster with JDK 1.4.2 than with Kissme. Yes TWO HUNDRED TIMES! [...] Question: what figures do people get with other open source VMs? There are quite some differences between the free runtime environments. (Total) running time goes from 1.2 seconds (native gcj) to 1.5 minutes (kissme). This is on a AMD Athlon XP 1600+ (1.4 Ghz). Note the interesting differences between the load, test and total time. All times are best of three runs. (gij 3.3.3) $ time echo gnu.testlet.java.lang.Character.unicode | gij gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:1236ms tests:5646ms 0 of 3578944 tests failed real0m7.141s user0m6.687s sys 0m0.068s (Kissme from CVS a few weeks ago) $ time echo gnu.testlet.java.lang.Character.unicode | ~/src/kissme/useful_scripts/kissme gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:11434ms tests:81436ms 0 of 3578944 tests failed real1m33.086s user1m30.842s sys 0m0.499s (Native compiled mauve with gcj 3.3.3 -O2) $ time echo gnu.testlet.java.lang.Character.unicode | ./mauve-native -debug Reading unicode database... done Benchmark : load:594ms tests:386ms 0 of 3578944 tests failed real0m1.211s user0m0.906s sys 0m0.041s (prototype Jikes RVM 2.3.2, don't have a development build handy.) $ time echo gnu.testlet.java.lang.Character.unicode | rvm gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:1703ms tests:1292ms 0 of 3578944 tests failed real0m6.169s user0m3.637s sys 0m0.232s (JamVM 1.1.2 with some local patches - that shouldn't impact runtime speed.) $ time echo gnu.testlet.java.lang.Character.unicode | jamvm gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:3927ms tests:7478ms 0 of 3578944 tests failed real0m11.572s user0m10.721s sys 0m0.447s (SableVM 1.1.2-pre as posted by Grzegorz on Planet Classpath yesterday.) $ time echo gnu.testlet.java.lang.Character.unicode | sablevm -Y gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:2296ms tests:6114ms 0 of 3578944 tests failed real0m8.714s user0m8.186s sys 0m0.067s (Kaffe 1.1.4 Just-in-time v3) $ time echo gnu.testlet.java.lang.Character.unicode | kaffe gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:1080ms tests:618ms 0 of 3578944 tests failed real0m1.985s user0m1.622s sys 0m0.067s (IKVM.NET 1.0.1549.20346 [latest snaphot] with Mono JIT compiler version 0.31) $ time echo gnu.testlet.java.lang.Character.unicode | mono ikvm.exe gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:2725ms tests:1393ms 0 of 3578944 tests failed real0m5.656s user0m0.075s sys 0m0.013s signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
Development Jikes RVM can take a while to build, but does buy some performance. Probably not worth it for classpath development or mauve tests, but if you want to run some apps it can pay off. I have prototype and development 2.3.2 images sitting around on my machine, so just for fun. prototype: [EMAIL PROTECTED] mauve]$ time echo gnu.testlet.java.lang.Character.unicode | rvm gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:1580ms tests:796ms 0 of 3578944 tests failed development [EMAIL PROTECTED] mauve]$ time echo gnu.testlet.java.lang.Character.unicode | rvm gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:564ms tests:700ms 0 of 3578944 tests failed About 10% on the tests; About 3x on the load phase. --dave___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
Mark Wielaard wrote: There are quite some differences between the free runtime environments. Here are some results from JC, although this is on a much faster machine (Intel(R) Pentium(R) 4 CPU 2.40GHz): $ time echo gnu.testlet.java.lang.Character.unicode | jc gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:1734ms tests:402ms 0 of 3578944 tests failed real0m2.760s user0m1.970s sys 0m0.780s JC was configured with --disable-assertions. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
Hi, On Mon, 2004-04-12 at 15:53, Mark Wielaard wrote: There are quite some differences between the free runtime environments. (Total) running time goes from 1.2 seconds (native gcj) to 1.5 minutes (kissme). This is on a AMD Athlon XP 1600+ (1.4 Ghz). Note the interesting differences between the load, test and total time. All times are best of three runs. Since a picture says more then a bunch of numbers: http://www.klomp.org/mark/free-vm-benchmarks/getallen.html Sorry, I left out kissme because it was so much slower then the rest. Interesting to see how much time each runtime spend in loading, testing and overhead. Hope I have time next week to update it with at least rvm development results and maybe IKVM ahead of time results (Jeroen, any hints on how to do that in this case?) Caution! This is a micro-benchmark for one very specialized small and repetitive task, so don't take the number to serious. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
Mark Wielaard wrote: and overhead. Hope I have time next week to update it with at least rvm development results and maybe IKVM ahead of time results (Jeroen, any hints on how to do that in this case?) I don't know whether you have a zip/jar or individual classfiles but assuming it's a single jar file, presumably it would be (commands separated by blank lines - ignore any mailer-induced wordwrapping): mono ikvmc.exe -target:exe -out:mauve.exe -reference:classpath.dll -main:gnu.testlet.SimpleTestHarness mauve.jar time echo gnu.testlet.java.lang.Character.unicode | mono mauve.exe -debug You may need to arrange for all IKVM's DLLs to be in the same directory as mauve.exe. The other thing to try would be using Mono's --aot option to pre-JIT (as it were) the generated exe and dlls. I've never tried this but in theory it appears that you should be able to do: mono --aot mauve.exe (and possibly also: mono --aot classpath.dll mono --aot IK.VM.NET.dll etc...) prior to running mauve.exe itself. Of course, I'm not Jeroen and I could be missing something significant... Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
Hi Guilhelm, Thanks for the info. Your numbers tend to confirm my suspicion that the factor of 200 is a Kissme-specific problem. In the meantime, I think I have come across a problem in Kissme's implementation of the CONSTANT_STRING instruction that does some way towards explaining this. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
The Mauve unicode testcase and VM performance
Folks, I've just checked in a new version of the Mauve testcase for Unicode character handling. This fixes previous problems that resulted in huge numbers of test failures with the current version of Classpath. [It turns out that they were partly because the testcase used an old Unicode table, but mostly because of testcase bugs; i.e. tests that were wrong vis-a-vis the JDK 1.4 javadoc.] The testcase now runs clean for JDK 1.4.2 as well as Kissme/Classpath from CVS. The interesting thing is that the test run 200 times faster with JDK 1.4.2 than with Kissme. Yes TWO HUNDRED TIMES! $ cat /tmp/foo gnu.testlet.java.lang.Character.unicode $ /usr/java/j2sdk1.4.2/bin/java -cp ../mauve gnu.testlet.SimpleTestHarness \ -debug /tmp/foo Reading unicode database... done Benchmark : load:288ms tests:505ms 0 of 3578944 tests failed $ useful_scripts/kissme -cp ../mauve gnu.testlet.SimpleTestHarness -debug /tmp/foo Reading unicode database... done Benchmark : load:13892ms tests:104699ms 0 of 3578944 tests failed (This is on a 2.5Ghz Pentium IV) Question: what figures do people get with other open source VMs? -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen Crawley wrote: | Folks, | | I've just checked in a new version of the Mauve testcase for Unicode | character handling. This fixes previous problems that resulted in | huge numbers of test failures with the current version of Classpath. | [It turns out that they were partly because the testcase used an old | Unicode table, but mostly because of testcase bugs; i.e. tests that | were wrong vis-a-vis the JDK 1.4 javadoc.] | | The testcase now runs clean for JDK 1.4.2 as well as Kissme/Classpath | from CVS. | | The interesting thing is that the test run 200 times faster with JDK 1.4.2 | than with Kissme. Yes TWO HUNDRED TIMES! | | $ cat /tmp/foo | gnu.testlet.java.lang.Character.unicode | | $ /usr/java/j2sdk1.4.2/bin/java -cp ../mauve gnu.testlet.SimpleTestHarness \ |-debug /tmp/foo | Reading unicode database... | done | Benchmark : load:288ms tests:505ms | 0 of 3578944 tests failed | | $ useful_scripts/kissme -cp ../mauve gnu.testlet.SimpleTestHarness - -debug /tmp/foo | Reading unicode database... | done | Benchmark : load:13892ms tests:104699ms | 0 of 3578944 tests failed | | (This is on a 2.5Ghz Pentium IV) | | Question: what figures do people get with other open source VMs? | Thanks for fixing unicode ! On my PIV 2.5 it gives with kaffe jit3: [EMAIL PROTECTED] mauve]$ echo gnu.testlet.java.lang.Character.unicode | kaffe gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:1052ms tests:334ms 0 of 3578944 tests failed [EMAIL PROTECTED] mauve]$ echo gnu.testlet.java.lang.Character.unicode | /usr/j2sdk1.4.2/bin/java gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:266ms tests:406ms 0 of 3578944 tests failed Answer: h 70ms faster for tests but 5 times slower for loading. Cheers, Guilhem. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAdYkLWRk4qbNiTwgRArf+AKCOFjQu0gMirvywMCGUdNHvbE1q2QCgjceY GkG9MpJGgZIDsh1auJQ/RpY= =Pft5 -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
