Friday, August 8, 2008

C version

The C version of my Corpscon clone runs in about 3.9 seconds (for a 13mb shape file), versus the Java version which takes between 6 and 10 seconds. I'm surprised that I get such a performance boost; I'd thought that Java performance would be closer to the C performance. Of course, a 50% (or even 250%) increase in runtime may not seem very large--and it's indisputable that both implementations are fast enough, but I've read so many benchmarks that put Java right up there with C and C++. I guess that's only for certain things, and not for others. And that's only when you turn on the -server flag, and let the JVM eat your memory.
What's also interesting is that the lowest Java runtime, the 6 seconds, is based on an NIO implementation of my program which was far more complicated than the corresponding C implementation. Whereas C does all it's buffering/file-magic behind the scenes, and lets you fetch one char at a time penalty free, Java demands that you explicitly buffer everything, and that you call upon the complex NIO library to get C-level performance. And you don't even get it! NIO, you lied to me.
I'm certainly not an IO expert: I don't know the secrets of cache and optimal buffering. But in C I don't have to be... it appears to be done for me by the compiler. I'm sure I could extract even more performance if I knew what flags to set on GCC. I need to find a book on how caching works, and how I can utilize it to improve performance.
Another thing that might have influenced the C vs Java benchmark is that in C, I can use floats that are supported natively by the operating system, because C (as far as I know) does not guarantee consistent float behavior, unlike Java which does. Because C lets the hardware take care of the float stuff, it gets the best possible performance, whereas Java has to do software-level work to ensure consistency, and therefore looses performance. I need to get a profiler or something, to better understand the bottlenecks in my programs.

0 comments: