• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ynm

What kind of optimization makes C++ faster than C#?

66 posts in this topic

Hi,

 

Just out of curiosity, I heard that game engine is mostly written in C++ because it is faster. But I don't know what kind of optimization C++ can offer over C#, can someone give some highlights so I can have general ideas of it

 

Regards

1

Share this post


Link to post
Share on other sites
there is no particular reason other than language age and general direction. C++ compilers are older and always had performances as their main objective where C# compilers are younger and never had raw performances as their main objective.
The 2 systems have just different agendas.. C++ favors runtime performance over programmers' productivity, C#'s balance is more to favor productivity over runtime performance.

Final note.. no language will make an engine "faster". Programmers write engines, good programmers will write a "faster" engine in C# than some inexperienced programmer using C++. I don't think the reason to adopt C++ in game programming has much to do with performance at all, it's more down to easiness to interact other low level libraries, existing code and resources (developers) reuse and lack of a performing C# runtime on consoles. Edited by kunos
2

Share this post


Link to post
Share on other sites

It will be interesting to see how much the garbage collectors performance improves with asynchronous operation over the coming years. I've read some recent articles that suggest it is markedly improved.

1

Share this post


Link to post
Share on other sites
GC is another topic that always pops up in these kind of discussions... IMO is pure non-sense. GC won't trigger if you don't "new" stuff, and will be VERY fast if you don't have objects with medium life expectancy.. it's just a matter to take some time to understand how the system works and how you can make it work for you... it's much easier to learn to deal with .NET's GC than learning proper memory management in C++, simple or through the 6-7 "smart" pointers available.
Just as you try to avoid new and delete in your game loop in C++, avoid newing class objects in C# and GC won't cause any troubles.

 

But really what you're suggesting here is that to "solve" the problem of the GC needing to halt all threads and needing an unknown amount of time to complete, that you do "manual memory management" and try to avoid invoking the GC, which also means designing around ctors/dtors and doing init/cleanup of your objects yourself so you can reuse instances. IMO that's a lot easier to do when there is no GC to worry about, and you reintroduce the problems GC was meant to solve (ie dangling pointers).

0

Share this post


Link to post
Share on other sites
GC is another topic that always pops up in these kind of discussions... IMO is pure non-sense. GC won't trigger if you don't "new" stuff, and will be VERY fast if you don't have objects with medium life expectancy.. it's just a matter to take some time to understand how the system works and how you can make it work for you... it's much easier to learn to deal with .NET's GC than learning proper memory management in C++, simple or through the 6-7 "smart" pointers available.
Just as you try to avoid new and delete in your game loop in C++, avoid newing class objects in C# and GC won't cause any troubles.

 

But really what you're suggesting here is that to "solve" the problem of the GC needing to halt all threads and needing an unknown amount of time to complete, that you do "manual memory management" and try to avoid invoking the GC, which also means designing around ctors/dtors and doing init/cleanup of your objects yourself so you can reuse instances. IMO that's a lot easier to do when there is no GC to worry about, and you reintroduce the problems GC was meant to solve (ie dangling pointers).

 

I am not suggesting that. "Young" objects are collected by the GC without stopping the world... so those shouldn't create problems at all.

What I was saying is: be sensible... just as you are sensible with C++. And, if you really get in trouble with the GC, use the available techniques to avoid that (ie. object pools). Again, I don't see this being any more difficult than writing a custom allocator in C++.

I wrote a quite complex simulator using C# and never had any problem whatsoever with GC and/or stutters.. actualy, scratch that, I have never had any problem with any of my C# stuff with GC stutters... and I don't use object pools or any other trickery.. just try to be sensible in what I do.. understand the differences between structs and classes in C# goes a long way.

2

Share this post


Link to post
Share on other sites

Portability is the big one for C#, but as for why it's considered 'slower', a VM compiled language like C# has to be translated at runtime, so an operation in native machine code will always have a significant advantage in speed (although a good VM can overcome that with caching). The simple reason is that a simple CPU instruction will execute at least twice as fast as a VM language instruction that has to be translated and then executed. There's more work to do for every single instruction, so you don't get the same speed unless the VM uses tricks to get that speed for you.

 

That said, modern machines, as was mentioned, can execute horrifically suboptimal code at near instantaneous speeds, so there's no reason to avoid C# unless you're doing something very low-level that needs to be blazing fast for some reason. Even in those cases you can find ways of bending C# to your will if you must. My only real gripe with C# is that it isn't Ruby. If I'm using a VM language I want it to JIT compile from raw scripts that read like Terry Pratchett novels and I want it do some of the crazy stuff that Ruby can get away with such as dynamically redefining classes at runtime or that beautiful, horrible monster known as eval().

 

C# is taken a lot more seriously than Ruby, though. <sad panda>

Edited by Khatharr
0

Share this post


