I noticed that Google have a site that compares a few languages using a graph traversal benchmark.

So I thought it would be interesting to see how haxe/hxcpp fares. I started with a direct (ie, almost line-for-line) translation of their cpp implementation. I changed the list to arrays where appropriate, and implemented one “set” as an array because haxe does not have a native “dictionary” object for keying from generic objects.

The supplied cpp target was pretty easy to compile on windows by ignoring the makefile and using:
cl -O2 /EHsc

The haxe target uses (right-click, Save As) LoopTesterApp.hx and MaoLoops.hx, and compiles with:
haxe -main LoopTesterApp -cpp cpp

The java_pro code can be built and run (note that increased stack size is required when running) :

$JAVA_HOME/bin/jar -cvf LoopTesterApp.jar `find . -name \*.class`
java -Xss15500k LoopTesterApp

The java target requires additional stack space – and so does neko, however there is no option to increase the stack space with neko like there is in java, so neko just panics. I have not tried as3 – I guess there will be a script timeout which would need to be managed. Also a JS or v8 time would be very interesting.

The runtimes are:

cpp 19.2 seconds
cpp (claimed) 6 seconds ?
hxcpp 26.7 seconds
java (pro) 22.5 seconds

The google paper cites a 3x speedup with optimised c++ code, but there is no code for this.

The java implementation is the hand-optimized version. In hindsight, I should probably have ported this version, rather than the vanilla cpp version. It includes optimizations such as object pooling and task-specific containers. Also, this particular benchmark is designed to allow java to comfortably perform its JIT compiling.

So in conclusion, I would say I’m pretty happy with these results. I’m sure there are some micro-optimizations, such as the “unsafe get” on arrays, which does not check the bounds, and some higher-level stuff that profiling may reveal that could share quite a few percent from the hxcpp time. I’m not particularly interested in optmising for a particular benchmark, however a little bit of profiling here may help speed up the target as a whole, which would be a very good thing.

10 Replies to “Multi-Language-Bench”

  1. Can that hxcpp “unsafe get” trick be used in haxe code? Or only accessible from a ndll?

    Actually I’m very interested to see a NativeArray haxe class that has zero overhead. Exposing more native cpp object API (like struct, unsigned int etc.) would be useful for creating ndll. And I think hxcpp has its value as an independent target that it deserves more cpp-specific classes for user to fully take advantage of the platform.

  2. Andy,
    You can use:
    var a = new Array();
    // Allocate array…
    a[9] = 0;
    for(i in 0…10)
    untyped a.__unsafe_set(i,i);
    untyped trace(a.__unsafe_get(i));

    This will allow you to crash, just like a “real” c++ program!

  3. On a totally unrelated theme, (but I’m telling you here bc I don’t know how to contact you, or the proper channel for this):

    I come from an Objective-C background, and I’ve developed lots of iOS apps before with their SDK’s and stuff. I’m switching everything to haXe, because I already use it for other targets and I love the language itself.

    I’ve been using the latest packages for nme and hxcpp in order to compile some iOS apps. Everything works amazingly (excellent work). However, there are lots of API’s that are not yet ‘wrapped’. To put an example, the API that gives you access to the Compass data.

    I’m pretty familiar with those API’s on Objective-C/Cocoa. Do you know a way of ’embedding’ native code (doesn’t matter if it has to be C) directly on the hxcpp target? The idea is that I can use all of those API’s that I already know without waiting for them to be ‘wrapped’ and working (if they ever do). Also, it would be good for testing/development purposes.

    I don’t know if that exists, but if it doesn’t perhaps that could be made with macros or some kind of annotation. That may break the cross-platform philosophy behind haXe, but think instead of it being an extension to haXe for certain platforms.

    1. Hi,
      It is not really easy to add your own native code to the existing system.
      Ultimately, you would want to get your results (eg, compass data) into your haxe code, so some sort of interface is going to be required. It is possible, but not easy at all.
      Your 2 best options are:
      1. Extend NME yourself. You can add your functions to one of the NME “.mm” files, and write cffi functions.
      2. Make a new project with your extensions. This will still need some interface code, see the project.

Leave a Reply

Your email address will not be published. Required fields are marked *