Hi, We did try to work with the hxcpp backend for haXe, but even after spending quite some time and submitting patches for it, it seemed like it would be very hard to get it to production quality with our codebase. We have probably 100,000 lines of haXe code targetting Neko, and it just seemed that our code triggered many problems in the hxcpp backend. It could be that our code relies on implementation details of the Neko VM, and hxcpp is technically correct, but after trying hard, we just gave up. On the other hand, we really need the code to run faster, so we have to do something. Nicolas suggested adding a LLVM backend to the Neko code as the most robust way to do this, so this is what we are trying to. We took the code for Neko, and are adding a new LLVM backend, in addition to the interpreter and the x86 JIT.
We hope the advantage of LLVM is speed, as well as provide support for multiple targets. The current Neko JIT only targets x86, while LLVM can provide JITs for more targets. For instance, LLVM does support ARM, so this work could be a way to target such systems. And when it comes to speed for C and C++ code, LLVM is competetive with gcc in many situations. As another case in point, see the new Haskell backend: That achieves great performance, even when it was not tuned except for a custom calling convention. The Haskell developers will be optimizing their LLVM backend this summer, and there is a fair chance that it will beat the existing native backend they have. See for instance http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/ and http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html LLVM is a mature project which will most likely be maintained and improved for many years, since it is becoming the system compiler for MacOS. Our primary aim is to speed up our haXe code targetting Neko on 64 bit machines. We don't know if we will achieve that, but we hope we will. The biggest challenge is probably that Neko is a dynamic language, rather than a purely statically typed language like Haskell, so it is hard to tell whether we will achieve the speedup, and if we do, how much it will be. But it seems like the best bet for our situation, and we hope that the contribution will be valuable for others as well. The code is really easy to download and install if you have a Linux setup. It is also trivial to add new test cases: Just write a .neko file in the tests folder that produces a small output, and type "rake". It should run the test with the interpreter, the JIT and the LLVM, and compare the output. Repeat until tired, and then send a patch to us! And once you have done that, adding the implementation of an opcode is also simple as long as it is just a callback to C. So I invite all to give it a try. So in conclusion, I hope that we will be able to reach a substantial speedup. In our testing, PHP is faster than haXe on neko in many practical cases, so we really should try to speed things up. Regards, Asger -- Neko : One VM to run them all (http://nekovm.org)
