25 replies to this topic

[147]

As the topic title indicates, I want to know which programming language is best for programming DirectX11? I know, that C++ in the most cases is the fastest, but I also read, that C# can also be used for DirectX programming. How much is the speed difference, or are there other advantages or disadvantages for C# / C++?

[Hodgman]

That's one of those questions where if you have to ask, it doesn't matter.
i.e. C# will be fast enough for you

[Dynamo_Maestro]

Most of my DirectX learning involved converting DX Samples -> C# and with the exception of startups being slightly slower in C# (although compile times make up for that) I never noticed any performance issues. Plus it was so easy to understand DirectX with less code and no COM crap

Even with terrible programming ;) I have had constant frame rates and nice performance. I had this C++ vs C# issue several months ago, not because of performance but because of almost every tutorial, guide, book was in C++, I suppose thats the downside of doing things in C#, they can all be converted but sometimes you get frustrated with translating;

You dont have to stick with just one language either, you are free to make use of both, personally I say use C# until you know 100% that you need C++ take advantage of both languages but only when you need to, chances are you wont ever need to use C++

I have recently become very fond of using C++ and C# together, it feels so taboo ;) Anyway whatever you are planning on doing will get done very quickly in C# and probably easier to change to careless of what is offered in C++, especially UI related work, which I found to be a pain in DXUT

[147]

If I undestood both post correct, C# is a Little bit slower, but easier to use. I also write C# since 2 years, which was an Advantage of using C#. Are there any Features of DirectX11 unusable with C#? And if there aren't very big differences in the use of DirectX, it should easily be possible to later convert the C# code to C++. Is the wayof execution the same as with normal C# (the code gets compiled to a code, which gets compiled with the JIT during runtime? Also I wanted to know if a type check is made only in the code of C# or also in DirectX, if I use it with C#?

[6677]

Microsofts directx wrappers to the .net framework have all been discontinued apart from XNA which uses directx 9 so is a little out dated and won't give you the low level access you want. Slimdx is a 3rd party wrapper and seems to be the way most people go with C#/other .net languages.

C++ is usually compiled straight to native code so doesn't need the .net framework (although there is also a variant of C# for .net). C#'s slowness compared to regular C++ only really comes down to the .net framework, any language using a virtual machine (.net, mono, java etc) is always going to be slower than native code (C, C++).

C# is easier to use than C++. Through slimdx you get the full feature set of dx9, dx10 and dx11, through microsofts outdated wrappers you get full access to dx9 only and through XNA you don't tend to get much access to directx itself but it does use dx9 under the hood.

Slimdx class names etc I believe are slightly different than native C++ directx but conversion of code over to C++ should be possible. Chances are you won't have performance issues on C# anyway, at least not until you start hitting AAA graphics and physics etc that aren't normally possible for a single developer

[mhagain]

