[Mono-list] numerical performance comparison [C++ vs JVM vs Mono]

[Jonathan Shore]

Hi,

I am looking forward to moving all of my code from Java / C++ to F# / C# in the very near future.   I took the nbody code from the language shootout and ran with 500 million iterations (much more than used in the shootout to provide a fair comparison) on ubuntu server on a core i7 920 box.

I used:

- C++ (g++ -O3 with various MMX related flags as done in the shootout)
- Java 7  -server
- Mono 2.4.4, compiling with -optimize:+

I had the following results in seconds:

1.  C++: 		98 seconds
2.  JVM:		126 seconds,  a 28% performance gap against C++
3.  Mono:	191 seconds,  a 50% performance gap with the JVM

Because the nbody problem uses sqrt for the euclidean distance in each loop, thought that maybe the discrepancy might be more related to the implementation of Sqrt().

I implemented a (very poor) numerical algorithm as a substitute for the sqrt() function in each implementation to provide an apples-to-apples comparison.    The new numbers became:

1.  C++:		517 seconds
2.  JVM:		527 seconds
3  Mono:		223 seconds (wow, a surprise here)

I noticed that the Mono runtime libraries use an internal implementation of Sqrt() that seems to resolve to an Op Code.   I am wondering, ultimately, what implementation this maps to?   Clearly the Sqrt implementation in Mono is 2x as slow (or access through the layers is 2x as slow) as the libc implementation.   

I do mostly numerical work, so concerned about sqrt as well as other fundamental functions in this regard.   Are these custom implementations in assembler for each arch?    Would it be reasonable to try to map these to the existing libc library when available?

Thanks

--
Jonathan Shore
Systematic Trading Group