Unity3D and c++

Will Unity3D ever support C++?

Currently, the industry standard is still c++ and it's going to stay that way. If Unity3D would allow programming for not just the .NET standard but also the c++ Lib then their client base would surely double.

Studios that use Unreal engine are currently using it because C++ has better performance. If Unity3D adapted c++, more developers would come on board with Unity3D.

What is everyone elses opinions on this?

Is Unity3D going to support c++ in the future?

 

The guts of Unity are written in C++. Mono is just the scripting layer, and it's pretty standard for game engines to use something other than C++ for that. It's often something much slower than Mono, too.

What's more, if you are writing a script that needs to do some heavy lifting and moving it to C++ land would help, Unity Pro lets you write it as a native plugin and do exactly that.

And also, assuming that they're reasonably well designed and written scripts are usually a pretty small portion of a game's CPU time. If they're not well designed and written, moving them to a lower level language like C++ is likely to make the issues worse.

 

Unity Free lets you use native libraries too - http://forum.unity3d.com/threads/181401-Unity-free-plugins-and-native-DLLs
Also you may use C++/CLI and mix the managed and unmanaged code in proportions you'd like. It's not as comfortable as writing in C#, but surely possible.

 

Studios that use unreal don't use it "because it supports C++" but "because it's unreal, with the whole feature set". And unreal's done in C++ because C++ was the obvious choice back then. People too often mistake "big thing Y is done X good because X is good" with "big thing Y is done in X because X was the only viable alternative when it was started and you don't port over millions of lines of code for no reasons".

C# is (simd co support aside) in the same performance league as C++, it's within a few % behind / over depending on the scenario on anything but the simplest useless benchmarks

 

They already offer a source code license. http://unity3d.com/unity/licenses

WTF... I hope this is a joke.

 

It's certainly not a joke, it's well known outside of the fanboi / not reading crowd outside of syntetic benchmarks. Aside from the (very important of course) hardware instruction set direct support it's just in the same league, being marginally slower or faster in some real word scenarios.

I can well provide a small sample that tests C++ being 1000 times faster, i can also do the exact oposite, but outside of 10 liners small loops syntetic programs that test nothing, yea they're in the same performance league really, with a bit diferent performance characteristics tradeoffs (allocation being nearly free in C# but that cost being paid at GC time for example)

 

Small loops are critical to performance in some cases, though.

Both languages have their strengths and their weaknesses.

 

I believe, "synthetic" is the key word.

 

Yup +1 there, i'm not saying C++ beats C# on small loops, i'm saying making a small 10 lines program with a for int i = 1 to 1bajillon do something irrelevant is not a way to measure language performance, it doesn't represent the performance profile of a real program

 

Studios that use Unreal engine probably wouldn't have any problem getting the source code license of Unity.

 

Have you looked at C++ lately? It's an ugly, and unintuitive language. Feels like trying to read aramaic. I start falling asleep almost immediately.

 

C++ vs C#, here we go, ding ding.. round 1

 

Even the GC cost is unacceptable to many people. Do you think I enjoy that most unity mobile games have notorious a GC cleanup lag? There is a thread in this forum from people who think its the most important thing for unity to work on right now. The reality behind game performance is that tight loops run many times per second always take up the majority of the processor time. If I can reduce the loop time by even a small fraction I can get massive performance gains. Low level C++ specific optimizations and C++ profilers are disturbingly powerful. I once had a loop that I thought was as fast as it could possibly become. I ran my visual studio profiler, analyzed the profiler data and fixed my algorithm accordingly. It ran over 100 times faster.

 

DAMN IT!

Try C++11 its beautiful.

 

Indeed, but my point is that the performance gain from effective use of small loops is not limited to synthetic benchmarks.

