Friday, November 14, 2008

IKVM Benchmarking

I'm interested in what options are available for migrating a high performance Java application over to the .net runtime. IKVM is one obvious pathway so I decided to run some quick benchmarks to gauge how well it performs.


I ran the DaCapo benchmark suite (2006-10-MR2) on my dual core PC and also a 16 core server. I allowed the execution time of the tests to converge (-converge) to help rule out startup costs and just used the default workload size. Since IVKM will have no heap restrictions I made the Java heap as large as possible. This turned out to be 1499Mb under the 32bit JVM and I limited the 64bit JVM to 2500Mb since I didn't want it to start page faulting on my box. As it turned out this was heaps [sic] of memory.

I took the fastest run time from the tests considering it as the "least disturbed" run. The graphs below are normalized to a percentage of the fastest runtime for each test so a smaller value is better. Several tests failed to run under IKVM which was a bit unfortunate - chart, eclipse and jython.


Firstly lusearch is missing from the following results. This is because I'm quite interested in this benchmark in particular and it performed so badly that it warrants further investigation...

Dual Core Machine

I really should have the exact details of my machine but I don't have them handy. It is basically a dual core AMD 64 with 4Gb of RAM.

As you can see the results are quite mixed. Pmd and Xalan perform quite poorly, however looking at the threading information and the memory stats nothing really jumps out. Xalan is one of the multithreaded tests however so is hsqldb in which IKVM fairs quite well.

dual-core results

16 Core Machine

Again I don't have the exact details of this box but it is a quad-quad-core with 32Gb of RAM. The extra cores seem to exaggerate the dual core results further. Interestingly, on hsqldb (one of the multithreaded tests) IKVM 32 bit outperforms the Java 64 bit VM and the 32 bit client. The other strange result is on pmd in which the 32 bit Java client is the fastest to execute - I suspect this is a copy paste issue :-(



Some very mixed results and some questionable test results :) I guess some more work is needed.