Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


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


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
70 replies to this topic

#21 iMalc   Crossbones+   -  Reputation: 2313

Like
0Likes
Like

Posted 27 December 2012 - 01:17 PM

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.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

Sponsor:

#22 smr   Members   -  Reputation: 1676

Like
2Likes
Like

Posted 27 December 2012 - 01:43 PM

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?



#23 EddieV223   Members   -  Reputation: 1406

Like
0Likes
Like

Posted 27 December 2012 - 03:25 PM

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, 27 December 2012 - 03:27 PM.

If this post or signature was helpful and/or constructive please give rep.

 

// C++ Video tutorials

http://www.youtube.com/watch?v=Wo60USYV9Ik

 

// Easy to learn 2D Game Library c++

SFML2.1 Download http://www.sfml-dev.org/download.php

SFML2.1 Tutorials http://www.sfml-dev.org/tutorials/2.1/

 

// SFML 2 book

http://www.amazon.com/gp/product/1849696845/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1849696845&linkCode=as2&tag=gamer2creator-20

 


#24 frob   Moderators   -  Reputation: 22226

Like
2Likes
Like

Posted 27 December 2012 - 11:11 PM

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.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#25 EddieV223   Members   -  Reputation: 1406

Like
-5Likes
Like

Posted 27 December 2012 - 11:50 PM


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, 28 December 2012 - 12:05 AM.

If this post or signature was helpful and/or constructive please give rep.

 

// C++ Video tutorials

http://www.youtube.com/watch?v=Wo60USYV9Ik

 

// Easy to learn 2D Game Library c++

SFML2.1 Download http://www.sfml-dev.org/download.php

SFML2.1 Tutorials http://www.sfml-dev.org/tutorials/2.1/

 

// SFML 2 book

http://www.amazon.com/gp/product/1849696845/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1849696845&linkCode=as2&tag=gamer2creator-20

 


#26 Hodgman   Moderators   -  Reputation: 30964

Like
0Likes
Like

Posted 28 December 2012 - 01:04 AM

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.
  }
 }
}

Edited by Hodgman, 28 December 2012 - 01:26 AM.


#27 rdragon1   Crossbones+   -  Reputation: 1200

Like
0Likes
Like

Posted 28 December 2012 - 01:11 AM

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!

 

If he's talking Windows8, he's probably talking about C++/CX, which looks basically identical to C++/CLI, except doesn't compile to .NET code, and in C++CX, the ^ hat symbol *is* used to denote something akin to shared_ptr (it uses refcounting), and suffers from the circular reference problem (they introduced WeakReference to deal with this)

 

http://en.wikipedia.org/wiki/C%2B%2B/CX



#28 frob   Moderators   -  Reputation: 22226

Like
4Likes
Like

Posted 28 December 2012 - 04:30 AM

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.

Let's not forget the context of a game engine, shall we?

I'd love to see some actual research showing that "c# and java are significantly slower when executing high work loads." Major companies like IBM and Oracle have neatly debunked that for Java. If you are looking for corporate database work you'll be doing it in Java. Microsoft did a fairly good job of debunking that for C# back in 2005, but it hasn't really sunk in yet.

You certainly can do many things in c++ that you cannot do in the other languages. Pointer manipulation and knowledge of the hardware can give you a performance advantage. This is much like the highly skilled assembly artisan of yesteryear.

However, let's consider how c won out over assembly. It certainly isn't faster to execute, at best it can match what the expert artisans produced. No, that isn't it. C took over because of its ability to develop software much more rapidly and in a way that did 't require expert artisans. The computers were faster and could spare the extra cycles that might be introduced by translating into machine code, the main cost of software was all the gruntwork, and that could be dramatically reduced with c. Those few places that needed to be hand-tuned by artisans could still be tuned, while the bulk of the work done more rapidly and with fewer bugs (read: cheaper) than the assembly counterpart. It also helped that you only needed to port a very tiny portion of code to move to new hardware, but in practice that wasn't much of a selling point.

Over the years new hardware features were exposed and were only available to assembly developers, but gradually those were made available to c programmers through libraries and later through compiler-specific features and options.