For a techdemo with pure rendering and nothing else, the language chosen is very likely to be insignificant - work is going to be mostly done on the GPU so your graphics hardware will be the main determinant of performance, by a very large margin. You could probably even use VB Script (not that I'd seriously suggest it...) and not notice much in the way of perf difference. The only real CPU-side overhead will be from API calls, and on any performance graph that's going to be down in the noise - fillrate, shader performance, etc will be where your time goes.

So at this level choice of language is really not a factor, and if that's all you want to do, then go with the language you're most comfortable with.

As soon as you get into adding physics, AI, sound, networking, any kind of non-trivial scene-traversal, things change. That's where you want to pick a fast language with low overhead, but it's also important that your code is written sensibly and in a performant manner. It's easy enough to write stupid C/C++ code with heavy run-time overhead that can be crushed by any other language, so it should be obvious that choice of language is not as important as just doing things right.

[french_hustler]

Heh... Back when I started learning DX, I was programming in Visual Basic.
Use whatever you're comfortable with, especially if you are just learning and creating smaller scale graphical applications.
Whether you are using one language or the other, the Direct3d pipeline is the same.

For bigger scale project, I would recommend C++. If you are using C# for a large project and have done everything you could to get proper performance in vain, then porting a whole application to a more performant language will suck major balls.

Edited by french_hustler, 01 August 2012 - 01:21 PM.

[147]

Now my last two questions. Are there any resources/tutorials that are written in C# (only for the start, a simple example would be enough)? And, theoretically, if I writte the graphic component in C#, should it be possible to write the rest in C++, or am I wrong at this point (I mean that the parts, which consume more CPU power get written in C++, the rest in C#?

[6677]

Its possible to link unmanaged DLL's into .net applications, not necessarily an easy process (these basically include C++ class libraries etc) and accessing them is usually done through a .net class laid over the top of the unmanaged code, this is often referred to as a wrapper. Slimdx for example, you make a call to slimdx and then slimdx goes off and makes the calls into the directx library. A simple function like print4squares() will be able to be called with just that one line in a C++ application. If the function is written in C# then it can be called from a .net application with 1 line aswell. But calling it in an unmanaged DLL from .net it might require 5 or 6 lines of code before you get to being able to type the line you need hence why wrappers exist, with the wrapper you only have to type the one line of code again and it deals with conversion for you. Wrappers are still alot faster than straight porting a library to C# though. For example MOgre and Axiom are both versions of Ogre3d for .net. However MOgre is a wrapper around the original C++ library and Axiom is Ogre3d ported straight over to full C# code. With the same demo sample in MOgre I get 2 fps lower than the reference Ogre3d implementation (with a framerate in the multiple hundreds this is hardly significant) but on Axiom I can only achieve around half the original Ogre3d frame rate.

For 1 game I think just going with a single language may be much simpler. C# is still pretty fast and most of the time graphics will be through a wrapper and hardware accelerated. Axiom is probably one of the only non wrapped graphics libraries out there for .net. Physics will depend on what route you go down, rolling your own or using an existing library. Once again alot (but not all) physics libraries for .net are wrappers for existing C++ libraries but unlike graphics probably won't be hardware accelerated (unless you are using PhysX for which there is a .net wrapper for and also happen to have an NVidia graphics card, Bullet also has hardware acceleration as a user option but this is on a recent version that doesn't have a .net wrapper yet). A beginners indie game will be fine in C# coded properly. If you think you can cope with C++ though then by all means go for it. Just to show what .net can do (specifically XNA, not known which language, I assume C#):
this is of course just rendering, no physics (I think, the water has waves in it but whether theres any actual physics calculation or its just a pre coded effect I have no idea) or AI going on but damn its pretty.

Edited by 6677, 31 July 2012 - 04:35 PM.

[mhagain]

If the other components expose a COM interface you can just add a reference and use the interface directly. Releasing is a bit fiddly but not much, otherwise it's quite straightforward (I've done evil things such as Lotus Notes (spit) interop before, so I can be fairly certain this works!) If you don't want that you could otherwise just write them as standard DLLs and use dllimport. See http://msdn.microsof...8(v=vs.71).aspx for some more info.

Edited by mhagain, 31 July 2012 - 04:32 PM.

[JWalsh]

any language using a virtual machine (.net, mono, java etc) is always going to be slower than native code (C, C++).

This isn't true, by the way. In .NET, the first time you run a method it is compiled to native code and replaced in what amounts to the v-table. Any additional calls to that method will be native. So accessing "code" is nearly identical for managed as it is for native.

In addition, memory allocation in C++ is significantly slower than in C#. This is because the C++ allocator must traverse the designated user-mode address space looking for an available chunk of memory that's large enough to fit the size of memory you're trying to allocate. The longer your application runs, the more fragmented memory becomes and potentially the more difficult this will be, especially if you're leaking memory. With that said, a lot of people write their own allocator for C++ applications.

In C#, all memory is compressed and the next available block of memory is always pointed to by a reference. So allocating memory in C# is constant time, and almost instantaneous. With that said, attempting to allocate memory beyond the current generational cap does invoke a garbage collection, which can cause intermittent issues. But, proper memory management, allocating small bits at a time, etc... can cause the generations to change size over time and can result in very fast garbage collections.

