I’ve spent the last few days profiling and performance testing what currently exists of jaRTI. In this time I have come across many oddities on the new differences and performance characteristics of Mac OS X (intel) and Windows. Needing a break, I’ve decided to share my findings with the world.

Preface

I spent virtually all my development time (and all my general time for that matter) in OS X. With the release of the new MacBook Pro’s I have noticed a marked improvement in the performance of the Apple JVM when running on Intel hardware. I can not count the number of times I have heard the Apple JVM for PPC be mocked, or indeed indulged in a little bit of the mockery myself, however, when running on the Core Duo chips it is lightening.

Wanting to profile jaRTI, I installed Bootcamp and Windows so that I could make use of the Netbeans offering. While I don’t use Netbeans during development, their profiler is quite nice but doesn’t currently support Intel OS X So, armed with a newly dual booting machine, I set about my tasks.

The Testing

To do some minor performance testing on jaRTI I write two small federates that advance logical time from 0 to 1000 in increments of 1. For communication between them and the RTI I was using a nice shiny new RMI-based binding that I had just finished writing. Running under OS X this test completed in an average of about 4 seconds. Wanting to compare this to the same federates running under DMSO’s RTI-NG, I fired up windows and gave it a whirl. Despite running the exact same code on the exact same hardware, under Windows I had an average result of 30 seconds.

*blink*

That is a pretty significant increase. Baffled as to why this might be so, I figured up the profiler and began to poke around. I found what I generally expected: most of the time was spent within the RMI code. However, questions still remained. I wanted to know if there was some problem internal to the framework that was causing RMI to spin its wheels for some reason. I switched bindings to a previously written “JVM binding” (which runs the federates and RTI in the same execution - so there is no network overhead) and came out with an average of about 2 seconds. For some reason the RMI code was causing enormous delays, but only in Windows. Why? I have no idea, but it was running some 10 times slower and that’s what I cared about.

Switching back to OS X, I ran the tests again with the JVM binding to see if this general ratio was consistent beyond just RMI. Running the tests yielded an average execution time of 0.3 seconds (comparted to 2 in Windows). I still can’t explain why RMI was causing such delays in Windows and not OS X, but I decided that I’d replace the RMI binding with a light-weight socket implementation that just throws Serialized objects back and forth (which, oddly enough, is a bit part of what RMI does).

After Mick and I spent yesterday working out the main bits, I completed the remainder of the new binding today. Running the two-federate test again in OS X returned results of around 6 seconds. Yes, this new binding was slower than the old RMI one. However, booting into windows and running the tests gave me an average result of 1.2 seconds.

*blink again*

Somehow, this new binding was about half as slow again under OS X, yet 30 times faster under Windows. Either way, the Apple JVM was quite quick on Intel hardware. Like Windows itself, in the tests I ran performance was up and down. If anyone has any idea why this might be so, please leave me a comment (or fire me an email), I’d love to have a rational explanation.