When C started to lose to c++ many of these same arguments appeared. It was bloated, it couldn't match what the expert artisans produced, it forced extra overhead with virtual tables, name resolution was a mess, and on and on and on. Yet the same factors caused its victory: The computers were faster and could spare the extra cycles that might be introduced in translation, the main cost of software was all the gruntwork, and that could be dramatically reduced with c++. Those few places that needed to be hand-tuned by artisans could still be tuned, while the bulk of the work done more rapidly and with fewer bugs (read: cheaper) than the c-based counterpart.

Over the years now hardware features were exposed and were only available through limited means, but gradually they were promoted to intrinsic operations and other compiler-specific features.

We are now seeing exactly the same thing with C#. Much of the business world saw this with Java, but games did not make that move. It is certainly true that an artisan in C++ or C can often craft slightly faster bits of code with those languages than with C#. However, computers are faster and can spare the extra cycles., the main cost of software is still all the gruntwork, and it can be done both faster and safer with C#.

The c++ artisan can do amazing things. Templates were often derided as a source of bloat, and then when template metaprogramming came around these artisans could produce code that compiled neatly but at a cost... Build times for some projects skyrocketed. The biggest pile of heavily optimized c++ I've ever worked on required nearly two full days on a build farm to compile. Sure the code was nice and fast, but when the turnaround takes so long the cost of development suffers.

Is there a place for these people in games? Certainly! There is a segment of the engine that needs heavily optimized code. But as we are discovering at my studios and others around the globe, that portion of the engine is extremely small and rapidly vanishing.

Something else is subtly different with C#. Java very nearly did this, but Sun couldn't quite manage to do it. Microsoft managed it: They constrained the language to work on a platform agnostic virtual machine. They forced the developers to live with some very tight constraints that many people don't like. But the constraints are more like the rules of art that enable more creative works to come from them: The constraints give us automatically-parallelizing compilers that can automatically split the work, balance it between processors, and do so just as well as the artisans of today can do --- with fewer bugs. The constraints enable code to re-write and re-optimize itself at runtime with no effort from the developer. We (and many other studios) have found that Mono on consoles is a great thing; we have ported to X360, PS3, Wii, WiiU, and even 3DS amazingly enough, and managed to do it for less cost than we expected because the core of the game targeted the C# virtual machine.

Tools developers have taken notice. Middleware is now touted with being CLR-friendly. Many developers are actively pushing on Sony and the other console developers for direct C# support. A rapidly increasing number of studios want access to hardware-specific functionality in c# compilers. And it is only a matter of time before that happens.

There are still features missing from the language, but that is true of all languages be it C++, Python, or Ruby. Sometimes you still need that tiny little boost a bit of assembly will give you. But those times are extremely rare.




Concluding this rather wordy post:

Talk with recruiters and headhunters, pay attention to the jobs and want ads, and you will notice that the only c++ programmers in demand are the artisans. Sure there is still gruntwork to be done in the language, but it is much dimished. The gruntwork of game development is rapidly moving away from C++. Sure the language has many great things, and I've made years of my living from being a language lawyer myself; but that time has passed. Our studio -- and many others -- paid the cost of porting to C#, and I can personally attest to the improvements it has made in what we can do. Not because the language generates magically different executables, but because the gruntwork can be done cheaper.

And when it comes to game development, cheaper will always win.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#29 Rattenhirn   Crossbones+   -  Reputation: 1782

Like
0Likes
Like

Posted 28 December 2012 - 11:02 AM

this rather wordy post
 
Excellent post!
 
I'd like to point out a few things that might not be accurate:
When C started to lose to c++ many of these same arguments appeared. It was bloated, it couldn't match what the expert artisans produced, it forced extra overhead with virtual tables, name resolution was a mess, and on and on and on.

Ignoring the name resolution mess, which has not much to do with the performance debate, there's still a difference between the additional features that C++ adds over C compared to what C# adds to C++.

First, let's look at a few things that C++ brought to the table:
OOP, including runtime polymorphism via ("virtual"), overloading, RTTI, exceptions and templates.

