How much faster would Unity games/apps be if it used C++?

If Unity provided it's engine as a DLL with header files so users could write their games in C++ instead of C# how much faster would they run?

 

They'd run as fast as a piece of string is long.

 

depends on the programmer?

 

Or twices as long as half it's length.

Fact C# and Mono is SLOOOWER than Compiled C++, but the question is how much faster is C++, 2x, 5x the only real way to find out is to ask and hope the good developers at UT who have worked on a C++ version of Unity (Due to the Apple App Store Native apps only policy issue).

This would not make the Unity game engine run any faster, but it would increase the speed of the game logic we write which could greatly improve frame rates, allowing for more stuff in our 16ms (60fps) game logic window and therefore better games.

If you're developing in C# then syntactically your code could very easily be converted to C++ (*).

* yes there would be some gotchas with collections, pointers and references but nothing a programmer could not work through and even automate into a code conversion program.

 

But on modern systems, does it really matter? There have been a whole slew of tests and studies comparing C++ to C#. The thing about those tests, they don't all agree on which is faster. Especially on the tests that are actually meaningful, they can come out tied more often than not. Granted, I think most of them are between .Net and native, so there is that. (If I remember which ones help illustrate my point specifically, I shall link to them...but I has 5 minutes before I need to head out)

Don't get me wrong, a) I don't want this to turn into another argument on the matter, and b) I LOVE pointers. Love them. I had a recent problem, parameterizing a sweep across a 3D* array that would allow me to sweep in any of the six directions with the same code, wherein the perfect solution was to use pointers...but, I couldn't use unsafe code for this solution, so I had to come up with a bastardized exploit to get around it.

*It was a 3D array represented in a 1D array in the structure of (x + y * width + z * width * height).

 

You already can do most of your game logic in C++ though; I've done it with libraries and module interfaces for editor access.

 