Finally, when you compile your C++ code to machine language, the compiler is unable to make a large number of optimizations because it knows nothing about the machine your application will be running on. So it has to accept the "lowest common denominator" with respect to advanced CPU features. In contrast, when a .NET application is JIT compiled, it is compiled on the user's machine. Because of this, JIT compiled code can be significantly faster than code compiled natively on a dev's machine.

While it's true the .NET CLR still needs to leverage some of those available optimizations, which it likely does with VS 2012, it is untrue that a VM will always be slower than native code.

Oh, and on a related note, SharpDX generates binding assemblies from the DirectX headers/libraries without using C++/CLI wrappers. As a result, it's known to be significantly faster than SlimDX. It's also compatible with Windows 8 Metro Apps.

Edited by JWalsh, 31 July 2012 - 04:50 PM.

[Dynamo_Maestro]

If I undestood both post correct, C# is a Little bit slower, but easier to use. I also write C# since 2 years, which was an Advantage of using C#. Are there any Features of DirectX11 unusable with C#?

So far from what I have seen SlimDX / SharpDX have all the features of DX11, I really doubt they would have things missing, last I read SharpDX was missing a few classes from DX9 but that was about it.

[Tasaq]

If you are interested in c++ vs c# question this article may help:

http://www.codeproje...k-Csharp-vs-NET

It clearly shows that c++ is faster in the most of cases. Despite this I have chosen C#, because it's easier to code and it contain logical name for classes, functions and methods(no acronyms, I hate them in both openGL and directX api). You also doesn't have to worry about memory management. I also find it easier to debug because exceptions clearly states what I did wrong.

You should pick language that you are more familiard with and you sould also think if it will be suitable for your project. If you want to create simple indie game, c# all the way. If you want to create game that will compete with modern games, c++ will be better for this scenario

Edited by Tasaq, 01 August 2012 - 02:53 AM.

[JWalsh]

It clearly shows that c++ is faster in the most of cases.

If you pay special attention to the actual code being used, you'll see that he's intentionally using the slowest parts of C#, vs. the fastest parts of C++, even writing his own HashTable class when the C++ STL version is too slow for him. He's also not doing any dynamic memory allocation as part of his tests, which happens to be the part where C# shines. The end result is his tests are too narrowly defined to simulate any real application, and his choice of implementation suggests a specific goal of proving that C# is slower. I wouldn't view this as a legitimate benchmark.

[Hodgman]

C++ is very fast when used by a computer-science expert, who's aware of pointer-aliasing, cache-line-aliasing, pre-caching, data layout trade-offs, balancing algorithmic complexity with hardware realities, etc...

When used by a beginner, C++ is not only slow, but also very dangerous -- with programs seeming to work properly, but actually leaking resources and corrupting their own memory, causing bugs that a beginner has no chance of finding.

C# is much friendlier to beginners, and it's "performance penalties" aren't really that bad when you're not capable of writing expertly performant C++ code anyway.


Your talent as a computer scientist has a much bigger impact on performance than whether you're using native vs JIT/managed binaries.

Also, N.B. the tools that C++ gives you to generate blindingly fast code also do exist in modern revisions of C# (e.g. fixed memory, explicit data layouts, raw pointers, unsafe native code), it's just that they're generally not used by default because they lead to the same issues that make C++ a dangerous language.

Edited by Hodgman, 01 August 2012 - 09:48 AM.

[Tasaq]

If you pay special attention to the actual code being used, you'll see that he's intentionally using the slowest parts of C#, vs. the fastest parts of C++, [...]He's also not doing any dynamic memory allocation as part of his tests, which happens to be the part where C# shines.

This might be a little off-topic but could you provide me with some materials on this (not necessary tutorials, maybe articles or apis with faster implementation), I would be very grateful
Personaly, I think C# is very underrated language.

even writing his own HashTable class when the C++ STL version is too slow for him.

True, it also "made my eyes bleed"

[147]

I thank all of you for your helpful answers, and I think I will choose C# in combination with SharpDX, because I think I can concentrate more on the principles and the way of programming DirectX, if I use a simpler language, that I allready know. I think this could get a long, but interesting way ...

[Icebone1000]