All of these are concepts that were possible to implement in C and integrated them into the language, while retaining the "do not pay for what you do not use" approach. Everything is optional, some things are even cost free, for example overloading, all of OOP, except runtime polymorphism and, for most part, templates. C++ introduced a multi paradigm approach to programming, which seems to confuse a lot of programmers, but is, in my opinion, essential to most often get the best tool for a certain job.

Now, let's see what C++ took away from C:
Nothing! Well, not strictly true, but nothing that really affects anyone.

One might argue, that it should have removed more stupid stuff from C, but then again, remember the "do not for what you do not use" approach, which makes all leftovers, by definition, benign.

Moving on to the differences between C++ and C#/Java.
What did they add?
Fully automatic memory management through GC, a VM for standardization of data types and interpretation or JIT compilation of "byte code", full reflection

Since they are not really an evolution over C++ or C, the comparison is a bit trickier. All of the improvements come with their penalties and are not optional. Every dereference operation has to go through an extra indirection to find out where the memory actually is, the compiler can't really throw stuff away, because the program can still access everything that has been in the source code through reflection, including the names and the VM makes access to system resources that are not already supported tedious or even impossible.

What has it taken away?
Free functions, templates (except for what generics cover), manual memory management, multiple inheritance (except interfaces), and more.

No I'm not saying these are all good or useful things to have, but I'd rather have the options and not be forced into a behaviour that suits the mindset of the creators of the language. Java was created when OOP was kinda new to the mainstream and "teh future", but now it's an old thing and there's a tendency to go data driven programming, for instance.

Some things that it takes away are downright bad:
The RAII idiom is no longer possible, because there's no way to tell when exactly objects are destroyed (C# works around that somewhat with "using"), the GC is unpredictable and introduces nasty pauses when not managed very carefully and there's no way to manage memory manually _at all_ (like, *gasp*, put in on the stack).

The attempt to push the vast subject of programming into a tight set of rules is what upsets me most about these "new" programming languages. I'd hope that something will come along, that adds new goodies, but keeps the old ones.
 
Tools developers have taken notice. Middleware is now touted with being CLR-friendly. Many developers are actively pushing on Sony and the other console developers for direct C# support. A rapidly increasing number of studios want access to hardware-specific functionality in c# compilers. And it is only a matter of time before that happens.

You know, popularity is not a good indicator of how good something is at something. Take a look at Cobol or, ironically, C or C++. ;)
 
 
Not because the language generates magically different executables, but because the gruntwork can be done cheaper.

Not sure what exactly you mean by grunt work, but if it's something un- or lesser skilled people can do, then it should be automated, regardless of language used. Remember, work smart, not hard! ;) j/k

#30 Tribad   Members   -  Reputation: 874

Like
0Likes
Like

Posted 28 December 2012 - 12:12 PM

C++ operates at a lower level of abstraction than C#. In C++, you could (if you wanted to) trivially fill an array with machine code, cast it to a function and run that code (it would no longer have any amount of portability at that point).

This worked with W95 the last time. Execution of data segments is not allowed in any OS available for the broad market.

It may work with OS that are designed for the embbedded market, but normally this is not working anymore.

 

I did that the last time for a Win-3.11 application written in C and at that time no one thought of C++.



#31 samoth   Crossbones+   -  Reputation: 4913

Like
2Likes
Like

Posted 28 December 2012 - 01:01 PM

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.

I'd prase it even more extreme:
What changed is that C compilers got smarter and smarter, to the point where they can now write assembly as well as better than experts can (when given sensible inputs). Likewise, C++ compilers got smarter and smarter, to the point where they matched outperform C compilers.

Neither assembler programmers nor C programmers will like this, I'm sure. But the stunning truth is that that's just what has observably happened. Take for example this statement from the Nedtrie home page:

... there are competing implementations of bitwise tries. TommyDS contains one, also an in-place implementation, which appears to perform well. Note that the benchmarks he has there compare the C version of nedtries which is about 5-15% slower than the C++-through-the-C-macros version

This sounds like total bollocks, but it is just what it is, go ahead and try for yourself.

For some obscure reason (stricter aliasing rules? RVO? move semantics? ...whatever?) a C++ wrapper around unmodified C code is sometimes not "just as fast" but faster than the original C code.