As an indie game developer working on VR enabled games (it's the future, this time, honest ) that need to hit or exceed 60fps or include a vomit bag.

That gives me < 16ms to run a game world (ideally, according to John Carmack, we should be running at 120fps so < 8ms), anything that takes up a chunk of this time means the game has to be reduced in some way, so in a way using C# Mono is a limiting factor on what the Unity game engine can deliver.

My understanding is that Mono is now owned by another company and this prevents Unity from progressing to a newer versions of Mono with improved GC, optimisations and features.

Could now be a good time to take Unity to C++, Unreal Engine 4 has already made this move?

 

But isn't this is an indirect linkage, your dll is being called from C# which is being called from the Unity Engine, you gain performance and speed but add another layer of communication and overhead?

 

Optimization? Occlusion culling? Aren't there ways to bring any game to the minimum fps by trading off view distance and reducing overdraw?

I shipped a game with over 2.5mil polygons and it used the kinect for input and was able to get it running perfectly (had it automated, running 24+ hours without issue). It was on a micro computer 7"x7"x4" form factor with integrated graphics........


Also worked on an oculus rift + kinect project on a team of 12 that had a badass scene with several thousand draw calls before optimization.

 

its depends on programmer AND TIME - so sometimes c# can be faster than c++ because c# is easier a lot than c++ if we need special optimising (threading? etc.) so c# has faster workflow and you can spend saved time to more optimise in c# (unsafe code?)

but if performance is only once criteria then c++ is the best option - c++ + assembler rulz ^^

 

Yes, but let's say that you do all of the in engine optimisations and get the game running at about 30fps and looking great, your using 33ms so your still over budget by 18ms. How much of that overhead is being used by Mono and C#?

Also I like to use procedural/dynamic worlds which do not work well with Unity's current static baked occlusion culling system.

 

If we had a better mono implementation it'd probably help a lot more than all the testing and redocumentation that would be required for adding an entirely new language and workflow.

 

If you're this hardcore C++ you might wanna migrate to Ogre3D.

 

Not much if any speed difference considering most games are GPU bound on most platforms. In cases where you ARE actually CPU bound then yes it can help you a little with *this* version of mono. MS's compiler is gives considerably closer performance to C++ and for inexperienced programmers may even be slightly faster.

 

That could really help with performance overall, but your still using Mono which is generally slower than .Net which is slower than C++.

It is a chunk of work, but in theory Unity could provide the engine as a dll with header files for the C++ programmers to build their games, the interfaces could be very similar to those provided already in C# and API documentation can be automatically generated from comments in the code by the programmers.

Unity already uses external editors for code it would just mean that C++ projects would work more like the Unity XCode projects for iOS/Mac with an extra step in the build/run process.

 

As mentioned earlier, "slower" is an incredibly difficult to quantify term in these cases. Adding C++ support might not necessarily provide any realistic performance increase since most of what's happening in Unity is handled at lower levels by the engine itself.

 

If you are only talking about the scripting side, probably not much.

If it gave us more access to the internals of the engine, ie physx, you could completely change up the engine for your needs (or mess it up. ha)

 

For simpler games, yes, but if you take an RTS style game e.g. Starcraft or a Simulation style game e.g. Civ with layers of systems dealing with things like pathfinding, strategic AI, unit behaviours and dynamic systems and lots of active units then C#'s overhead is a limiting factor.

Most benchmarks indicate that a C++ program takes a fraction of the time to run of a similar C# program how much of a fraction varies between programs.

Games written in C++ perform better than C# quite simply because you are batch processing the JIT compilation so it does not need to be done at all, in addition to this C++ compilers can see the whole of the project and optimise accordingly JIT compilers are limited in their optimisation scope.

Yes there will be cases where C# can go toe to toe with C++ but C++ did not have to do any JIT compilation so it was already in the lead.

 

OK let's put it another way, what is the most complex game you have seen developed with Unity, by complex I mean big open world games with very high unit counts and or complex layers of simulation like Civ?

Are there any RTS's, MMO's, Sims made with Unity that just blow you away with the number of enemies active at any one time?

 

So Unity becomes a modular framework and all the module providers have to do is provide appropriate interfaces. But couldn't that leave Unity open to being a frontend for the Unreal or Crytech engines?

 

A 64-Bit editor would be very nice..

 

Agreed. Later Mono implementations have known performance increases. I vote for this.

Also, speaking as someone working on improving my design abilities (I already write code for my day job), I wouldn't see why we would want to go down to C++.

C++ is generally fast because it can be very low-level (e.g. memory operations), which is good for console development or performance-critical projects. However, for someone writing a 'simple' iOS or Android game, the level of abstraction that a managed language like C# operates at is just fine; instead of worrying with low-level things like memory management, I can focus on writing game logic and integrating assets.

I agree with others who say, 'we need performance improvements', particularly in regard to garbage collection. But I'm not sure C++ is necessarily the right way to go to get that.

 

You knew this would set me off again.

Yes, really... the slowest part of game development in Unity are the programmers themselves. I mean, for most C# vs C++ arguments, its the method not the language that's going to be the slow part. I mean we can always spread calculations across frames or thread it.

I really need that resource management stuff. Specially for what is coming now we've got a reasonable budget on the table coming up.

 

What about threading the the first tool a game developer is going to go for to offload work that makes a "layered" world come alive but does not impact game fps is threading.

So if my Unit is off screen and is not being drawn how comes it still takes up time in the main thread, could Unity provide an off screen thread for non-rendered active components?

 

You can write just as bad code in c++ as you can in C#. Meaning: the language you use will be way less important than the algorithms you use.

 

For a simple game you will be mostly writing code in extended versions of the Monobehaviour class so therefore memory allocation and clearing are not even an issue as Unity handles the instantiation and destruction of these objects. Also with C++ Unity can provide a memory management system that would ensure a games memory is allocated and used appropriately. All developers would have to do is use a Monobehaviour class that uses the system or a sub-class that allows them to create normal objects that use it, as long as they tell Unity when it is no longer needed.

Instead of relying upon a generic Garbage collection system we could have a system that provides pooling and object re-activation under the hood and only discards objects when instructed to do so.

 

You could do that with C# if you want to. Just pre-initialize a bunch of objects and pool them, then only use from the pool. As long as they don't ever go out of scope they won't get collected and if you were able to avoid allocating any new memory on the heap (not sure that's possible with Unity but it was with XNA) then you can avoid having the GC ever run automatically at all.

No, as far as performance, C++ is "generally" faster, but as others have said, it depends on the programmer. But if you had functionally equivalent and similarly written code, the code itself will perform virtually identically in both. The differences you'd actually see are all related to garbage collection and this can be nearly eliminated or managed by careful programming.

Now, you also mentioned earlier switching between the two languages and how "easy" it would be because the syntax is similar. Syntax isn't the issue. In fact, C# is a really easy language to learn, but the .NET Framework itself (in its entirety) is simply massive and takes longer to learn than the languages. A person starting out could become proficient in C#, F# and VB .NET from a syntax and style perspective without ever mastering a significant portion of the framework. That all being said, there's a massive difference between C# and C++. One is managed and one is not. It's not just about syntax. It's a whole different way of thinking because you have to carefully manage those resources yourself.

 

The parts of most games that are a bottleneck, rendering, physics, particles, etc. are already in C++, and seem decently fast. The key to optimization is optimizing that which needs it, not optimizing everything (this assumes you do not have infinite developer resources and time, if so, then you don't have to follow good practices ). Ultimately we're talking about a matter of scaling, and if the argument is your game is truly less fun if it's pushing 20% less 'things', then I'd love to hear that design. Even 2X less 'things', I think we're well past the point in technology where that is a blocking factor in game design.

This is not, IMO, the problem. The problem with current garbage collection is not that it's slow, precisely, but that there's not a low latency version of it. The .net spec has a low latency garbage collector (GCLatencyMode) but it doesn't work in mono (at least the version we're using). While faster (insert sub system here) would be better, the solution to our GC problems seems to be the support of that feature, not a replacement of the GC system/overall behavior. In short, the GC is missing a feature, not a refactor, IMO.

 

Unity's main slowdown will be chucking more on screen than the GPU can handle, and this is generally the developer's fault. Unity isn't a magic bullet (no engine is). If you look at the insane stuff Naughty Dog did with streaming, on a PS3, then you appreciate how much work can be required. Lucky for most, times have changed and the hardware is back to managing how much vertex processing you're using, how much fragment processing you're using and if you're threading in a good way. Threading isn't going anywhere. It's here to stay. For the most part, you want unity to deal with that and only thread if you really have to.

And threading is a massive can of worms.

Streaming isn't just going to be solved by threading something. It has to be solved in engine source, because part of the problem isn't getting the data, it's the stalls when you have the data. And I'm not all that sure what Unity can do about it at this point in time without some prior pieces in place.

 

Wow, your a mod? Thanks for donating your time

 

Okey this discussion is above my league and this might be a bit besides point but I believe Civ V and IV both use scripting languages for game logic. Lua and Python respectively. But then again Firaxis' tech is delicated for that style of games and I have no idea for how much stuff they actually do use those languages for. Might be 99.99% C++.

 

Considering that plenty of in-house game engines use languages like Lua for their scripting by choice despite having direct access to C++ already I think it's pretty clear that there are benefits to be had by stepping out of C++ land. C++ might indeed be a faster language, but - like any other optimisation - unless your language is your bottleneck then changing it won't help.

A faster language does not necessarily lead to faster execution. The places where the benefits of C++ are most pronounced are the places where Unity already uses C++ exclusively - the low level engine code.

At performance programming classes I've attended the game logic that we put in scripts is what's typically known as "slow code" by performance programmers. It's called that because by its nature it often does stuff that there's not a lot of benefit to optimising at the low level, often because more time is spent accessing memory than actually executing instructions, even when implemented in a slower language.

 

here take a look

c++ vs c#.net
http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET

c++ vs mono
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all〈=csharp&lang2=gpp&data=u64q

.net vs mono
http://geekswithblogs.net/CISCBrain/archive/2005/08/28/Mono_vs_dotNet_Performance_Test.aspx

also keep in mind the mono/.net have just in time compilers (jit)

so that really helps over purely interpreted msil bytecode.

well that is with microsoft .net, mono .net can at times be slower and use a whole lot more memory.

and to make things a worse the version of mono integrated with unity is really old and from what ive read even slower, fatter and buggier...

so hopefully unity will update mono in the not too distant future

and it would really be nice if they would give ability to use microsoft .net runtime eventually...

still it depends on the programmer. and how they do things. i mean they could code a really bad data structures/algorithms.

but all being equals assembly language, c, c++ and then something like .net, and then java and other managed jitted languages and towards the end (being worse) is like lua which many games developers use, why because its not jitted so no native compiler and it does not support native threading so all the game logic will run in a single thread on a single core.

i know there is luajit, but they dont use it. they use luaplus for the most part and it does not support luajit. i did luaplusjit, but i dont know of any game that uses it. i guess they are too lazy to link against some other library...

lua in general is up there with unreal script both about 20x or more slower than natively jitted languages like c# or even luajit...

re: civ

from what i recall they use lua, most likely luaplus. lua plus is just lua but c/c++ interface to it. the thing is its very dated and not really supported anymore. lua/luajit is where its at now for the lua crowd.

personally i think they should give up on lua and head over to mono/java where its even better. its hard to do a little language without all the $$$$$ and developers that the big guys like oracle(sun) java and microsoft (novell) have with .net...

 

They already do, if you're publishing to Windows 8 store or WP8—that's why you can't use obsolete collections like ArrayList and Hashtable on those platforms, since they've been removed from the latest .NET. And there have been various performance complaints; apparently some aspect of it is slower than Mono...so don't assume that it's magically better. I think this idea that the version of Mono currently in Unity is so terrible, and upgrading it will make everything a million times better, is perhaps not actually based on reality. (That's not to say that it couldn't be improved, just don't expect anything earth-shattering in real-world usage.)

--Eric

 

re: hashtable / arraylist

i have latest visual studio / .net and i have no problem using ArrayList and Hashtable. its in using System.Collections;

metro is not desktop. its more limited api like on mobile devices. winrt (metro) is more like compact .net so its a subset they take out stuff. in this case they took out non generic collections.

anyways i would not be there if i could help it..

although i dont do metro. why reward/encourage/support bad behavior/decisions...

bad enough that i have to run windows 8.1 the last thing i want it anything to do is spend time there...

? does that work for windows desktop game or metro games?

i dont do metro, but i repeat myself, im starting to sound like sam-i-am out of green eggs and ham

i meant for windows desktop games. like the ones i play with..

also i did not say .net is always better/faster/smaller than mono

look at the link i give

i didnt say million times faster. and i did not say horribly terrible or magically better

but a lot of improvements and bug fixes to mono, including the garbage collector...

there are number of threads on the version of mono with unity and that garbage collector...

i dont expect anything but what they improved and fixed and it would be nice if we did have it in some upcoming release of unity...

and it would be nice if i could run the editor and if not the games in microsoft .net runtime. without metro...

also metro .net apis are subset of desktop .net api
http://msdn.microsoft.com/en-us/library/windows/apps/br230232.aspx

i personally dont like metro.

also metro application go through additional security scrutiny and limitations which can result in them running slower and having issues cause the loops it and one has to play.

basically microsoft runs them walled off sandbox container and its expensive to get in and out, if not outright difficult and/or impossible. its more designed for phone... or like browser...

here take a look
http://www.extremetech.com/computin...ction-in-windows-8-is-an-absolute-train-wreck

plus its hard to find benchmarks. cause i dont know of anyone doing modern ai (modern in name only, cause its a step back in time and functionality)

so i would not judge desktop .net by metro .net, personally i would not waste my time there. i guess it great for app store games, but i dont play any of them. apple did better job, although i dont like their dev tools, languages, libraries. sort of something out of time.

 

Metro games AFAIK.

 

This would be true if they updated to 2.8 and not 3.x

 

I'm pretty certain that you're right. I'm sure that Unity wants to improve things as much as any of us do, and they've experimented with it before, so I'm sure that if it was going to make such a pronounced difference they'd have gone ahead and done it.

So you honestly believe that 3.x would give us "magically better" results?

 

In a lot of senses, yes. Especially when it comes to things like Unity's terminally slow garbage collection.

 

A completely off the top guess of mine is that Unity is working on their own implementation of the .NET framework, that will come in Unity 6.2.3. With the framework will come the new unified renderer that will fix all the issues on all the platforms, the word "Unification" will be spoken of heaps and will get old real quick.

 

here is my take on metro ui

parody of Dr. Seuss' Green Eggs and Hame
https://en.wikipedia.org/wiki/Green_Eggs_and_Ham

Code (csharp):

1.  
2. I am Sam
3.  
4. I am Sam
5. Sam I am
6.  
7. That Sam-I-am
8. That Sam-I-am!
9. I do not like
10. that Sam-I-am
11.  
12. Do you like
13. metro modern ui
14.  
15. I do not like it,
16. Sam-I-am.
17. I do not like
18. metro modern ui.
19.  
20. Would you like it
21. Here or there?
22.  
23. I would not like it
24. here or there.
25. I would not like it
26. anywhere.
27. I do not like
28. metro modern ui.
29. I do not like it,
30. Sam-I-am
31.  
32. Would you like it
33. in a house?
34. Would you like it
35. with a mouse?
36.  
37. I do not like it
38. in a house.
39. I do not like it
40. with a mouse.
41. I do not like it
42. here or there.
43. I do not like it
44. anywhere.
45. I do not like metro modern ui.
46. I do not like it, Sam-I-am.
47.  
48.  
49. Would you use it
50. in a box?
51. Would you use it
52. with a fox?
53.  
54. Not in a box.
55. Not with a fox.
56. Not in a house.
57. Not with a mouse.
58. I would not use it it here or there.
59. I would not use it anywhere.
60. I would not use metro modern ui.
61. I do not like it, Sam-I-am.
62.  
63. Would you? Could you?
64. in a car?
65. Use it! Use it!
66. Here it is.
67.  
68. I would not ,
69. could not,
70. in a car
71.  
72. You may like it.
73. You will see.
74. You may like it
75. in a tree?
76. d not in a tree.
77. I would not, could not in a tree.
78. Not in a car! You let me be.
79.  
80. I do not like it in a box.
81. I do not like it with a fox
82. I do not like it in a house
83. I do mot like it with a mouse
84. I do not like it here or there.
85. I do not like it anywhere.
86. I do not like metro modern ui.
87. I do not like it, Sam-I-am.
88.  
89. A train! A train!
90. A train! A train!
91. Could you, would you
92. on a train?
93.  
94. Not on a train! Not in a tree!
95. Not in a car! Sam! Let me be!
96. I would not, could not, in a box.
97. I could not, would not, with a fox.
98. I will not use it with a mouse
99. I will not use it in a house.
100. I will not use it here or there.
101. I will not use it anywhere.
102. I do not like it, Sam-I-am.
103.  
104.  
105. Say!
106. In the dark?
107. Here in the dark!
108. Would you, could you, in the dark?
109.  
110. I would not, could not,
111. in the dark.
112.  
113. Would you, could you,
114. in the rain?
115.  
116. I would not, could not, in the rain.
117. Not in the dark. Not on a train,
118. Not in a car, Not in a tree.
119. I do not like it, Sam, you see.
120. Not in a house. Not in a box.
121. Not with a mouse. Not with a fox.
122. I will not use it here or there.
123. I do not like it anywhere!
124.  
125. You do not like
126. metro modern ui?
127.  
128. I do not
129. like it,
130. Sam-I-am.
131.  
132. Could you, would you,
133. with a goat?
134.  
135. I would not,
136. could not.
137. with a goat!
138.  
139. Would you, could you,
140. on a boat?
141.  
142. I could not, would not, on a boat.
143. I will not, will not, with a goat.
144. I will not use it in the rain.
145. I will not use it on a train.
146. Not in the dark! Not in a tree!
147. Not in a car! You let me be!
148. I do not like it in a box.
149. I do not like it with a fox.
150. I will not use it in a house.
151. I do not like it with a mouse.
152. I do not like it here or there.
153. I do not like it ANYWHERE!
154.  
155. I do not like
156. metro modern ui!
157.  
158. I do not like it,
159. Sam-I-am.
160.  
161. You do not like it.
162. SO you say.
163. Try it! Try it!
164. And you may.
165. Try it and you may I say.
166.  
167. Sam!
168. If you will let me be,
169. I will try it.
170. You will see.
171.  
172. Sam!
173. Now that I have tried it,
174. Now you will see,
175. I still do not like metro modern ui!
176. I do not!! I do not like it, Sam-I-am!
177. So now you let me be!
178. And I still would not use it in a boat!
179. And I still would not use it with a goat...
180. And I still will not use it in the rain.
181. And I still will not use it in the dark.
182. And I still will not use it on a train.
183. And I still will not use it in a car.
184. And I still will not use it in a tree.
185. It still is no good, not good you see!
186.  
187. So I still will not use it in a box.
188. And I still will not use it with a fox.
189. And I still will not use it in a house.
190. And I still will not use it with a mouse.
191. And I still will not use it here and there.
192. Say! I still will not use it ANYWHERE!
193.  
194. I still do not like
195. metro modern ui!
196. Sam-I-am
197.  

 

That didn't work... it was meant to rhyme and it didn't... this is madness!

 

i failed poety

 

There's one out there that deals with tens of thousands of units... but who cares about facts when hyperbole suffices?

 

What game?

 

I could be wrong, but didn't even the community's most vocal opponent of the current GC system end up deciding that it was better to pursue the ability to eliminate allocation than improve collection?

 

Yeah, great.

So what about third party assets? What about the increased dev time for lower power hardware targets? Yes, limiting allocation is a good idea, but that doesn't change how awful Unity's GC is.

 

re: Unity's GC

isnt it mono gc

or did unity write their own gc and not use mono gc