Jump to content

  • Log In with Google      Sign In   
  • Create Account

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

#61 Telastyn   Crossbones+   -  Reputation: 3726

Like
-1Likes
Like

Posted 30 December 2012 - 08:53 PM

However, "pay for what you use" is exactly what makes C++ the most productive choice for the small sub-set of problems where it is (one of) the most productive language to choose from.


Certainly, hence why I said general case. I agree it's a design decision. I just think that a design that benefits a "small sub-set of problems" to the detriment of the others is objectively a poor one in a general purpose programming language.

I frankly don't see how that is at all contentious, unless you're saying C++ isn't a general purpose programming language biggrin.png



Sponsor:

#62 Hodgman   Moderators   -  Reputation: 30341

Like
1Likes
Like

Posted 30 December 2012 - 09:37 PM

Certainly, hence why I said general case. I agree it's a design decision. I just think that a design that benefits a "small sub-set of problems" to the detriment of the others is objectively a poor one in a general purpose programming language. I frankly don't see how that is at all contentious, unless you're saying C++ isn't a general purpose programming language biggrin.png

C/C++/C# are all "general purpose" languages (which is pretty meaningless; it just means they're Turing complete and are not DSLs...), but you'd typically call the former two "systems programming" languages, and the latter an "application programming" language, as those are the general domains that they're typically best at / used for.

e.g. Python is also a "general purpose" language, but is often called a "scripting language", because it's often used to write small "scripts" that extend the behaviour of a host program.

 

If you're a systems programmer, then the lack of simple manual resource management in C# turns out to be a "a design that benefits a "small sub-set of problems" to the detriment of the others"... So no, you can't objectively say that in the absolute.

Every sub-set of programming problems is small on a global scale, but on a local scale the size depends on who you are and what your job is.

 

Given the original topic of this thread (and the additional context of being on a game-dev site), it's clear we're discussing the (globally small) set of problems where specific manual resource management methods (and other options that you have in C++) can be more efficient than C#'s one-size-fits-all alternatives (such as game engines) -- and then also every other set where this isn't the case (such as corporate GUIs).


Edited by Hodgman, 30 December 2012 - 09:41 PM.


#63 frob   Moderators   -  Reputation: 21072

Like
4Likes
Like

Posted 30 December 2012 - 10:34 PM

Part of this confusion seems to be that a few people are assuming a monolithic and single-language system.

A game engine need not be in a single language.

Good engines rely on many different languages.

Thinking back over the decades of good engines I've used, the simplest engine remember was for the Nintendo DS, and it 'only' used six languages that I'm aware of. The major EA engine I work with today has no less than 15 languages, probably more if I dig deeper. They range through hardware-specific assembly and C and C++ and C# and Lua and perl and python and shader scripts and even a handful of custom languages for particle systems and audio control.

Looking at engines like Unity you see that it also isn't one language. Java, Objective C, C++, JavaScript, shaders, C# through mono, assembly language for many platforms, direct support for content from Maya and 3D Sudio, as well as Flash, Photoshop, and Fireworks. They don't limit themselves to just what is easy to do in C++.


Engines are non-trivial. Portions will be written in C++. Portions will be written in assembler. Portions will be written in shader languages. Portions will be written in scripting languages. Portions will be written in <<insert language or tool here>>.

When something is best suited for any language, no matter if the language is assembly or c++ or c# or lua or python, if that is the best language for the component then you should build that component in that language.

For the portion of the engine that needs c++, I strongly recommend it. If you go back through the thread you'll see I always have. For the portion of the engine that needs gameplay programming I recommend languages other than c++; it is not the language's strong suit.

When you need a hammer or saw or lathe or drill, use the correct tool. If you need systems code or bare-metal code or shader code or scripting code, use the correct tool. A game engine needs many parts. It would be foolish indeed to limit yourself to only a hammer when building a sports car. Learn to be comfortable with ALL the tools, or at least know when your favorite tool is the wrong one.
Check out my personal indie blog at bryanwagstaff.com.

#64 Blind Radish   Members   -  Reputation: 355

Like
0Likes
Like

Posted 30 December 2012 - 10:46 PM

Oh boy here come the flames.

Look, just make your project in C#.  When you find something particularly important is running too slowly, there is a way to write it in C++ and call it from your code.  It'll run as fast as you want it to run.