The same is true for C/C++ versus hand-written assembler code. I've been writing assembler since 1983, but I regularly find it hard to match (match, not outperform!) optimized C++ code nowadays. If anything, I use intrinsic functions now, but writing "real" assembler code is a total waste of time and an anti-optimization for all I can tell. The compiler does at least as good, and usually better. You may be able to work out an example where you gain a few cycles over the compiler, but on the average you'll be totally anihilated.



#32 Nypyren   Crossbones+   -  Reputation: 4495

Like
1Likes
Like

Posted 28 December 2012 - 01:34 PM

Execution of data segments is not allowed in any OS available for the broad market.

This is true, but it is not the entire story. In Windows OSes you can simply call VirtualProtect to allow execution of runtime generated code.

(Edit to fix broken formatting)

Edited by Nypyren, 28 December 2012 - 04:03 PM.


#33 frob   Moderators   -  Reputation: 22226

Like
0Likes
Like

Posted 28 December 2012 - 02:07 PM

This is true, but it is not the entire story. In Windows OSes you can simply call VirtualProtect to allow execution of runtime generated code.

I have no idea what this has to do with the topic at hand: Why C++ is chosen over C# as a game development language.

The same is true for C/C++ versus hand-written assembler code. I've been writing assembler since 1983, but I regularly find it hard to match (match, not outperform!) optimized C++ code nowadays. If anything, I use intrinsic functions now, but writing "real" assembler code is a total waste of time and an anti-optimization for all I can tell. The compiler does at least as good, and usually better. You may be able to work out an example where you gain a few cycles over the compiler, but on the average you'll be totally anihilated.

That is exactly it. When C++ compilers started taking over, it wasn't because they generated the fastest code. Now because of popularity and investment, they have been tuned to do it.

Java's had 15 years to mature, and is now the de-facto standard language for over 1/2 of all tablets and smartphones. That is in spite of it originally being derided as slow and bulky and non-portable, the opposite of it's promise.

C#'s had 10 years to mature, and it is hard to find a tools programming job without knowing the language.

It is not about what generates the fastest executable, but what executable gets generated the fastest. Sure an expert assembly artisan is able to write a game like Roller Coaster Tycoon that runs on a 486 and took four years to develop; clones appeared within a year that ran on modern hardware and played just as good -- they didn't take four work years, and they were profitable.

If you talk to recruiters and headhunters and tell them you know C++, they'll ask you what else you know. It isn't because C++ generates faster code at games, it is because studios have learned to be more productive with C#, Lua, Python, Ruby, and assorted other languages.

Productivity, not language performance, is the key feature.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#34 EddieV223   Members   -  Reputation: 1406

Like
0Likes
Like

Posted 28 December 2012 - 02:48 PM

Productivity, not language performance, is the key feature.

No this is not accurate. It depends on the application domain. For some projects performance is absolutely key. For others not so much.

Also, productivity is what has improved with c++11 in a BIG way. I'll admit though that it's still not quite c# level of productivity but its much better.
I'd prase it even more extreme:
What changed is that C compilers got smarter and smarter, to the point where they can now write assembly as well as better than experts can (when given sensible inputs). Likewise, C++ compilers got smarter and smarter, to the point where they matched outperform C compilers.

Neither assembler programmers nor C programmers will like this, I'm sure. But the stunning truth is that that's just what has observably happened. Take for example this statement from the Nedtrie home page:
That is exactly it. When C++ compilers started taking over, it wasn't because they generated the fastest code. Now because of popularity and investment, they have been tuned to do it.
This is true that modern optimizing compilers do a very good job these days. However the biggest gains in performance since c/c++ started are not from optimizing but from the evolution of the computer hardware.

"Moore's law is the observation that over the history of computing hardware, the number of transistors on integrated circuits doubles approximately every two years. The period often quoted as "18 months" is due to Intel executive David House, who predicted that period for a doubling in chip performance (being a combination of the effect of more transistors and their being faster).[1] "

While this law may not be followed exactly it does show that performance has been doubling nearly every two years, no level of optimizing can do that. So that is the biggest reason, c became affordable over assembly and c++ over c and so on. Even though the modern features of the languages when they were new, cost a performance overhead. The reason people would pay that price some times was for productivity. Speed of execution vs programming productivity.