I know a guy who works as a consultant for large game and engine development companies. His job is to help them optimize their engines at the low level to get the most out of particular hardware or to meet target performance specs. A lot of what he does comes down to breaking big loops into little ones and re-architecting how memory is used to best suit those loops on the target platform. It's not unusual for him to get performance gains in the same ballpark as the one Justin described.

I expect C# to be as fast or faster than C++ for the majority of everyday usage, and for the majority of coders (myself included, there). But when it comes to tasks where there's real world benefit to be had from optimized low-level code hand-crafted for a specific platforms (the kind of thing I'd expect to find in the guts of a game engine) I'm under the very strong impression that C++ has real-world benefits.

Mind you, this exact conversation used to be had over C++ and assembly in the past. As compilers got better I (think?) it became moot, and I expect that in another decade (maybe even less) the same will happen here, too.

 

The gc issues people whine about are legit complaints about unity's old mono. This has to do with unity not with c# also with the amount of per frame allocations they do
And vs's profile for .net works just fine too. Read what i said again, there's bothing wrong with tight loops in c# the key word was synthetic

 

It didn't just become moot. It became reversed with compilers usually doing a much better job than someone handcrafting assembly.

 

Right. And when high-level language runtimes become consistently more effective than people who hand craft code as described above C++ will probably start to get superseded by more modern languages for those roles, too.

 