I'm betting /you/ will be slower with C++ than with C# in both productivity and program execution.
You want to get it working and then look for where you need improvement and improve.  Eventually you'll hit a wall with C# (maybe), at which point you can move over to C++ and have it fast enough to get the job done.  There's always room for improvement, so stop worrying about it lol.


C++ does exactly what you say.  You can shoot yourself in the foot.
C# makes reasonable assumptions and files the paperwork for you so you don't have to.  Maybe you don't need it filed in triplicate, but a well established protocol works even when you're not thinking hard about how you want to deal with a situation.  If you need triplicate, its there.  If not, no worries.  C++ only files in triplicate when you tell it to, and is willing to blindly do as you say.  If you mess up it's on you.  That is how it saves time.  By not double checking all of your instructions.

That, and they've been at improving it for a really long time.



#65 shadowomf   Members   -  Reputation: 315

Like
-1Likes
Like

Posted 31 December 2012 - 04:20 AM

Good engines rely on many different languages.

Sorry, but this is just plain wrong. Many different languages don't equal quality.

 

While there are many engines that are written in more than one language it's not necessary a good thing.

(I'm not counting scripting support into this, because scripting is often part of the game and the engine is only providing the possibility to script the game or game objects.)

 

Also you have to differentiate a bit more. E.g. having a library or engine that has multiple language bindings is a complete different thing than having an engine that's written in a dozen of different languages. Having many different bindings is something good, especially if the engine should be licensed to other developers. Having an engine written in many languages sounds like a horror story.

Again we are talking about the engine itself. I'm not saying that it's a bad thing to write your tools in something for appropriate (e.g. use C# for the tools and C++ for the engine itself). However if every tool is written in another language it's not a sign of high quality.

 

Thinking back over the decades of good engines I've used, the simplest engine remember was for the Nintendo DS, and it 'only' used six languages that I'm aware of. The major EA engine I work with today has no less than 15 languages, probably more if I dig deeper. They range through hardware-specific assembly and C and C++ and C# and Lua and perl and python and shader scripts and even a handful of custom languages for particle systems and audio control.

They don't use it because someone thought "hey great let us use as many languages as possible in our engine". Most of the time it grew historically and it's hard to impossible to get rid of it. Sometimes you have to add another language, for example to support a new platform or make use of a new library, however I'm pretty sure no experienced developer will make such a decision lightly.

 

And the many different tools and scripts all in different scripting languages is a sign of lack of direction. Obviously nobody decided to use only one scripting languages.

Or even worse imagine this scenario:

  1. In the beginning somebody choose perl as scripting languages, because he knew it already or he heard something about it.
  2. A few years later you decide to switch to python, because you can find more developers that also know python and in generally it seems like a nicer language or whatever. However you don't have the time to make a complete transition to python, because not all your developers are as fluent as they need to be for that. Besides your developers don't have the time to rewrite all the tools. So some modules are rewritten but most of them stay perl.
  3. Lua comes along and somebody made the decision to use it as main scripting language in the game. It's nicer for the artists and level designer and the developers do like it too. Great since you are already using Lua in-game, why not also for the tools? So without much hesitation your team decides to switch to Lua for tool development. Now most of your developers need some time to get familiar with Lua, they also have their usual tasks to do so again yo can't completly rewrite everything in the new language.
  4. You've got yourself a ten year old code base with 3 different languages (just for the tools). Whenever there is something to change on the older modules you need to find the perl or python guy. Since some of the tools are so old and complex, everybody is just saying "never change a running system" and nobody is touching the old code. If your last perl guy leaves you won't replace the perl tools, no developers will start writing tools in Lua or whatever you currently use just to integrate the old tools. "No, you need to run the converter script to make it work with tool X, when you're finished you need to run it again to make it work with our other stuff!"
  5. Of course everybody that reads this knows, a rewrite would be the best thing to do or better forget all about it and start from scratch. However if your studio can't afford it you need to make it somehow work. It gets worse every year and each project is getting more difficult, takes longer and gets more expensive. Maybe some day your studio does a complete rewrite, maybe they decide to license an engine from another developer. Or maybe your studio is slowly fading away into oblivion, like many before you.

 

Multi-language projects have many downsides, for example:

  • They are a maintenance hell. At my place of work (not game related) we have projects with Tcl, C++, Visual Basic, C# in one project (some modules stand on they own). It's just bad, I can't see any good about it.
  • Developers need to be fluent in many languages. This is especialy difficult if you have some rarely used, old or esoteric languages. Especially since some parts of the engine aren't tuched for a while and the developers aren't as familiar with it as with a piece of code they work regulary with.
  • New developers will need longer to get a grasp of the engine code.
  • It's harder to hire new developers, especially if you want them to have expierience with all of the used languages.
  • If somebody is developing a module in a different language than all the other modules you should take a close look. Is it neccessary or is he trying to make himself unfireable. If he is just trying to use arcane knowledge to make it hard for everybode else to maintain that module, he/she should be let go as soon as possible.
  • Each additional language means the development environment gets more complex. Not something you wish to achive.


#66 Hodgman   Moderators   -  Reputation: 30341

Like
0Likes
Like

Posted 31 December 2012 - 07:41 AM

Good engines rely on many different languages.

 
While there are many engines that are written in more than one language it's not necessary a good thing.
(I'm not counting scripting support into this, because scripting is often part of the game and the engine is only providing the possibility to script the game or game objects.)
Also you have to differentiate a bit more. E.g. having a library or engine that has multiple language bindings is a complete different thing than having an engine that's written in a dozen of different languages. Having many different bindings is something good, especially if the engine should be licensed to other developers. Having an engine written in many languages sounds like a horror story.

Yeah, it depends on how you define things. I think it would be pretty common to see:
* a language for the engine
* a language for the game
* a language for the GPU-side components
* a language for the tool-chain
* a language for data definitions
* a language for build automation

Some of them might be the same language, and some of the dot points might be several languages.
e.g. For the above dot points, I use C/C++, C++/Lua, HLSL/Cg, C#/VB/Batch/JavaScript+HTML, Lua, CMake/Batch.
That's around 10 languages in a modern engine with no legacy code.
The engine is C++, but contains some C modules, which is fine because the two interop so well.
The engine is bound to Lua, so the game is written in a mixture of C++ and Lua, depending on which is more productive in that area.
The obvious choice for the GPU portions is a standard shading language -- HLSL is great, and Cg is almost the same syntax, which helps when porting HLSL code to GL.
The data-processing parts of the tool-chain are all C# because it's a good language to work with and is very capable. Many GUIs are JavaScript+HTML because they're designed to be remote "web" tools, that are just thin GUIs that connect to either a C# data-cruncher, or the C++ engine in the background. Extensions of our art tools are VB, because they support it for scripting. Microsoft Batch files are sometimes used as glue.
Human editable data files are written in Lua, instead of JSON/XML/et al. because Lua is already the engine's scripting language, and it's also a great, flexible DDL.

Instead of being tied to a specific IDE "project file" format, the code builds are controlled by CMake scripts, which is a simple imperative language, again with some Batch glue.

 

Personally, I'd include all of the above inside the category of what "the engine" is made up of (not just the engine's runtime library itself).


Edited by Hodgman, 31 December 2012 - 07:43 AM.


#67 shadowomf   Members   -  Reputation: 315

Like
-1Likes
Like

Posted 01 January 2013 - 09:17 AM

Personally, I'd include all of the above inside the category of what "the engine" is made up of (not just the engine's runtime library itself).

That's where our opinions are different (which is not a bad thing).

I wouldn't count the following as part of the engine. Sure they are connected, but not part of the runtime.

  • Shaders - many provide some predefined shaders. But I believe shaders should be part of the game. Else all games use the same lighting style and materials it gets boring. Handwritten shaders often look more unique and can do so much more than shader that have been generated can. Besides aren't shaders assets?
  • Scripting - yes, provide the possibility for scripting, but I wouldn't put scripts in the engine.
  • The whole pipeline - Texture-, normal map-, lightmap-, mipmap-baking is all part of the tools. It's not shipped with the game and not part of the engine. It's part of the eco-system that engine developers provide to make it easy to use the engine. Most of the time the tools even work without the engine as well as the other way around.
  • Build tools - you wouldn't count Visual Studio as part of a game engine would you? Or cmd.exe. Just because somebody decides to replace either it's not magically becoming a part of the game engine. Would you count make as part of a piece of software that is developed with the gcc toolchain?
  • Web tools - see whole pipeline/build tools and I wouldn't count any other way to provide a pretty Gui for a simple tool.
  • Exporters - for Photoshop, gimp, 3ds max, blender, ... they are tools just as before, besides there are other ways (use standard formats).
  • The game - choose whatever language you wish to write the game. Provide multiple language bindings to use the engine. The game just is not part of the engine. Anyway if you go down that road, microsoft should start to claim that any piece of software written for windows is also a part of windows (well in some philosophical way it could be). Of course it's always possible to write a game without engine, which makes the engine somewhat a part of the game...
  • Libraries - If you use a third party library or API, for example OpenGL, the Windows API or any other library the library is not part of the engine. It's a dependency. I wouldn't count the languages used inside the library as part of the engine. Besides you can't always be certain what language it was written in.
  • Data definition languages or data in general - One of the points where we need to clarify which languages we mean. If we start counting not human readable data languages, we could include every binary file format that an engine supports. Besides the whole point only applies if you're using a data driven architecture, else it's just data and not part of the engine. Most data is part of the game anyway... so I would count this as assets.


#68 EddieV223   Members   -  Reputation: 1406

Like
1Likes
Like

Posted 02 January 2013 - 03:55 PM

Did it take over a decade to improve C++? Did this annoy the hell out of many people (including me)? Of course, but that is what design-by-committee is about. A design committee always makes any kind of process lengthy and complicated, that's just the way it is. It's not a miracle that someone at the top (1-2 people) dictating what shall be done happens in considerably less time than 40 or 50 board members meeting and discussing and trying to make every single one happy. This doesn't mean that what finally came out of it is necessarily bad, however.


It did take a long time to for this update to happen, from 98 to 2011. However, the future of c++ is amazingly bright, they now have many study groups of experts working on separate pieces of the language. These study groups work on the language and then bring there work back to the commite to be voted on. This is something that c++ has never had, more people are now working on the standard than ever before.


If you want to see exactly what I'm talking about watch this.
http://channel9.msdn.com/Events/Build/2012/2-005

he starts getting into the new standards committe about 22minutes in.

Study groups ( none of these existed before c++11 was released )
concurrency
modules
filesystem
networking
Tx Memory
Numerics
reflection
concepts
ranges
Feature Test
Databases ( being formed )

And also the standard agreed on a new time table for releases

ge3qu.jpg

Edited by EddieV223, 02 January 2013 - 04:07 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

 


#69 samoth   Crossbones+   -  Reputation: 4763

Like
1Likes
Like

Posted 02 January 2013 - 05:42 PM

Good engines rely on many different languages.

 

Sorry, but this is just plain wrong. Many different languages don't equal quality.

One could certainly do everything in one language, but that would be foolish. A good craftsman uses the right tool for the job. Insofar, using several languages in some way does equal quality (that assumes one doesn't just use many languages for using many languages!).

 

I am probably one of the biggest C++ fanboys, but I would never consider even for a minute writing part of a toolchain in C++. Why? Because C++ sucks ass for that.

Python, Ruby, PHP, take your pick. One line to read a whole file into an array, a dozen lines with 2-3 regex to do the whole magic, 2-3 lines to dump the binary stuff to disk. Two lines to read and parse an XML file, a dozen more to walk through it. Pipe to/from an external command... 1 line. Make a HTTP request or database query or similar... 1 line.

 

Do that kind of thing in C++ and you need half a dozen of libraries and will waste a week on writing something that (maybe, if you're lucky) does the same thing in three seconds instead of two, and that's a nightmare to maintain. It will take quite a few runs to amortize that week of development time. Every time you change something, you spend half a day on it again.

 

Level Editor? Written in 1/3 the time using C#, and they work quite OK. Could they be 20% "better" in C++? Probably, but who cares. They're functional, and they're not so slow that it takes away productivity. Spend your time on something different.

 

Then there's scripting, of course. Scripting (Angelscript in my case) is what usually runs not only the GUI, but almost the entire program. Unless of course you don't care about that kind of thing. How would I do that in C++?

 

So, you really don't have to make up something to get 4-5 different languages (and that's not counting domain specific languages like SQL or XML or JSON that you implicitly use too).



#70 Josh Petrie   Moderators   -  Reputation: 3115

Like
1Likes
Like

Posted 04 January 2013 - 04:34 PM

This is way off-topic for this forum now.


Josh Petrie | Core Tools Engineer, 343i | Microsoft C++ MVP


#71 EddieV223   Members   -  Reputation: 1406

Like
0Likes
Like

Posted 06 January 2013 - 02:31 PM

The discussion has been interesting and constructive at least, it didn't go flame war style like a lot of threads like this do.

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

 





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