Bam! GitHub - r-lyeh-archived/scriptorium: Game Scripting Languages benchmarked
Should put end to C++ vs C#/Lua/etc. arguments (hopefully)
And how should I interpret the table??
No idea. Ask the guy who compiled that chart?
Ehm, why do you think, looking at the table, that table is going to end the C++/C#/Lua arguments?
I just posted, don’t really care 
A comparison marked with “Take it with a grain of salt” by its own creator?
/thread
C# is not even there and anyways the request of having other languages in general was never about speed
If it were about speed, would we all not default to C++?
That being said, there are lots of things to improve in the engine before I’d rally for Epic to officially integrate another programming language.
Lol 
Such direct comparisons are inevitably going to give us only a very rough idea of speed. You have to consider the following:
-
The task being performed. Each language has its strengths and weaknesses. In some scenarios (such as certain recursive functions) Java can outperform C thanks to JIT compilation and hotspot, but C usually wipes the floor with Java in other scenarios. The question should be “is X faster than Y at doing Z?”, not just “is it faster?”
-
Skill of implementation. It’s not enough to just write something in C and then port it as-is to another language. Someone tried porting the GLM library to Java almost verbatim, and it was completely useless for OpenGL development. I rewrote the library from scratch to create the Java OpenGL Math Library (JOML) and it was around 10 - 15x faster and produced no hitches from garbage collection
By common sense, as C is lowest level programming language - it has always been and always will be the fastest language. Each layer you put on top will slow things down, as simple as that. If you want it even faster start coding in ASM directly but i doubt that you do a better job as todays compilers - especially in a 64bit environment.
I’m not so sure about this. The compilers for VM based languages like C# and Java are getting better and better. C++ doesnt have JIT, so its compiled for one architecture and thats it. With JIT native code can be generated on the fly for the specific architecture it is run on. This could lead to cases where a C# or Java application might be faster. Funny enough Microsoft is currently working on a AOT, which eliminates the JIT advantage.
VM languages do have overhead, like the JIT. It needs to compile the code to native first time its being accessed. Its a difficult discussion, and it really depends on what one is trying to do.
As you mentioned it runs a VM - which is overhead itself. I’m not a big fan of JIT either since your source-code is up for grabs then. I’m coming from Unity so when it comes to Game-Development i really want the performance UE4 provides by using a native language. The comfort of using a high-level language in the end bites you in the back when making games - at least that’s how it felt when using Unity.