And we're not there yet i'll grant that (by no means you can write regular c# and expect it to beat intel's c++ compiler+ custom code with compiler intrinsics for example) but it's definately (once again simd similar exluded) already in the same league when writing normal code in both languages

 

By a non-managed language with only slightly more novice friendly syntax than C++ and only after I have long been dead from old age.

 

Novice friendlyness is fairly unimportant, that's not the pro of c#. The pro is the modern multi paradigm features and all the integrated apis of .net. Like everything it's a tradeoff (large runtime)

 

unless you're already 100years old, just no

 

As I said, I agree with that. In fact, taking the other advantages into consideration (eg: not having to worry about memory management so much) it can be argued that modern languages make faster code for a lot of things. All I was getting at is that writing off the advantages of C/C++ as only being useful for synthetic benchmarks is dismissing a powerful tool just because it's harder to use.

I'm sure people said similar things about assembler, too.

I don't think it'll take that long. Remember, the faster the things get the more we can use them to help us figure out how to make them even faster.

 

Hey i never said that, i said people who claim that c++ is much faster than c# (just like those who claim the reverse) usually do so with leaningless micro benchmarks that don't represent true production code performance

 

The next time someone shows you a piece of code in C++ using simd/asm/whatever and says it is 100 times faster than the same written in C#, you can say "thanks" and show how easy it is to call this super-low-level-ultra-high-performance piece of art from a high-level C# program.

 

Well for the side of c++ this time it's not completely true as you pay a hefty cost for going from managed to unmanaged and back. So while you can do that in a few key places you can't justify it on small data sets (where the cost of crossing the boundary is higher than the speedup)

 

Yep, that's true. There's no much sense in calling a native code that just adds two vectors together.

 

Oi, not this again...

C++ is not innately faster than C# - at least not by much. Rather, C++ allows advanced developers to perform micro-optimizations which would be impossible in higher-level languages. Which of course, takes a lot of experience to do successfully, and the complexity bleeds into normal usage of the language.

If you've got a moment, listen to this talk from the developer of Braid: http://the-witness.net/news/2011/06/how-to-program-independent-games/

The key takeaway being that hours of your own life spent developing a game should be optimized with equal or greater priority than the execution speed or memory footprint. And when you factor that in, C# is a rather fast language.

 

Without going down the "you're doing it wrong and you don't need speed" route, which is frankly quite condescending, C++ is indeed faster than C# - often by a large margin. This is generally down to the fact C++ compilers are spitting out vastly better optimised code, and offer a lot more short cuts.

I'm not going to tell people how to do their jobs other than C# is an ideal scripting language, and C++ is an ideal engine language. But you can't go around saying they're in the same ballpark, because they're not.

I don't particularly want to program in C++ because I've been there, done that, and I'm very happy with C# (or even unity script) for the purposes of game logic. But if I was making an engine, it would not be in C#.

 

Got any reason to think so except urban myth of "because i think so"? Because i've seen a lot of "C++ is faster" from small 10 lines samples, and a lot of "they're pretty similar" from people who i trust respect and who actually are well known in their jobs and went further than typing 10 lines compiling comparing.

 

I'm not interested in arguing with you. Get some more finished games under your belt first.

 

This thread is about C++ performance vs C#, not specifically related to games, i don't see what this has to do with anything?

 

Okay, here:



Sodoku is a pretty typical real world scenario of say, a puzzle game, an RTS or just a game that requires array access. As we can see, C++ makes a complete mockery of both ms .net and mono isn't even on the right page for it. There are always corner cases where C# can come close, but you can read more here: http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET

And no, it's not a little "loop" test like you point out. In any case even if it was, it's still valid very much so for game development. The upshot is, C# is slower. And mono's version a lot more so.

 

I already know of this post, and of course it's not a little loop test, and no a little loop test isn't valid because it doesn't mean it will hold in context, it doesn't test so many things it's not even funny. Those samples are at around 50% which is quite a bit slower but definitely nowhere near the "100X speedup" claimed in some sample examples and much closer to the truth.

I'll give a lengthy answer to this but it's definitely not just a 1 liner so posting this as it may take some time.

 

You have $100,000. You have to make a commercial game engine using either C# or C++.

Which one do *you* think will give you best chance of success?

 

Actually it would be funny if he said C++ went for it, as i'm starting a C# one at the moment, we could compare in a year for kicks.

 

Yeah, let me refresh you:

You guys are now looking thick on a forum.

 

Btw i just did some testing on the sudoku test, it took 1 minute of profiling to see that 86% of the time is spend on indexing an array, just changing that to unsafe code should provide interesting results. I'll let you know

 

Here's my 2c.
The C++ in .Net is great for interfacing the two languages, but never meant for anything else.

C# has a philosophy of emphasizing programmer productivity, C++ has a philosophy of having all features have an understandable run-time signature. Linq and async/await will probably never make it into the C++ core language, only into slightly clumsier libraries for this very reason.

Because of that, I believe that C++ will be faster for a long time to come IF you've got people that understand how to use it and it's libraries.

I also find C++ more productive than C# for low level programming because I can do things in class design for C++ that I simply can't do in C#.

Having said that, the Unity framework allows me to write simpler UI code than I would have had to write in the other framework I was looking at. More importantly, it also has a robust ecosystem of libraries which are going to save me days of work.

I fully expect that It will be slower than the version I could have written in C++. I'm willing to live with that trade-off since that means that I can spend more time polishing the UI instead of writing much of the low level framework by hand.

 

Actually results seem to go exactly the way i expected, since all the time was spent on checked indexers on the C# side just changing those to pointers is getting the perf back.
Originally i had C# = 4.5 sec vs C++ = 1.5 sec, i'm not done switching and i'm already down to 2.0 sec on C#, so yea, same ballpark easily, should be really close when i'm done but even without being finished it's already 75%

 

Sudoku. Ok.

Let's listen to the author of the article:

He didn't but I did:



The upper group of bars is the original code using generic Array2D<T> class. The middle one is a simple replacement of that class with two-dimensional arrays. And the lower one is the same code but using one-dimensional arrays instead of two-dimensional ones. I could also change the code to use pointers instead of indices, but I was bored already.

There's only one thing I want to highlight ― When you compare different languages for performance, make sure the code you run is optimized and uses all the features/benefits of the languages. Otherwise your comparison doesn't make any sense.

PS
C++ executables show 1.4...1.8 seconds on my machine.

 

In my version i did pointers instead of indice for all 1d array hot from 4.5 to 2.2 sec (vs 1.5 for cpp) goong from your graph and what reamins in my perf log i assume if i changed the 2d arrays like you did the cpp c# version speed would almost match

 

If you want access speed for a multidimensional array in C#...avoid [,] like the zombie-infested plague it is. Use jagged arrays for access speed. (Just an observation of the above test)

EDIT: That's for larger arrays. I guess the size of a sudoku array might not be that big of a difference. Jagged arrays have more overhead at allocation time, but are quicker on accessing individual elements due to the nature of the [,] indexer vs [][] indexing.

 

Wow...43 responses and its all crap.

Whoever made this topic turn into a battle of c# vs c++ you're a total tard. This isn't a discussion on whether the .net framework is faster than c++.

It's fact that c++ is faster. My only reason for this post was to gather input from the community on whether or not you all believe c++ should be an option to use. I know you can use plugins, but it's not as easy as it sounds. It still requires c#.

I'm going to request that this thread be closed. Amazed at the children who browse this forum. Makes me not want to use this engine.


Best,

SubZeroGaming

 

No that's the whole point, you turned this in an argument in your OP as you stated your "opinion" as a fact, and stating it as a fact again, it's "not" a fact that C++ is faster. And calling people children doesn't simply make you right yknow. Coming from someone who "learns by doing" and says he struggled for "month" to use unity (from your signature links) i don't think you're really in a position to tell any of us (on either side of the argument) what is and isn't a fact and that we're childrens, you're the beginner here in this thread.

 

Here's my 2c.
The C++ in .Net is great for interfacing the two languages, but never meant for anything else.

They would have to put far too much work into supporting C++ for it to be worth it. I'd love to see it, I've got a lot of C++ code I'm having to convert to C#, but I don't think it's worth the effort for them to create and maintain across all the platforms.

 

Yeah, a total tard!

Studios that use Unreal engine are currently using it because C++ has better performance. - SubZeroGaming


Not only do you post what appears to be baseless opinion as fact, you make four key mistakes IIRC:

• Unreal supports the UnrealScript... which is *slower* than C#.
• Unreal engine costs big bucks, with said bucks you can likely get source access to Unity and script it in C++ to your hearts desire.
• Unity already supports C++ plugins... which should cover most C++ use-cases.
• Unreal != Unity - and as such likely has have a different market.

Thoughts?

 

Let me change the wording. C++ has some features that let you make your code do certain things faster than, say, C#. The actual performance of your code totally depends on you, your coding skills and the amount of time you have to spend. C# on the other hand has some features that let you get things done faster. The potential performance difference is not a deciding factor in most of the cases because

a) 80% of the time you write the code with no special performance constraints.

b) The rest 20% of the code will not be any times faster just being rewritten in C++. Again it depends on your skills and the problems you have to solve. For example, you may reach the memory bandwidth limit or any other limit. CPU is not the only possible bottleneck. Switching the algorithm or technique may boost the performance much more than switching the language.

c) The difference is potential, not necessarily real. Many times I decided not to optimize any further because the expected performance gain I could achieve (even if I switched to native code) simply wouldn't be worth the loss in maintainability (especially if I really switched to native code).

d) The difference is not that big that many people think.

If you still want to use C++ there are only two options in Unity (except buying the source license):

1. Use C++ /CLI that can produce both native and managed code.
2. Compile your C++ code into DLLs and use C# only to communicate with the managed API.

Both ways are possible but painful, I believe.

 

Right, and months on Unity. yes. Years with c++. I work with it professionally.

And Unreal does support C++ and unreal script. Their unreal script is similar to c# i believe. But they do support c++.

Alright. Discussion closed.

 

Huh, you make no sense.

And you..for some reason are unable to fathom that Unity does support C++ and you also make the really general claim that C++ is faster. Why..do you want to work with C++ primarily? Are you insane or do you have really specific needs, because either way Unity still supports C++.

And so does Unity?

Not how it works.