Table of contents:
- Virtual machines? Garbage collection? Isn't MPI.NET going to be slow?
- How does object serialization affect performance?
|1. Virtual machines? Garbage collection? Isn't MPI.NET going to be slow?|
Many programmers concerned with performance tend to avoid garbage-collected languages that execute in a virtual machine, because those language features have traditionally had a high cost to performance, particularly in the small, numeric kernels that are often used when benchmarking for scientific applications. However, recent advances in virtual machines and just-in-time compilation have closed the gap significantly, and the two-orders-of-magnitude slowdowns reported in early scientific programs using Java are long gone. In our MPI.NET micro-benchmarks that intentionally measure the overhead of the virtual machine and MPI..NET directly against native C code, we saw 7-12% slowdowns in MPI.NET in the absolute worst case (NetPIPE results using shared memory).
|2. How does object serialization affect performance?|
MPI.NET automatically serializes objects when they are transmitted from one process to another, so that users need not worry about their (de-)serialization. The (de-)serialization process has a non-trivial cost, since it involves memory allocation, copying data into a platform-neutral form, and often some virtual method calls and even object reflection. This cost is necessary for objects on the heap, but it becomes a huge performance problem when applied to simple datatypes like integers, floating-point values, or complex numbers. Thus, MPI.NET uses aggressive optimization techniques so that it only serializes objects on the heap. Primitive types (like integers and floating-point values) and .NET's value types (including structures, like a complex number) are transmitted directly through MPI without serialization, providing performance near that of native C code.