Link to post
Share on other sites

you dont seem to understand how C# runtime works at all, so your claim are as wrong as it gets.

Every single C# function gets compiled to native code by the JIT the first time it is invoked, from that point on, that function is running native code period. So the "more work to do for every instruction" is just... uninformed and uninformative.

This has been the case for ages, since Java started doing it loooong time ago.

2

Share this post


Link to post
Share on other sites
you dont seem to understand how C# runtime works at all, so your claim are as wrong as it gets.

Every single C# function gets compiled to native code by the JIT the first time it is invoked, from that point on, that function is running native code period. So the "more work to do for every instruction" is just... uninformed and uninformative.

This has been the case for ages, since Java started doing it loooong time ago.

 

just because it's 'native' code doesn't mean it's as optimized as running it through an offline compiler, which typically has a lot more freedom in how long it can spend generating optimized code. JITted code is typically not as efficient. On the other hand, there are also situations where JIT compilers can use instrumentation to re-JIT and optimize code based on data that offline compilers don't have access to.

0

Share this post


Link to post
Share on other sites
you dont seem to understand how C# runtime works at all, so your claim are as wrong as it gets.

Every single C# function gets compiled to native code by the JIT the first time it is invoked, from that point on, that function is running native code period. So the "more work to do for every instruction" is just... uninformed and uninformative.

This has been the case for ages, since Java started doing it loooong time ago.

 

just because it's 'native' code doesn't mean it's as optimized as running it through an offline compiler, which typically has a lot more freedom in how long it can spend generating optimized code. JITted code is typically not as efficient. On the other hand, there are also situations where JIT compilers can use instrumentation to re-JIT and optimize code based on data that offline compilers don't have access to.

 

where exactly did I say that jitted code is "as efficient as offline compiled native code"? 

0

Share this post


Link to post
Share on other sites
you dont seem to understand how C# runtime works at all, so your claim are as wrong as it gets.

Every single C# function gets compiled to native code by the JIT the first time it is invoked, from that point on, that function is running native code period. So the "more work to do for every instruction" is just... uninformed and uninformative.

This has been the case for ages, since Java started doing it loooong time ago.

 

just because it's 'native' code doesn't mean it's as optimized as running it through an offline compiler, which typically has a lot more freedom in how long it can spend generating optimized code. JITted code is typically not as efficient. On the other hand, there are also situations where JIT compilers can use instrumentation to re-JIT and optimize code based on data that offline compilers don't have access to.

 

where exactly did I say that jitted code is "as efficient as offline compiled native code"? 

 

was just pointing it out for others' benefit as it's a common misconception

0

Share this post