Today's computers are so fast that most typical desktop application's can easily pay for the languages such as java/c#, in exchange for that extra productivity. However some cannot, or do not want to, due to the project domain calling for absolute speed.

However c++ is being upgraded now. C is still basically the same language as it was in the 80s. ( There is a new standard but it doesn't fundamentally change the language )

This is what c++ now has over c and assembly, and why it competes with c#, modern features have been added and many more are on the way. C# has many modern features and that is a top reason that it is so productive to program with. So now that c++11 is back in the game, expect the competition to heat up even more in the following years as c++ will have frequent updates with lots of new modern features being added.


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!
 
 


 
If he's talking Windows8, he's probably talking about C++/CX, which looks basically identical to C++/CLI, except doesn't compile to .NET code, and in C++CX, the ^ hat symbol *is* used to denote something akin to shared_ptr (it uses refcounting), and suffers from the circular reference problem (they introduced WeakReference to deal with this)
 
http://en.wikipedia.org/wiki/C++/CX
 
 
 


That's what I was talking about, thank you.

Edited by EddieV223, 28 December 2012 - 03:30 PM.

If this post or signature was helpful and/or constructive please give rep.

 

// C++ Video tutorials

http://www.youtube.com/watch?v=Wo60USYV9Ik

 

// Easy to learn 2D Game Library c++

SFML2.1 Download http://www.sfml-dev.org/download.php

SFML2.1 Tutorials http://www.sfml-dev.org/tutorials/2.1/

 

// SFML 2 book

http://www.amazon.com/gp/product/1849696845/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1849696845&linkCode=as2&tag=gamer2creator-20

 


#35 MichaBen   Members   -  Reputation: 481

Like
2Likes
Like

Posted 28 December 2012 - 03:42 PM

I see people talking about programmer productivity a lot, but I really wonder if this is really noticeable. The typical comparison that people make to suggest this is comparing making a simple GUI application in [language X] compared to using Win32 in C++. Of course this increases productivity, but not because of [language X], but because of using a proper GUI library. Anything other then pure Win32 will increase productivity of GUI development, a C++ GUI toolkit like Qt probably achieves the same productivity boost. The language is probably a minor factor here, most of the productivity is determined by the libraries and/or engines you are using.

 

Some aspects that do make a difference in productivity are better error detection at compile- and runtime, this can decrease the time needed to debug nasty bugs. How big of a difference this would make I can't really tell, but in my experience the majority of the debugging time is spend into logic errors, which are very hard to detect by any automatic system and therefore will not be much different with another language. Type and memory safety would be a nice to have, for high performance applications it would be nice to have this optional so you can enable it only for debugging, that way you can still benefit from it to decrease debugging time. Garbage collector systems and shared pointers are not suitable for this however, as these systems do not support being disabled.

 

But the main problem with things like garbage collectors and shared pointers is the fact that they don't solve any problems, only symptoms. For example you have an NPC referencing another NPC as target, and this NPC is then deleted. With manual memory management it would crash because of a dangling pointer, with 'automatic' memory management it would not collect the object and therefore not delete the NPC, even though your intentions were to delete it. So in the end, you removed a crash, but kept the bug. A system with possibility to assert that no references are left when you try to delete the object would really increase productivity here, as it tells you where the problem it, rather the crashes sometime later (C++) or obscuring the symptoms of the bug (C#). Also a system like that can actually be disabled in final release mode, if there are worries about it's performance. With a slightly customized version of the C++ unique pointer you can achieve this, significantly decreasing debugging time of pointer errors, while keeping 100% performance since you can fully disable this in release mode.

 

I think the main problem with C++ are programmers who refuse to use modern and safer features, like in my office it's still a crime to use the word "exception", and you will be frowned upon for suggesting to use templates instead of macros. Once in a while I still see raw memory being allocated for a temporary array that is deleted again the same function, while std::vector would do the exact same thing in a safer way. In that case moving to a different language does increase productivity, but mostly because people are then forced to drop their old habits from the C era.



#36 Rattenhirn   Crossbones+   -  Reputation: 1782

Like
2Likes
Like

Posted 28 December 2012 - 04:15 PM

Productivity, not language performance, is the key feature.


Since this seems to be your primary argument now, I've spent some time looking into that.

Productivity is very difficult to quantify objectively, and in my experience the main productivity gain you get from C# is the excellent library that comes with it, especially for GUI programs. Hence it's high usefulness for tools.

But it like to hear more about those productivity gains!



#37 Karsten_   Members   -  Reputation: 1635

Like
3Likes
Like

Posted 28 December 2012 - 07:29 PM

This is a hard one to argue because Microsoft and Sun (/ Oracle) have spent lots of money to discredit the "myths" that C# and Java are slower than native languages as part of their marketing techniques.

If you take look at some academic journals on compiler design and language implementation, it will become very clear to you that there is no possible way that a JIT compiled VM language (produced by your C# compiler) can be faster than native machine code (produced by most C++ compilers). Afterall, this isn't magic or voodoo. However much you would like to believe, it just can never be true ;)

Since academic journals arn't very interesting for bedtime reading, I have some slightly more straight forward examples...

Unity (big pusher of C# for obvious reasons) admits that .NET is slower than C++.

http://docs.unity3d.com/Documentation/ScriptReference/index.Script_compilation_28Advanced29.html

It [.NET code] is around 20 times faster than traditional javascript and around 50% slower than native C++ code
And the following is a comparison between C# and C++ with some nice looking graphs.

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

This uses the default Microsoft C++ compiler and although C++ is still the clear winner, in these tests, C++ would absolutely thrash C# if using specialized C++ compilers for the task, such as Intel's or codeplay's.

But to be honest, there is simply no convincing .NET developers... Hopefully the enlightenment this post gives them will be worth all the downvotes I am going to get ;)

Edited by Karsten_, 28 December 2012 - 07:36 PM.

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.


#38 frob   Moderators   -  Reputation: 22226

Like
1Likes
Like

Posted 28 December 2012 - 08:36 PM

This is a hard one to argue because Microsoft and Sun (/ Oracle) have spent lots of money to discredit the "myths" that C# and Java are slower than native languages as part of their marketing techniques.

If you take look at some academic journals on compiler design and language implementation, it will become very clear to you that there is no possible way that a JIT compiled VM language (produced by your C# compiler) can be faster than native machine code (produced by most C++ compilers). Afterall, this isn't magic or voodoo. However much you would like to believe, it just can never be true ;)
And there, I feel, we must disagree.

It does not matter when it is compiled. Ultimately it does get compiled down to hardware native code. The code is not run through an interpreter, it is compiled and run.


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

This uses the default Microsoft C++ compiler and although C++ is still the clear winner, in these tests, C++ would absolutely thrash C# if using specialized C++ compilers for the task, such as Intel's or codeplay's.

But to be honest, there is simply no convincing .NET developers... Hopefully the enlightenment this post gives them will be worth all the downvotes I am going to get ;)

Yes, he has lots of graphs and pictures. Did you actually read his conclusion?

Among them, he wrote: "I believe a performance-conscious C# programmer can write programs whose performance is comparable to similarly well-written C++ code."

That is hardly a damning accusation against performance.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#39 LordJulian   Members   -  Reputation: 151

Like
2Likes
Like

Posted 28 December 2012 - 11:14 PM

Well, since the original topic went straight to hell and since everyone is throwing their hat in the ring, here I come as well.

For me (a 6.5 years developer at a huge game company, working at a few AAA titles you might just have heard of - assassin's creed, anyone?, on all the major consoles out there), the deal is like this:

 

GAME DEVELOPERS (because this was the original context of the question) are choosing to build their engines in C/C++ because (choose any/some/all "of the below") :

 

- tradition: since forever engines were made in C/C++, whatever was before that couldn't really be called an engine

 

- 1st/3rd party libraries: there are literally millions of libraries and APIs written in C/C++ out there. Sure, most of them are junk, but you simply cannot build a complete engine without some of them. Also, you can access them in mostly any other language, but why should you? Plus, any translation is likely to cost you.

 

- platform support: even though it is basically the previous reason, it deserves a repetition: any platform owner (game consoles, mainly, for our purpose) will deliver their SDK that WILL target C/C++. That's it. If you want to use it in a different language, a wrapper is a must.

 

- The promise of gold at the end of the rainbow: raw memory access, the way you like it. Even though, at the beginning, you don't need it, when push comes to shove and the framerate just isn't high enough, you WILL want to fiddle with memory layout and all the other tricks in the book that will yield better performance. Don't mistake this point, it is for ninja-tier programmers, but if you want it, it is there. I've witnessed some very nice and some very low level trickery that was done by a colleague of mine for a PS3 project on a particle implementation that was very optimized on the main platform to begin with. The result was mind blowing, we almost got the particles "for free" on PS3, while them being a major strain on the main platform.  To summarize: given a good C# programmer and an average C++ programmer, the C# programmer will probably produce faster code on most of the tasks; but given excellent programmers on both languages, my money is on the C++ one, every time, anytime. He just has more wiggle room and the promise of total memory layout freedom.

 

- Rock solid compilers. The c++ compilers usually carry 20+ years of effort spent into delivering very very fast code. The things the C++ compiler does with your code are just amazing. The other compilers are catching on quite fast, so this is becoming a non-reason fast, but still, the C++ compilers (and linkers, specifically) are geared towards maximum speed output, given the proper switches. Granted, with a certain compiler, I was able to write a VERY simple program that gave WRONG results in a certain configuration, but that was a solitary issue, they fixed it and we never spoke of it since.

 

Well, there are a few more reasons, but basically this is it. And now an advice for you: if you want to do a game and you're sure you can do it in C#, GO AHEAD. It is a lovely language with quite a few tricks up the compiler's sleeve. If you want to do an engine... do it, for fun, in C++. You will never finish it on your own in reasonable time with production-ready features , but it's a very nice exercise and you will gain lots of benefits.

 

Have fun!



#40 3Ddreamer   Crossbones+   -  Reputation: 3159

Like
0Likes
Like

Posted 28 December 2012 - 11:54 PM

Which is faster,  C++ or C#,  is largely a matter of circumstances. 

 

To answer the question directly, C++ is faster, especially where compiling and precompiling are very demanded, such as the data intense and thread allocated needs of juggling many game engine areas of 3D objects, shading, sound, scene graph, and more.  In other words, C++ allows the extremely crowded type of subway, so to speak, to be organized for streaming flow.

 

The C# can in some cases actually be "faster" in those situations where game source code competes with game engine source code for memory allocation and threading, in such cases the threading and memory cache can be unpredictable which may cause unmanaged (auto) memory of C# to be ideal for game scripting.  In this case, it would be like an art fair and crowd, so to speak,  with C# where the data flows automatically without the micro-management of stream like C++ allows.

 

 

What I write here is really an over-simplification because there are ways to extend both C++ and C# to do the native strength of the other language to some extent through libraries.  C++ has managed as its native strength while C# has unmanaged for emphasis.Specifically, C++ libraries can let you have managed or unmanage memory allocation and C# ones are increasing allowing this flexibility, too.  Memory managed or unmanaged effects stuttering more then speed in general. 

 

When handling huge data demands, C++ wins in the speed context with compilation combined with managed memory, but the amount of advantage depends largely on the amount of variety to be handled.  By contrast, if you only had to handle one data stream, then the advantage of C++ over C# would be the least compared to situations when many threads are used and C++ has the advantage.

 

 

Summary:

 

C# is faster when the demands in terms of memory allocation and threading are mostly or completely unpredictable, such as is often the case with heavily scripting and dynamic game source code that needs unmanaged (auto) memory management.

 

C++ is faster when a wide variety of data streams are to be organized with generally known demands which enable memory and hence thread management, such as in game engine source code implementations.

 

Over the next 5, 10, or 20 years, the differences and advantages of C++ or C# will continue to close, C# and libraries being younger - evolving much like C++ before it.  In other words, in terms of languages and libraries, C++ is the mature adult but C# is the very young adult which is growing to close the gap in capability.

 

 

 

 

Clinton


Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

 

by Clinton, 3Ddreamer





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS