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.

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.

The "^" operator isn't equivalent to a shared_ptr (if it were, you would have a ton of leaks, because shared_ptr's can't cope with circular references, and require the programmer to be able to explicitly choose between them and weak_ptrs...), it's exactly equivalent to C# references!
The dialect you're talking about is called C++/CLI, and it is compiled to MSIL -- the same intermediate "bytecode" language that C# is compiled to, and it runs on the same VM and uses the same Garbage Collector that C# does!

Scratch that!

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.

What changed is that C compilers got smarter and smarter, to the point where they can now write assembly as well as experts can (when given sensible inputs). Likewise, C++ compilers got smarter and smarter, to the point where they matched C compilers.
Following the same tradition, C# compilers are also getting smarter.
Take note that because C# is a lot more restrictive on the programmer, operating on a completely different kind of 'abstract machine' to C/C++, the compiler actually has a lot more information available to it when making optimisation decisions.
e.g. C++ code can look pretty innocent, but still cause a lot of confusion for the compiler. As a straw-man, take this function:

void World::FindPlayerWithMinHealth( int& outHealth, int& outIndex )
{
 outIndex = -1;
 outHealth = 100;
 for( int i = 0; i != m_players.size(); ++i )
 {
  if( m_players[i].health <= outHealth )
  {
    outIndex = i;
    outHealth = m_players[i].health;
  }
 }
}

And then I call it with:

world.FindPlayerWithMinHealth( world.m_players.m_size, world.m_players.m_size );

When the compiler is compiling the function, it has to do it in such a way that the stupid line above will behave as expected. So, looking at it again:

void World::FindPlayerWithMinHealth( int& outHealth, int& outIndex )
{//these two lines could change any bit of memory anywhere in the system!!
 outIndex = -1;
 outHealth = 100;
 for( int i = 0; i != m_players.size(); ++i )//m_players.size() has to be re-called every iteration, perhaps it's value has changed.
 {
  if( m_players[i].health <= outHealth )//have to fetch m_players.begin every iteration, perhaps it's value has changed
  {//these two lines could change any bit of memory anywhere in the system!!
    outIndex = i;
    outHealth = m_players[i].health;//have to fetch m_players[i].health again, even though it just appeared above.
  }
 }
}