Languages Again

I do a lot of my production/  performance-oriented stuff in Java (for better or worse) because it is so portable and is very close to the performance of C++ if you know what you are doing.   I would much prefer to be using F# / C#, as they are far superior as languages in my view (though C# owes its heritage to Java more than any other language).

The problem is that I need to deploy on Linux (and for that matter, my dev platform of choice is osx).  Here are some performance #s for 500 million iterations of the nbody problem on a core i7 920 linux box:

The nbody problem uses sqrt when calculating the euclidean distance between bodies.  Began to wonder whether much of the difference is in the implementation of the library math functions.   So I did an implementation that uses a (slow) numerical algorithm to calculate the sqrt, common across the languages.   In that way we have an apples-to-apples comparison.   The C++ vs Java numbers are now:

The difference is now 1.9%.   In fact the additional 10 seconds difference may be Java startup + JIT compilation.   This resonates with other comparisons I have done in the past.

I have code in Java that outperforms equivalent C++ code.  For instance, the JIT compilation is clever enough to avoid virtual function invocation when it can be avoided / determined at runtime.   The same cannot always be done as effectively with static compilation.    (The cost of virtual function calls is 3x more expensive than non-virtual on the intel architecture).

The JVM is just the best VM around (even faster than the MS .NET vm).   I would love to see the JIT compilation technology in the JVM applied to a cross-platform .NET VM, such as Mono.   Alternatively, if the JVM was expanded to include value types, a properly implemented generic type system, and some functional features, could imagine targeting IL for the JVM.

My ideal would be to be able to cross-compile C# and F# to JVM bytecode (much in the way one can map java bytecode to the CLR with ikvm).   The .NET libraries would be a much smaller problem given that the Mono implementation already exists.    The mono guys have their hands full, and seem to have focused more on breadth rather than ultra-high performance.

I suppose the .NET and Java communities are mostly distinct, so probably few people interested in seeing F# targetted to the JVM.   Can only hope that either the mono VM continues to improve performance and GC or a new subsuming VM fills the gap where the JVM once ruled.


Filed under strategies

