C++ backend for haXe

I have just completed an alpha release of a c++ backend for haxe. This means that you can complile haxe code into a 100% compiled executable. You can download the demo file in hxcpp-01.zip. Sorry, windows only at this stage.

The distribution contains a new cpp backend for haxe. It has been based on a 2.0 version of haxe, which may be a tiny bit out of date. Most of the changes are in the new “gencpp.ml”, and to the standard library files, with a few little extra bits here and there. You can re-compile the haxe compiler if you have ocaml by using the supplied install.ml script.

To try this version for yourself, first backup your haxe distro and copy then supplied “compile/bin/haxe.exe” and “compiler/std/*” files over the top. Use the “-cpp cpp_directory” command line to generate a directory that contains src, include and nmake files. You can then compile these using the microsoft visual studio “nmake” utility. The build system requires the library, include, make and dlls from the “hxcpp” directory. To access these, you should set the environment variable “HXCPP” to point to hxcpp directory extracted from this distribution. This can be done from right-click-”My Computer”/Properties/Advanced/Environment Variables, or from the commandline before compiling. These resulting “exe” file also needs the hxcpp.dll file from the hxcpp/dll directory. The should be in your “path”, or simply copy it next to your exe.

You can recompile the hxcpp.dll using the nmake file in the directory. You can change the compile flags from the $HXCPP/nmake.setup file (eg, turn on debug).

Demos

Two demos have been included - “perf”, a small benchmark program I found on the net and a “Physaxe” demo. The source is included (slightly modified), and so are the binaries. The cpp src and include directories have been included to give you taste of the output if you can’t be bothered setting up the compiler yourself. The binaries can be found in demos/bin, and are compiled for neko, swf and cpp. The neko version can be run with “neko phx.n” or “neko TestRunner.n”. You do not need a very recent version of neko, but you do need the included “nme.ndll” findable by neko (next to it will work).

The cpp version of Physaxe uses the cpp verion of NME. This was compiled from the same code base as the neko version, except it uses the “neko.h” file found in the hxcpp directoty instead of the one that comes with neko. The nme.dll should be next to the compiled exe.

If you want to compile the nme versions yourself, you will need the latest nme and neash versions from code.google.com: http://code.google.com/p/nekonme/source/checkout http://code.google.com/p/neash/source/checkout

Performance

The flash version of physaxe runs the fastest, with the cpp version about 70% of the speed (when using the opengl version), and neko about 20% of the speed.

One of the problems is that the cpp version uses the neko api, which required fields to be looked up by name, which is quite slow in this implementation. A faster version could link directly to the hxcpp objects - but then it could not use the same API. This problem is made far worse by the fact the physaxe re-renders each point in each object every frame, rather then simply adjusting the matrix of existing objects.

I think the most significant loss of perfromance is coming from the reference counting housekeeping. I will look into a garbage collected system soon.

The results from the “TestRunner” are mixed with flash being faster for stings, but cpp faster for maths and looping. Neko is fastest for the sting sort in this case, but this is unusual because the stings are already sorted. When they are not, neko is very slow. The cpp string code is very simple, so there is scope for improvement there.

TODO

There is still plenty to do.

• A lot of the operators (eg, “*=”) have not been looked at.
• The actual formatting of the generated code needs a complete overhaul.
• The ml code needs some simplifying/cleaning.
• The standard libraries (eg, xml,regex)
• Need some way of locating the various dlls etc.
• Splitup/refactor the HObject.h et al files.
• Returning values from blocks/swithes.
• Complete neko.h
• Look at GC.

Plenty more, I’m sure.