I opened up a topic on the Free Code Camp Forums, telling people about Haxe and I mentioned performance.
I do think that Haxe is useful for native apps that need high performance. I would definitely rather write a nice clean high level language and let Haxe handle all of the platform independence for me than write low-level C or C++
Someone replied saying that Haxe would never perform as fast as C because it is a high level language. I actually don’t know much when it comes to low level languages. It made me curious and I was wondering if anyone could tell me what the performance comparison is between C, C++, and Haxe.
I don’t know if there are statistics showing the difference between C, C++ and Haxe, but maybe the maintainer of the CPP target might have some more insight in that area.
However, I can tell about the approach we usually take when it comes to using Haxe or other high level language tech that compiles to C++.
Regarding performance of the Haxe CPP target you would most likely be able to get better performance by writing directly in C/C++, if you had the all the time in the world and the best C/C++ programmers - so that’s not an option for most companies.
But our experience is at the same time also that you don’t need to have 100% of your code to be super performant - normally you will be able to identify some critical parts of your application, that need to perform really well, and these are usually a very little percentage of the whole code base.
And one solution, is to write these parts directly in for example C or C++ and provide externs for Haxe to interface with that code.
You could say that Haxe is a super, super, super high quality swiss army knife that can do a most things really really well - and it’s pretty fast to develop in. Just the speed of the compiler, is something that put a smile on your face every day.
But for some cases, it’s better to use the super specialized tool, from the bottom of the tool box instead of trying to modify the swiss army knife to do the job.
Unsurprisingly, the answer is: it depends. There are parts of Haxe that introduce a bit of overhead compared to idioms that map directly to C++:
- anonymous types and all kinds of untyped code
- garbage collection
- closures (I’m actually only guessing here, but I think you will find that a method dispatch is usually quite a bit faster
@:generic type parameters (as they result in dynamic casts)
That still leaves you with quite a few nice features that C++ doesn’t have:
- static extensions
As Mikkel pointed out, you can rewrite performance critical sections with C++ or even in Haxe while avoiding the costlier abstractions. In that case the C++ compiler will optimize your code the same way as it would optimize hand-written code. It’s likely that writing near-optimal code in Haxe is harder and more awkward than doing it in C++, but again, it’s not needed at least 90% of the time. In those 90%, you will be vastly more productive and you can use the time saved on shaving off CPU cycles in your bottlenecks.
@back2dos, @mikkelmr, thanks for the insight. I’m extremely interested in Haxe and I am trying to figure out just how it compares to other languages.
I’ve always been a fan of Python and I thought that Cython was cool, but I found out that there are some performance limitations compared to C++. ( And the code that I was working with was for a video game so it needed to be able to be fast ). I’ve been trying to figure out how to avoid C++ because I really love languages that care about the developer ( aka, easy to read and write ). It’s a lot more important than just aesthetics, it makes you more productive and lets you get more done.
I wanted a language that had some of the philosophy that I loved from python. I took a quick glance at Golang because it was made to be nicer than C++, but I didn’t get time too try it before I accidentally found Haxe. So far it seems to be what I’m looking for. I’m surprised at how featured the language is and how it made me like it even though it was statically typed. After switching from Java to Python I was a little bit turned off by statically typed languages because it seemed so much more meaningful and clean to write Python. I think Haxe has hit a sweet spot with its awesome type system.
Java is a pain regarding static typing because it doesn’t have any type inference. When done right, static typing is great and makes your code feel much more robust
I have been using Haxe’s C++ target to make games for a few years now, and usually the bottleneck comes from somewhere else than the generated C++ code performance (bad use of the GPU, too many draw calls, inefficient logic…). I would say that Haxe C++ target is fast enough for most use cases, and there are always options to optimize edge cases as stated above by rewriting sensitive parts in C/C++ and plug them to haxe with externs.
Another question: Is HashLink faster or slower than haxe-cpp? ( Or does it depend ) Also, do you lose the ability to use C/C++ externs code if you use it?
Based on the comments on my Free Code Camp topic it sounded like the closer to assembly a language is, the more potential for efficiency it has. Based on the blog posts about HashLink it sounds like HL/C is pretty close to the system. Would compiling to HL/C be more efficient than compiling to C++?
It probably depends
HashLink target is running NorthGard with Heaps so that can give you an idea of what it is capable of, while there are games like StreamLine that use Haxe’s C++ target with Unreal Engine thanks to unreal.hx. So again, they are surely fast enough for most use cases.
I believe HashLink has a foreign function interface that gives you the possibility to plug C (or C++ through C interface?) libraries, so again you always have the possibility to write very performance sensitive parts in raw C/C++ code if needed and plug them to your Haxe codebase.
All in all, performance depends on so many other criterias than just the raw language speed and what you are doing, and you would usually also consider other aspects before choosing a target: what tools can you use on this target that will save you time, how much do you know about this target etc… Quite a bunch of Haxe developers use Node.js + Haxe js target to write tools or server side code, not because Node.js is the fastest (it isn’t obviously), but because the community is huge and provides a lot of support and libraries that you won’t have to write yourself and thus make you more efficient.
Cool, thanks for the help.
@zicklag In addition to the option of writing hand-optimized C/C++ code through externs as was mentioned above, there are also many cases where using a profiling tool like @jcward’s excellent hxScout will help you to identify bottlenecks that can then be optimized away using nothing but refactored Haxe code.
Case in point: there have already been a couple of instances where I was able to run hxScout against my current project — a “2.5D” Wolf3D-style first-person engine written in pure Haxe — to identify areas of excessive object allocations, GC pause times, and CPU-intensive bottlenecks in the generated C++ code. In each of these cases, I was able to resolve the problem through some careful analysis and deliberate but clean refactoring of the existing Haxe code — no complicated hoops to jump through and no external C/C++ code necessary.
For me, cases like these highlight the real power of Haxe.
how about compare hxcpp and hashlink?
I assume simple enums (not algebraic datatypes) are compiled to c++ enums, right?
Nope, because then reflection wouldn’t work on them. You can however use enum abstracts to achieve that.
From time to time, people bring up the question of “which is ‘faster,’” but it really isn’t possible anyway to answer that question categorically. And, with today’s über-fast microprocessors and really-good optimizing compilers, it really doesn’t matter anymore.
"Don’t ‘diddle’ code to make it faster – find a better algorithm."
– Kernighan & Plauger, The Elements of Programming Style.
This is true also for C++.
It does sometimes. E.g. modern day python programs may take up to half a second to even start running. No matter what the algorithm is.