Link to post
Share on other sites
I think most game engines being written in C++ is simply because C and C++ are extremely portable languages. If there were another language that was equally as portable you might see more engines written in that. It doesn't hurt that one of C++'s goals is also to be performance king.
I am not sure what you mean by "extremely portable". Yes, in theory they are, but thanks to non standard extensions (although very useful, #pragma once for example), and different architectures, I would say they are most definitely not portable. You have to think about portability in your program design, something most java and C# developers don't even have to think about. C's target isn't to be portable, it is a system language, as I recall, Ritchie and Tompsons target was to have a language offering enough high-level support to not get lost in your code, while having the power to dance with single bits.

Back to topic:
I wrote a program comparing java and C++, the later iterations of java have a good runtime optimisation. Both programs syntactically did the same (as a java programmer would write a C++ program), multiplying BIG matrices. There was no big performance gap between java and C++. But when I rewrote the C++ algorithm to simply use pointer arithmetics, C++ ran several times faster than it's counterpart.

The lesson for me was: Yes, C++ is faster when you know how and you have the right problem to solve. But Java has become fast enough, the performance gap for your everyday business application is negligible.

E: You can even write cool indie game engines with C# and Java. Yes it is not as powerful as a C++ engine, but you don't try to make a better looking, more efficient engine than Source,Unreal and friends, right? Edited by Bluefirehawk
1

Share this post


Link to post
Share on other sites

[quote name='Bluefirehawk' timestamp='1356601825' post='5014655']
I am not sure what you mean by "extremely portable".
[/quote]

 

I mean there is a C / C++ compiler available for virtually every platform. This would be a prerequisite for all of the C# / Java / other language runtimes to exist, since all of the ones I know of are implemented in C / C++.

 

I'm not saying you don't still have to port your engine - you certainly need to port your engine to different OS'es / graphics apis / input apis / etc, but at least you can. For example, I don't think any of X360/PS3/Wii have a C# or Java runtime available - some have a form of C# you can use, but it's a severely restricted environment compared to native C++.

0

Share this post


Link to post
Share on other sites

[quote name='Bluefirehawk' timestamp='1356601825' post='5014655']
The lesson for me was: Yes, C++ is faster when you know how
[/quote]

 

This is a very important point. Many game engine developers have the "know how", but the problem you run into with managed environments is that even if you know how, you simply don't have low level enough access to implement the optimizations, so you're stuck. That's a deal breaker for a major engine to adopting a language.

1

Share this post


Link to post
Share on other sites

you dont seem to understand how C# runtime works at all, so your claim are as wrong as it gets.

Every single C# function gets compiled to native code by the JIT the first time it is invoked, from that point on, that function is running native code period. So the "more work to do for every instruction" is just... uninformed and uninformative.

This has been the case for ages, since Java started doing it loooong time ago.

 

Gosh, that's clever. I wonder if there's a name for that. Hmm... Let's call it 'caching'. I hope it catches on. Wait, I must be a time traveler because I already said:

 

 (although a good VM can overcome that with caching)

 

It's plain sense that a native instruction will cause less work than a native instruction plus translation. That's the whole reason why the VM caches the translated instructions.

0

Share this post


Link to post
Share on other sites

[quote name='Rattenhirn' timestamp='1356616507' post='5014691']
What remains is, that "cafe based" languages (Java, .net) need to assume a virtual machine to work properly. So runtime performance can only ever be as good as this virtual machine matches to the real machine used, causing more and more troubles as the virtual machine ages and the real machines progress.
[/quote]

 

I'm not biased towards either option, however I just wanted to point out that the same goes for compilers. There are plenty of good reasons to use either C++ or C# depending on your goal, platform, library restrictions and a multitude of other factors.

 

In response to the OP, yes as other posters have pointed out a lot of your runtime efficiency is all in how you design and structure the code. I'm repeating kunos when saying this but I feel it has to be reiterated. One experienced with C# will more than likely write better performing code than they could write in C++ without additional learning.

0

Share this post


Link to post
Share on other sites
I think the most obvious answer here is that the .NET runtime itself is written in C++.
So you can just write code directly in C++, or you can write code in C# that uses stuff written in C++ under the hood.
0

Share this post


Link to post
Share on other sites
I think the most obvious answer here is that the .NET runtime itself is written in C++.
So you can just write code directly in C++, or you can write code in C# that uses stuff written in C++ under the hood.

 

I'm not really sure that's relevant. I could write a C++ compiler in python. Does that mean that the code generated by my compiler would be at least as slow as code running under python?

2

Share this post


Link to post
Share on other sites
Continuous memory is also a big win for c++. When you make an instance of a class in c# it's really just a reference to the object on the heap. In c++ it exists on the stack unless you used new. This allows the computer to use the cache much more effectively. And with c++11 you can put these objects in say a vector and with move semantics efficiently have them moved around without problems or having to do a deep copy. Edited by EddieV223
0

Share this post


Link to post
Share on other sites
Hi,

Just out of curiosity, I heard that game engine is mostly written in C++ because it is faster. But I don't know what kind of optimization C++ can offer over C#, can someone give some highlights so I can have general ideas of it

Regards
Getting back to the original post:

The myth that C# is inherently slower than C++ is exactly that: a myth.

There are similar myths that Java was inherently slower than C++, and they are also a myth.

Early compilers in both languages were very pessimistic in optimization and did generate slower binaries. Those very early tools have evolved.

There are facets of the libraries that are faster, and facets of the libraries that are slower. But the languages themselves are equal.



C++ is the core language in large part because experienced programmers know c++ and know how to get solid performance out of it. When engines must be cross-platform it is currently easier to use c++ because the third-party vendors provide c++ based interfaces; the network effect has locked that language in power for the time being. That is changing rapidly as many third party vendors are clearly moving toward C# as their preferred interface.


When you take an experienced c++ programmer and try to turn them into competent Java or C# programmers, there is a clear learning curve as they must re-learn what patterns are expensive to use and which are cheap.

It is easy to write poor-performing c# code if you are not familiar with the language, and most experienced game engine developers are not very fluent in c#. It is difficult for those experienced developers to make the transition.

Many of the up-and-coming developers are able to write more high quality code in C# than the experienced C++ developers could do in C++. Few developers need to know raw assembly any more because there are more productive tools out there. My studio has been mostly in C# for six years now, and the difference between our c++ and C# code is incredible. There was a brief learning curve and migration cost, but it has been more than made up for by performance in creating games. It is easier to put more in the game, and our results are at least as good. It is easier to find skilled C# programmers who can write performance-critical code than it is to find C++ developers who can do the same.

There is very clear motion in the works. From my perspective nearly all our tools are written in C#, and a good portion of our engine and most of our game code is written in C#. Mono runs great on all the major consoles, and there is no need for JIT compilation since the tools can emit the fully-optimized binaries if you pass the right arguments.

The OP (and many others) have just made the assumption that C# is slower or more cumbersome. I heard the same thing in the 90s that C++ was bloated and more cumbersome than C. I read the same arguments in the 80's that C was painfully slow and could never replace the skilled assembly-writing artisan.

The question has never been "will c++ be replaced", but "when". I believe we passed the tipping point a few years ago. It is now more difficult to get a seasoned C++ developer than to get a seasoned C# developer who is also more productive overall than that c++ developer.
2

Share this post


Link to post
Share on other sites

Hi,

Just out of curiosity, I heard that game engine is mostly written in C++ because it is faster. But I don't know what kind of optimization C++ can offer over C#, can someone give some highlights so I can have general ideas of it

Regards

Getting back to the original post:

The myth that C# is inherently slower than C++ is exactly that: a myth.

There are similar myths that Java was inherently slower than C++, and they are also a myth.

Early compilers in both languages were very pessimistic in optimization and did generate slower binaries. Those very early tools have evolved.

There are facets of the libraries that are faster, and facets of the libraries that are slower. But the languages themselves are equal.

C++ is the core language in large part because experienced programmers know c++ and know how to get solid performance out of it. When engines must be cross-platform it is currently easier to use c++ because the third-party vendors provide c++ based interfaces; the network effect has locked that language in power for the time being. That is changing rapidly as many third party vendors are clearly moving toward C# as their preferred interface.

 
 
 
 



What you say about speed is just not accurate, c# and java are significantly slower when executing high work loads. There is a reason they develop their environments in c/c++. And there is a reason that hard ware manufactures write their drivers in c. These languages are faster, and are less waste full in memory as well.
 
When you take an experienced c++ programmer and try to turn them into competent Java or C# programmers, there is a clear learning curve as they must re-learn what patterns are expensive to use and which are cheap.

It is easy to write poor-performing c# code if you are not familiar with the language, and most experienced game engine developers are not very fluent in c#. It is difficult for those experienced developers to make the transition.

Many of the up-and-coming developers are able to write more high quality code in C# than the experienced C++ developers could do in C++. Few developers need to know raw assembly any more because there are more productive tools out there. My studio has been mostly in C# for six years now, and the difference between our c++ and C# code is incredible. There was a brief learning curve and migration cost, but it has been more than made up for by performance in creating games. It is easier to put more in the game, and our results are at least as good. It is easier to find skilled C# programmers who can write performance-critical code than it is to find C++ developers who can do the same.


A lot of what you say here is a bit whatever. However lets look at something. In windows 8 you can program in c++ however it is an interesting dialect of c++. There are no naked pointers. Instead they have what is really just a shared_ptr operator ^ .

This means there are absolutely no memory leaks in their version of c++. You can do this without using windows 8 if you wish. So you get the best part of C# in c++. It is rather genius I might add. And there is no need for garbage collection, everything is deleted properly. There is no garbage collector, and everything runs very fast. This is interesting because 2 of the major reasons developers chose c# over c++ is that c++ is very error prone due to miss use of pointers, including memory leaks. The other reason is that c# is easier to use. C++11's main goal was to clean up the language and make it easier to use, learn, and harder to create bugs. They really did a good job of that. So what you have here are the 2 of the top reasons people chose c# over c++ now fixed.
 
 
There is very clear motion in the works. From my perspective nearly all our tools are written in C#, and a good portion of our engine and most of our game code is written in C#. Mono runs great on all the major consoles, and there is no need for JIT compilation since the tools can emit the fully-optimized binaries if you pass the right arguments.
C++ is enjoying a huge resurgence because of c++11, even Microsoft creators of c# has been "Going Native". In fact they are so sold on c++ they have been investing in it. They paid for the new http://isocpp.org/ website for example, and have fitted the bill for many things the c++ organization needed this year.
 
 
The OP (and many others) have just made the assumption that C# is slower or more cumbersome. I heard the same thing in the 90s that C++ was bloated and more cumbersome than C. I read the same arguments in the 80's that C was painfully slow and could never replace the skilled assembly-writing artisan.

This is true, but what changed? Computers got faster, much faster and the cost of the more expensive language features became affordable.
 
The question has never been "will c++ be replaced", but "when". I believe we passed the tipping point a few years ago. It is now more difficult to get a seasoned C++ developer than to get a seasoned C# developer who is also more productive overall than that c++ developer.


Actually c++ is seeing a large resurgence in the industry due to being significantly upgraded to c++11, you realize that all these "Modern" languages have been getting patches and upgrades while c++ hasn't had new features added since 1998 and it still is in heavy use today, that says a lot. Not only has this changed with c++11 but they now have a complete structure in place to be able to release new upgrades to the c++ language every couple of years. In fact there are upgrades planned for 2013 and 2014

With that said, c# is a fine language, I like that language too. For a long time c# has been gaining ground and for good reason. It's been getting updated with features and things while c++ hasn't. Edited by EddieV223
-5

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0