22 responses to “Languages Again

  1. gigi

    You should also test with Visual Studio with WPO and PGO enabled, as VC++ is a much better optimizer than GCC. PGO can also convert virtual calls to static calls.

    The SQRT difference could come from the possible use of SSE in the GCC compiler. I once used SSE for computing a large number of SQRTs (vector length for 3D graphics), and obtained a huge speed increase. You can compute 4 sqrt in parallel with SSE in the same time you compute 1.4 SINGLE sqrt with classic non-vectorized instructions (FSQRT)

    • tr8dr

      Sure, any number of reasons why sqrt could be implemented faster in one library versus another. The java implementation of sqrt is not java code, rather whatever C implementation Sun wrote. Likewise, the sqrt I use on linux’s performance is just a matter of how the gnu libc libraries were put together.

      The JVM, btw, is able to take advantage of SSE, but undoubtedly not to the extent an explicit implementation would. With regard to VC++, recognize that it has deeper optimisations than gcc (similarly the old sun and intel compilers were also better). My runtime platform is Linux, so VC++ is not an option.

      Also the performance numbers for C# / .NET evaluation are much closer to C++ / Java on MS .NET. The windows platform is just not something I would consider for high-freq trading.

      • In my experience, gcc 4.5 produces consistently faster code in almost all cases than Visual Studio 2010. However; that’s just the stuff I write (which is incidentally tuned in Visual Studio – so any bias here is certainly to VS’s favor), which certainly doesn’t guarantee anything for the general case – I’m mostly dealing with numeric optimization with lots of doubles & math. I do quite a bit of tuning based on profiles and some experimentation which helps the VC++ results considerable – before said tuning the performance gap is considerably larger.

        In any case, the differences tend to be on the order of 10% (barring specifically selected microbenchmarks), so the statement “VC++” is a much better optimizer is most realistically false – what I see points in the direction that it’s generally worse, and neither makes a dramatic impact in most cases.

  2. When it comes to integrating OCaml to JVM (dunno about F#), there is always this:

    As far as I’m aware, this implementation of OCaml on the JVM is a feat in itself, but I’ve heard complaints about the performance not being as good as it ought to be.

    But then, perhaps I’m being unfair. Never really tried it.

    • tr8dr

      I looked at this. Did not seem to be production-ready or well integrated with the VM. It has potential if there is enough development going forward. Unfortunately it seems that the 2 biggest functional language projects on the JVM are Scala and Clojure. I like lisp well enough, but don’t find it appropriate for large systems with its dynamic typing and lack of object system. Scala feels wrong. It is as ugly as C++ and more complex syntactically, nor does it have type inferencing in the way that ML / OCaml / F# does.

      Also, though F# is based on OCaml, it is distinct. I like the way F# fully integrates with the .NET object system and allows one to create 1st class objects. It is nice to be able to be pure functional and at the same time dip into the practical world of OO.

  3. Sure, sure.

    But integrating with the practical world of OO in F# also brings you back to the NULL/Null pointer issue. You lose safety.

    As to having practical OO systems fully and safely blended into functional languages, it’s a difficult topic in itself. I’ve been working on that a bit, and you do pull your hair.

  4. Now that Mono 2.8 is out with its new generational GC and LLVM backend, maybe you should give it another go on Linux, would be interesting to see your new results.

    • tr8dr

      Mono 2.8 looks to be a big step in the right direction. The problem with this benchmark is the Sqrt() function. Having talked with one of the mono developers, it seems like the math library is not yet all that optimised (for example is not using MMX). The math backend is still the same in 2.8 I believe. I’m not sure whether is remapped if built with LLVM or not.

      One could get around the math problem using native callouts to the C library I suppose.

      I’ve not been able to find the official 2.8 packages or alternatively the source tarball. I’ve had poor experiences with the mono build process in the past. deb packages would be the easiest. go-mono still shows the 2.6 source and packages in their download section.

    • tr8dr

      I installed 2.8 on my mac (can’t yet get a build for my ubuntu linux box). Sadly, mono is still 2x slower than C++. This is entirely do to the implementation of Sqrt().

      They don’t seem to be bundling llvm with the mono builds. The mono team is discouraging the use of LLVM generally if you talk to them, but grudgingly have made it part of the build.

      I’ll try the native approach with linkage to libc and see how that goes …

  5. andrew

    Not so fashionable,
    usually ‘fast enough’,
    the big winner for me is less typing.

    of course ymmv and it also helps if you know it already.

    otoh, if you are selling the code, it has to be in whatever the client wants.

  6. Qbit

    Hey there,

    Love your blog, been reading it for quite awhile. In several posts you have mentioned that you use Java. I am making the transition from Matlab to Java for various reasons and I wanted to ask you this,

    How do you get around the “classic” problem with float/double numbers, eg. 5.00+1.02 = 5.0199999999…

    Do you use bigdecimal? I’ve found it a tad slow.

    • tr8dr

      To be honest using Java mostly because I have so many years invested in it. At this point I’m trying to move gradually over to F# / C# (running on mono). Java is becoming a dead-end language relative to these. You might also consider Scala if you want to stay on the JVM.

      With regard to floating precision, I guess it is only important when you put orders out to the market and for display. Rounding should solve your problem. I’d stay away from non-native representations if performance is important.

      My current language mix is R -> Java -> C++, but will eventually be R F# -> C# / C++

      • gotnoname

        thanks for your reply! I was thinking about doing rounding as well.

        Regarding Mono, tbh I started writting my algo-trading system (the non-numerical bits, these were done in matlab) in Mono, however there are a couple of issues I confronted when I thought of making a mono only system (without matlab),

        1) Numerical Libraries. Java has Apache math commons and some others *well tested* (free in both code & price) libs. .net has some free libs but they don’t look mature to me. Also, I’m not sure how widely they are adopted. wide adoption is a big benefit in terms of bug-free code, documentation etc.

        2) Mono is essentially an MS solution without MS. MS may change its mind in a couple of years and go after patents. It may be (haven’t tested it but just saying my thoughts) that Mono is not optimized for a non dual-core/i5/i7 processor (mainstream processor).

        3) I don’t know how well mono is optimized. Your posts hint that some things, e.g. sqrt, is not optimized in Mono.

        4) some numerical libraries are not supported in Mono, others won’t be well tested in Mono. If I’m the only one seeing a mono-specific bug in a library few people use, I’m out in the cold.

        I don’t want to use C++ for a home system (moving out of matlab is purely because of license costs if you want to add parallel processing etc) and the more “tidy” environments that are also cross-platform atm are a) Mono b) Java. I’d much rather use C# but what worries me is that it may take awhile for its scientific libraries to reach maturity. I agree that Java is too 90s but this also mean that some libraries in Java are mature today.

        Have you looked into .net’s (non-commercial) numerical libraries? since you’re making a transition to .net, I’m very interested in hearing your thoughts, if you dispel my fears, I may well continue my mono codebase (which has reached a substantial size) and extend it to do the backtesting as well.

      • tr8dr

        You can use IKVM to cross compile java bytecode and make available for the .NET VM. So all of the java libraries are available for use. As for C++, I just use a bit of it to interface to native libraries where there is not a good implementation in Java.

        I would love to see F# and C# divorced of MS control. But just as Java was in Sun’s hands, doubt that will happen in the next 10 yrs.

        As for analytical libraries, I have interfaces to a scattering of Fortran, C / C++ libraries for scientific algorithms build over the last 40 yrs. But mostly I use my own, having built substantial math, machine learning, and timeseries tools over the years.

  7. gotnoname

    how did you find ikvm in terms of stability & performance so far? it looks quite ambitious, I’d love to use if it were close to “native” jvm.

    • tr8dr

      Have been using IKVM since 2005 without issue. The performance is in-line with native .NET compiled. Basically just translates JVM bytecodes to .NET bytecodes. The actual compilation to native is done by the VM. IKVM is also being used for code generation and java compatibility in the mono project.

      Should you encounter any issues with something esoteric on compilation, the developer Jeroen Frijters is very responsive.

      • gotnoname

        great to hear that, many thanks! I’m a little conservative with regard to the tools I choose to use. Mainly because in the past I’ve invested allot of time in the wrong tools (learning COM/DCOM 2 years before .net would be the pinnacle) and now I apply some “value investing” criteria before I choose a platform.

        Since you’re happy with IKVM, I’ll try to use Java’s libraries through C#.

  8. Qbit

    btw tr8der, why do you use clustering for what you do instead of the more standard pca approach? I’d expect the two to be (roughly) equivalent.

    • tr8dr

      PCA is one of many dimension reduction tools, a linear one at that. There are much better or more specific measures for relationships that can be used. So I can use any one of many possible “connectedness” measures to weigh each edge on a graph.

      The clustering is then a simple algorithm on any weighted graph.

  9. Filipe Rocha

    What about Clojure? It seems it’s just what you need! A functional LISP on top of the JVM born for concurrency!

    • tr8dr

      I admire the Clojure and its community, however, I don’t feel that it is ready. I did some tests with it and was disappointed with performance. Also having to annotate computations with types to get decent performance was too cumbersome. I really like lisp (esp scheme), however, i think the future is in languages that are strongly typed, whether implicit or explicit. ML and other languages do a much better job with this and can generate much more performant code.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s