as title.
speed means game’s overall runtime speed, smoothness in actual target platforms. (PC, mobile, etc)
IL2CPP will only impact the performance of the code you write for your game, it should have little impact on the core engines performance.
C# or Mono code does just in time compilation on the fly which means it only has an overhead the first time it runs. But there is a performance overhead for calling from C# into Unity. If you look at Unreal 4 then a lot of developers use its node based blueprint programming system which will be slower than native code.
DirectX 12 and Vulkan should provide a massive boost in performance for both engine’s, when fully implemented.
Unity has already implemented a multi-threaded task/job system within the game engine itself, which has speeded up the engine quite a bit. Combined with the Physics engine upgrade it is quite fast now.
I have yet to see a game benchmark that directly compares Unity and Unreal with the same ‘game’ mechanics and assets.
I do have my own benchmark Cube Mark which I have been running in Unity and even had a brief go at getting it working in the Unreal engine http://forum.unity3d.com/threads/unity-benchmark-v0-1.151813/page-6#post-1974571
The benchmark used the Blueprint system in Unreal but did not manage to move as many cubes as Unity could.
But what we need is an entire game level, or a couple of different game genres, developed and ported to both engines then tested for speed to get a good comparison. It would also be a fun inter-community optimisation challenge.
I believe Unity is already faster on the lower end platforms. It’s the high end graphics capacity that Unity is slightly behind on.
A inter engine bench mark would be interesting. But there are so many things going beyond raw performance when it comes to engine choices.
If you want raw performance, don’t use an engine, hand craft your entire game in C++
I suppose it would depend on how much you let Unity do and how much you do in C#. For my game, huge amounts of work are done in the C# VM - terrain creation, lighting calculations, ambient occlusion, a lot of the physics, saving, etc.
I imagine I would see performance increase if that code were in C++.
How much of a performance impact you can expect (if any) depends on your code and what exactly you’re doing. If you’re only creating simple games with simple code, I’d be really surprised if there was any significant performance gain. For complex games it’s really impossible to tell. The sheer complexity of the environment your code runs in is the reason for that. Besides that, there will probably be differences depending on what exactly acts as the bottleneck in your code.
It’s the same thing with Vulkan and DX12. The important part is not implementing those new technologies, but rather using them efficiently.
A simple example would be upgrading your single-core processor to an equivalent multi-core one.
Ignoring the overhead from the OS (scheduler, etc.) , the performance gain is exactly 0% if your algorithm isn’t parallelized.
tl;dr:
IL2CPP won’t make bad code good. If it runs like ass now, it’ll run like ass then.
1 Like
Compute Shaders are your friend, if it is performance you are after - at least when it comes to terrain, lighting and physics.
First of all what makes you sure UE4 is faster?
That’s right, you guys really don’t know. As for cubemark, I’m not really exactly sure what it’s meant to test. It’s a very small test that I suppose measures raw draw call cost. If uses post, there’s not much sense in that unless both engines are using either none or the same.
1 Like
What? Naww, we should follow in the footsteps of rollercoaster tycoon and make the game in assembly!
Hype over c++ & graphic-ness.
Probably not 
1 Like
Yeah it’s just, most people slam it on a desktop with some vague idea that it’s faster. A great benchmark is seeing how both hold up under VR conditions. VR uniquely stresses engines - you can’t have stutters or bad garbage collection. You have to instance draw calls per eye and do other tricks like that. It’s a good test for millisecond stability with threading. Spikes and so on.
I’d rather have a slightly lower framerate across the board than have pits and peaks which might or might not skew benchmarks but deliver poor ingame experiences.
That reminds me… is unity going to try to be per-platform cross-platform in the future? Like you can use dx for windows, vulkan for linux and metal for mac? Or is vulkan going to cover mac as well?
Just remembered all* your code in unity is running on a single thread, this depending on game type, or even CPU type, could be a performance limitation in Unity.
Not sure how multi-threaded the code/blueprints are within Unreal 4.
*You can write threaded code of your own. But the Unity API does not have a threadsafe subset so you can interact with Unity from your threads. So you have to go through the main single thread to Unity.
D you think it would be difficult to create a ‘thread maker’ plugin since plugins use c++? Or could we use threads if all of the thread code was in c++ in a plugin?
There is no C++ threadsafe API access route into the Unity Engine, so you still have this single threaded potential bottleneck that has to go via single threaded C#/Mono potential bottleneck.
Ideally Unity would have some threadsafe access points to the engine then you could have multi-threaded access allowing you to use all of a platforms threads and cores for maximum performance.
Isn’t Unity providing a build to Native option for Windows Univeral apps, this is I believe using the Microsoft’s .Net to Native build technology?
So we might not even need to wait for IL2CPP to Standalone for windows platforms.