C++ is very fast when used by a computer-science expert, who's aware of pointer-aliasing, cache-line-aliasing, pre-caching, data layout trade-offs, balancing algorithmic complexity with hardware realities, etc...

When used by a beginner, C++ is not only slow, but also very dangerous -- with programs seeming to work properly, but actually leaking resources and corrupting their own memory, causing bugs that a beginner has no chance of finding.

C# is much friendlier to beginners, and it's "performance penalties" aren't really that bad when you're not capable of writing expertly performant C++ code anyway.


Your talent as a computer scientist has a much bigger impact on performance than whether you're using native vs JIT/managed binaries.

Also, N.B. the tools that C++ gives you to generate blindingly fast code also do exist in modern revisions of C# (e.g. fixed memory, explicit data layouts, raw pointers, unsafe native code), it's just that they're generally not used by default because they lead to the same issues that make C++ a dangerous language.

Kind off topic..But this interest me a bit..
When you say beginner, looks like you talking about a beginner programmer, but to me, and correct me if Im wrong, you can master C#/java/whatever, but the only way to became a "no beginner" in C++, is programming in C++... do you agree with this sentence?

I mean, c# and java will teach you OOP much faster than C++ in my opinion, but the only way to learn the stuff that makes C++ powerfull(the ones you mention as being computer-science expert skills), is coding on C++.. Since other languages abstract out all of that stuff..

When I started programming in C# in the beginning of this year I realized how ridiculous hard C++ is, ive been programming only in C++ since I started to learn programming, the difference in productivity is scary.

Edited by Icebone1000, 02 August 2012 - 07:59 AM.

[Hodgman]

When you say beginner, looks like you talking about a beginner programmer, but to me, and correct me if Im wrong, you can master C#/java/whatever, but the only way to became a "no beginner" in C++, is programming in C++... do you agree with this sentence?
I mean, c# and java will teach you OOP much faster than C++ in my opinion, but the only way to learn the stuff that makes C++ powerfull(the ones you mention as being computer-science expert skills), is coding on C++.. Since other languages abstract out all of that stuff..

As I mentioned above, C# has actually added lots of the 'dangerous' C++ features, like raw pointers, and low-level performance tuning features, like explicit data layouts. So if you "fully master" every possibly usage of C#, then those skills will all transfer over to C++.
However, yes, C++ has lots of quirks of it's own that you still have to learn, like the rule of three, and it has it's own idioms such as RAII, which doesn't appear in many other languages.
So if you're comfortable with your computer-science and computer-architecture knowledge (which is theory that doesn't depend on any language) and you've mastered some other languages, you will find C++ much easier to learn than a complete beginner, but nonetheless you will still have plenty of new material to learn.

When I started programming in C# in the beginning of this year I realized how ridiculous hard C++ is, ive been programming only in C++ since I started to learn programming, the difference in productivity is scary.

Indeed, they don't call it a "productivity language" for nothing.
So, if you're a beginner programmer, it would be wise to start with a language that lets you focus on programming, rather than also having to focus on language-specific quirks and difficulties (which C++ has plenty of).

Edited by Hodgman, 02 August 2012 - 08:21 AM.

[french_hustler]

As I mentioned above, C# has actually added lots of the 'dangerous' C++ features, like raw pointers, and low-level performance tuning features, like explicit data layouts. So if you "fully master" every possibly usage of C#, then those skills will all transfer over to C++.

And C++ has added a lot of RAII features like smart pointers being part of the stl library.
I think that the language is moving in a direction that makes it really easy for beginners who have low knowledge of things like memory management to come in and write proper applications. Though you still have to learn the proper usage of such features since it isn't handled under the hood, it seems that both languages are advancing towards a common middle ground. But I'm just playing devil's advocate.

In the end, a programming language is just a tool. Like a sword-master, it takes a lot of practice to be proficient with your tool. I still say, stick with what you're comfortable with.

I do have a question though. Why is C# a "productivity language"? I've searched a bit and read couple threads on stack overflow but haven't found huge advantages in using C# over let's say C++ & QT. I've been programming with C++ for a loooong time now. Why should I pick up C# to further my productivity?

Edited by french_hustler, 02 August 2012 - 11:58 AM.