Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I want to create a performant 3d renderer for a tech demo at the university workshop. The engine will basically render a forested backdrop, in a small octrant.

I am thinking of writing the engine in a managed language, but I am in a dilema about a possible performace handicap.

Google search just gave some raw benchmarks, with C/C++ winning by vast margins. But I need some performance benchmarks, especially in these kind of softwares... (renderers)

Also, if there are performance slogs, what are their immidiate reasons ? (leaving out GC)

share|improve this question

closed as not constructive by Trevor Powell, Sean Middleditch, Tetrad Feb 20 '13 at 22:21

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
I imagine this question will get closed as it provides no real world situation or code examples –  Yakyb Feb 20 '13 at 11:12
1  
Maybe some answers from experts? –  Zed Feb 20 '13 at 11:37
1  
Why do you need benchmarks, and why can't you generate the benchmarks you want, yourself? –  Trevor Powell Feb 20 '13 at 21:14

1 Answer 1

up vote 7 down vote accepted

As always, it depends.

Generally speaking, an algorithm implemented in C# should not perform worse than in C/C++ for arbitrarily large inputs. Using a "fast" language is not a substitute for a good algorithm. As a concrete example, QuickSort in C# will always beat InsertionSort in C/C++.

Rendering itself is a non-issue. If you're using hardware acceleration, rendering itself will happen on the GPU, which doesn't really care about what language the host program is written in. If you can manage to have the majority of processing get done in the GPU, there will be little difference in the language you use to write your engine.

However, there are things that managed languages such as C# are not very good at, some of which are very relevant in game making. Specifically, memory handling is much slower in C# than in C/C++, because every memory access is checked by the runtime. For example, copying an array element by element is much slower in C# than in C/C++.

But fear not, C# offers several tools you can use to optimize specific pinpointed areas of your code. You may want to look into unsafe, fixed and in general, usage of pointers in C#.

If all fails, you can always write your specific high performance routines in C/C++ and call them from C# using P/Invoke. I did this when making a game engine with scripting capabilities in Lua: I made interfaces for my engine functions and called them from the scripting engine written in C, which used LuaJIT, which is blazing fast.

You can also use P/Invoke to call native high performance functions like CopyMemory() without having to write them yourself.

On the other hand, the development costs you can save yourself by writing a very complex program like a rendering engine, in C# may seriously outweigh the performance advantages you may get by writing it in C/C++.

So in my opinion, if you can write your program in C#, you should do so. Unlike other languages (-cough- Java -cough-), C# offers you lots of options to optimize pinpointed bottlenecks, while maintaining a good high-level abstraction for the rest of the engine.

On the other hand, you should use C/C++ in the following cases:

  • You know C/C++ much better than C#, and it's impractical to learn C# just for this project.
  • You are working on a platform in which C# is not supported.
  • You are running on a severely memory/cpu constrained architecture.
  • Extensive memory-jockeying is central to your program, in which case it's simply not worth it writing few parts in C#.
share|improve this answer
2  
Note: P/Invoke causes the CPU to halt and switch modes which is quite a lot of overhead so you shouldn't use it to call small algorithms. An interesting link concerning the performance of DirectX wrappers for C# like SharpDX: code4k.blogspot.nl/2011/03/… –  Roy T. Feb 20 '13 at 12:15
3  
Note that in that link its about the performance overhead of draw calls. After that everything is handled by DirectX and the performance is the same for all languages. Your application will probably not be CPU bound on draw calls so it isn't really an issue. –  Roy T. Feb 20 '13 at 12:17
    
What about access to native simd instructions? –  Zed Feb 20 '13 at 16:21
    
@Zed Mono.Simd seems to partially support some extensions, and there's a library by Intel that also seems to do some SIMD. I haven't used either, but if everything else falls, you can always write that specific part in C and P/Invoke it. –  Panda Pajama Feb 20 '13 at 16:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.