C++ vs. Lice-C performance

Hi,

do you have any comparison tests or idea about the difference of (nearly) similar Lite-C and C++ codes? (And C# just for fun.)

My experinces:
Recently I have ported the static part of my RTS map decomposition codes to UE4, which - surprisingly for me - works at least 10, maybe 30 times faster than in 3DGS (1-1.5 sec stop in UE4 game thread what is approx. 30sec with 3DGS but with a few interim waits to avoid long freezing). It consists of large dynamic struct array allocations, several memset and few memcpy of arrays, passing arrays as function parameters by pointers, large loops with many complex computations. And significant amount of ray tracing, but it is rather an OBB vs. PhysX3.3 question (it is fast enough with 3DGS, lightning fast with PhysX).

I know it is heavily code dependent as it can be seen in C++ vs. C# benchmarks, but I would like to get a rough idea and a confirmation of that my AI related codes also would run similarly faster with UE4-C++ than in 3DGS-Lite-C (consisting of mainly dynamic array struct management - lot of array memsets, and loops through arrays - and expensive computations like tons of A* pathfinding). Moreover in Ue4-C++ I can convert my codes to run in separate threads in the background for the cost of more memory (each thread would require its own, not like when they are running after each other). Or course UE4 actor system and ticking is different from 3DGS entity system, where I could avoid using separate waits for my RTS units (I use only one loop with wait() as the main game loop and another for MapBuilder editor UI loop).

Thanks for any info

Just use a high precise timer and check the times of a test app you made.
I bet C++ is a little bit faster then lite-c because of better compiler optimizations but C# isnt comparable at all. I had a simple .net program which should read the bytes of a file and write them to a text file. It ran for around 5 hours where my C++ programm took 3 seconds...

I asked C# only for curiosity. I will probably switch to C++ and UE4 (more attracting than C# and Unity for me), and keep Lite-C and 3DGS only as a fast-to-develop test bed because I am familiar with it.

as I remember earlier on the 3dgs home page it was mentioned that Lite-C is faster than C#, now it is compared only to scripting languages. I saw a couple of benchmarks where surprisingly C# was faster than C++.

c++ and c# comparison depends highly on what you are doing and how you are doing it.

Lite-C is more then a scripting language, the code itself gets translated to direct assembler, the question is how good this translation is.
And seriously, if you create a multiplayer game dont even think about the word unity. Even the greatest retards can drag a dll into their project and use YOUR classes and functions because .net code isnt secured in any way.
UE4 reversing is not even close to what happened to UE3.
On UE3 you are able to dump a whole SDK for your game hacks by injecting a DLL to the game. But Im sure the same will happen to UE4 some day

UE3 was using unreal script, some sort of jvm-like vm language. UE4 uses c++ i doubt that will happen

They still save function and class names/size with the UE4 insert class member macro

multiplayer is a future plan for me, but the current UE4 system does not really suits an RTS (but they have plans to extend it at least). there are several other RTS projects in development, I will see how they work, or stay with single player only.

the thread again went a bit offtopic.

Naturally, the Lite-C compiler isn't as optimized as the Visual Studio compiler, period. So, it is a well known secret that if you do your code in a DLL, it is a lot fast. So, if code execution is an issue, just drop it into a DLL function - should be straight forward.

The only thing you can't drop into a DLL are wait(1) calls. So if you rely on classic Gamestudio scheduling, you could build e.g. classes for actors that encapsulate the behaviour which is called by the "framing" wait(1) construct in Lite-C. Sounds awful, though.

Best way would be to design your code with as less wait(1)'s as possible and shift later to DLL.

thanks for the detailed answer.
apparently my code is the bottleneck again (but I should do again a deeper analysis again to define which parts), so it means I could put my whole game loop into a dll...

Just completely switch to C++ then, this porting is stupid and opens big doors for hackers because of the DLL imports/exports.
Also, you can easily translate wait(1) calls.
All you need to do is hooking into the main thread which is kinda easy.
Then you can just call GetModuleHandle/GetProcAddress on "acknex.dll" and "wait" to get the function address and call it.

I think I will do it rather with UE4, and do not fight with 3DGS too much. I keep doing some prototyping tasks with 3DGS/Lite-c, but on my to-do-list only 4 corresponding items remained...
I could stay, and convert my stuff to a Lite-C/C++ mix, but as I am developing something long term, UE4 is a safer choice (and in practice faster to work with on smaller projects too).

<--- Falls to knees, " Damn you UE4!!!!!!!"

Camera pulls back - Malice crouches in the rumble of 3dgs. In the distance an every growing crowd of users fill the paths leading to the safety of other engines. Around him the wreckage of this once great center of game development, decaying, neglected and abandoned.

Que dramatic music score.
Fade to black.

music: https://www.youtube.com/watch?v=l3EryN4stwQ

I am pretty sure that wait would not work as it works in lite-c.

Easiest way to do it as hellx said, use only one wait in your lite-c main, write your thing in c++ as an engine plugin, create a function (something like doFrame() ) and call it from lite-c in your main while-wait loop. Now you have a function that's called every frame, and you do not need any other scheduling/wait stuff. Then create an interface with an onFrame function and implement that interface in your entity classes then put them each of them into an array and call all of your entity instance's onFrame on that doFrame function. Code you normally write inside while - wait loops in your actions goes inside that onFrame now. You can also add further functions to handle creation/destruction functions to the interface. creation function is for code you put before your while-wait loops in your lite-c code and destruction function is for code you write after the loop.

you do not need to expose anything other than doFrame to lite-c. (maybe an init and a destroy function too.)

Well I did that already so Im sure it works.
Otherwise I wouldnt write it here..
Anyways you need some small adjustments and tricks to insert the function to the queue manually (only supports cdecl calling convention)
But I guess gonna be annoying for non reverse engineers so your way is much simplier

Isn't there this while(engine_frame()) construct for overcoming the need of wait()?

That should skip one frame yeah.
But you need a static bool to toggle it or otherwise you generate an infinite loop (Only if your func gets called in engine_frame of course )

...and it's not meant for plugins but for using the engine dll in C++. I misread somewhere something it seems...

Actually you don't need a toggle bool (the engine takes care of returning 0 on close events) - but you have to setup all your code below this while, which is your main loop.
So you can as well go for a while(bla) {dll_call(); wait(1);}

No one commented on that yet?! WTF did you do?!?!?! 5 hours for something that should be IO bound and fast no matter what language you use?! This is the most ridiculous and ludicrous thing I have ever read, even in the completely interpreted world of Python you won't see such a performance discrepancy. And that is Python, we are talking about the CLR which is actually compiled to native machine code!

Like... Either you are bullshitting, or you were trying to be heavily biased in favour of C++ and made the C# version slow on purpose. My money is on the former.

Sorry, I didn't make it further than this post in the thread (minus some quick skimming of the thread to make sure no one commented on this gem yet). I'll have to leave again, my brain left out of my ear and I'm afraid I'll have to go and catch it again before I become a stumbling, mumbling idiot.

well I wont expand on that one.

but anyway I haven't done any kind of comparison between c++ and c-sharp , but I have read plenty of forum comparison related threads around the internet and they basically always end up agreeing that there is no real performance difference worthy of any discussion , well some agree some disagree , I personally love c# its the darn beezkneez , its like multi supportable language for other languages , it is beautiful .

I also love c++ so I wont choose sides here but onward to other points :

with any of those 2 languages you would have much better array's and lists to choose from for your arrays and stuff , you should be able to improve on your code in some ways by making use of some great functionality offerd by any of the 2 language's.

and I just want to say that , you can thread your functions in lite-c by using windows api too , as long as you keep it thread safe and avoid engine functions , you should be able to thread those complex functions and simply wait (1) untill the thread is done .

C++ is compiled to assembler instructions interpreted by the CPU while C# is compiled to virtual instructions interpreted by a VM.
Guess whats faster

well some say c++ because of the many optimizations you can make , plus the fact that it is pre-compiled , orhers disagree to the point that the jit is fast enough to keep up with c++ and others will say no , its the memory where the real difference comes in .

I simply say , it doesn't matter either way if you cannot comfortably code efficient code , if your code is inefficient then no language will safe your behind .

Actually C++ is compiled to machine code, just like Assembler is. There might be some assembler in the intermediate output, but there might also not be, it's all up to the compiler.

And if you want to go down this route, the CPU does not actually execute any of these instructions directly but instead transform them into &#956;ops, so if you want, you can see the CPU as one large VM that interprets x86_64 instructions.

In any case though, C# is without a doubt slower, mostly because of all the high level affordances it gives you, whereas C++ is designed with completely different goals in mind. What is better is up to you, at the end of the day though, C# is most likely not your performance bottle neck. Not with todays CPUs, where you are most likely to get IO bound.

Oh, and by the way, C# is compiled to byte code, yes, but that is actually compiled on the target machine to machine code. So actually the CIL compiler has the option to perform platform specific optimizations that a general C++ compiler targeting multiple different platforms can't do. It's the same idea behind Apple's bitcode, where the binary contains LLVM IR which is then optimized for the different platforms. That doesn't mean Objective-C is suddenly an interpreted language running in a VM.

All of that being said, I do like me my C++ and it does have its performance benefits over high level languages like C#. However, if you want to milk the most out of C++ in terms of performance, you will have to pass up on a lot of very nice abstractions that you could otherwise benefit from. However the case though, even hand knitted assembler tuned for one CPU micro-arch only will not perform 6000 times faster than C#, especially _NOT_ for an IO bound operation like reading files, unless gross incompetence is at play.

From what I've read about file I/O in C#, there indeed seem to be some rather slow methods depending on what you do - "5 hours" however is nowhere near that. My assumption is there was something else done in an improper way...

In some cases i also had the impression that CLR code (C#, ...) runs actually faster than a fully optimized C++ program. I can't remember exactly what it was, but it was about a simple algorithm.

If you have an allocation-heavy program that runs rather short, a CLR program will outperform the C++ variant, because garbage collector is trimmed on allocating a really huge bunch of small and large memory.
(The above is an assumption i make based on my knowledge about memory allocation)

Also i don't remember I/O beeing slow in C#. If you always read a single byte and convert it to hex, then print it to another file, this will be slow indeed....

I know I'm not exactly going into what you said, but it's still important and tangentially related to simple algorithms: The thing most people forget is that CPUs are insanely fast because they make assumptions about your code and fancy algorithms are only really good for big values of n! An array will most likely outperform a hash table for even up to a hundred entries simply because a linear search through array is much friendlier to the cache and branch predictor. A lookup in a hash table may very well be O(1), but that doesn't offer you much if it means that the CPU can't predict what's going to happen and can't effectively utilize the pre-fetcher.

Yes, RAM access is fast on a human scale, but it's incredibly slow on the CPU level and stalling on RAM access can easily blow your performance budget right out of the window. On the other hand, CPU caches are insanely fast, the closer they are to the actual core the faster. And if you play by the CPUs rules and effectively utilize the cache, the performance will be through the roof.

As a very real example might be this, now famous, StackOverflow question and answer: http://stackoverflow.com/questions/11227...-unsorted-array

Anyway, since we are already walking down this rabbit hole, here is another thing:



That is true, but, threads are expensive! We are talking ridiculous amounts of expensive here, since the OS has to allocate resources for the thread and initialize it, which are both non trivial. So whatever work you want to perform in the new thread has to be more expensive than that right out of the gate or you will spend more time twiddling thumbs while the new thread is spawned.

On top of that, you introduce a lot of complexity in your code because most of the time you don't want to just create a thread that then just fucks around, but you want to do something with the performed work, so you'll have to work on synchronization of two or more threads. And that is a whole bag of pain you are getting yourself into.

Next up is the issue that not everything is actually threadable! There is a category of problems called 'embarrassingly parallel workload' which is so trivially easy to multithread that there almost always is no reason not to do it. One example would be calculating the histogram of a picture, you can trivially divide the picture up into pieces, let each thread crunch on one piece and then in a last step just combine all the results together. This is so trivial to multithread because each piece of work isn't depending on any other step of the work pieces, ie there is nothing stopping them from being done in parallel. On the other hand, you have things like cryptographic hashes where each step of the work depends on the result of the previous, so you can't parallelize that work.

Now, most of the time you will find some work that is somewhere inbetween, and for those you'll have to test and see if doing them in parallel is actually worthwhile.

A way to help out with that is to employ a thread pool, so instead of creating n threads, assigning them work and then joining those n threads, you have a thread pool which maintains its own set of worker threads and which you can give a bunch of tasks which the thread pool then divides amongst those threads. Now in theory that's simple, in practice not so much. I spend a good month working on a new thread pool system for an unannounced 2nd version of a certain game engine and it's very trivial to end up with a system where scheduling jobs and dividing those jobs between the threads is more expensive than actually performing the work.

Oh, and it's quite easy to blow the CPU cache even harder when having multiple threads contend for the same data.