C# Vs. C++ Performance in a Client/Server App

Hi guys,

Well, I am currently trying to write myself a simple MMORPG (yes, it does seem a bit far fetched and all, but I like challenges), and even though I'm still working on the overall design (after I found out that implementing a thread-per-client system would stop being effective after approx. 12 clients), but I was interested if anyone knew how much of a performance hit C# takes compared to C++.

I understand that the hit will depend on what the program will do, and at the moment I am more concerned with the performance of the server than the client, so here is a description of what the server will do:

Accept TCP connections, and data asynchronously
Execute Database queries
Be Multithreaded, in C# it would probably be a queue data structure and a ThreadPool object for the processing....

Of course that is the base essentials of what it will do, but I can't really say much more since I haven't even designed it completely yet.

And then there's always the client, I was wondering if the performance of C++ compared to C# would be all that important, in this case? The client would obviously have to create at least one (or maybe more if say the chat server and world servers are kept on separate boxes) socket, if there would be more than one then sending/receiving would have to happen asynchronously. And the rendering would probably be via DirectX...

Now that all that junk is out of the way, does anyone here either have any personal experience with any of this in both languages, and would be able to provide a comparison, or any statistics that would be relevant.

Obviously writing the whole thing in C# would be much easier, but if the ease came at a large performance hit, I'd need to question my decision, all over again, and see if it was really worth it.....

P.S. I'm not sure what forum I should have posted this in, but I do know that if i'd posted this in the C forums, I'd get a biased answer, and if I'd posted it in the .NET forums I would have got another biased answer....

P.S.S. If anyone has written something similar (to the server, I mean), I was wondering if you would have any advice as to how I should implement it....

/me waits for the flames, :P

I have not programmed in C# other than a learning experience. C++ is closer to the machine so it will be faster. C# needs to be compiled first before it runs but once that is done it will run how the compiler and .NET determines it will run. iirc, Microsoft still recommends running time sensitive programs to be coded in C/C++. There should also be some advantages in using C++ since it inherently is more flexible.

Is there a reason why you limit the choice to C# or C++? There are a host of other languages that would do the job just as well, or perhaps even better. It is also common for games to mix several languages, e.g. C or C++ for the graphics engine, and a high level scripting language for the game logic.

For example, I know of at least one commercial MMORPG - Eve Online that has both the client and server written mostly in Python[1], with time-critical sections written in C or C++. It has successfully coped with over 15,000 simultaneous users.

IMHO C++ is fine for the low level graphics code, and if well written can outperform virtually any other language. The catch here is "well written" - some studies have shown that the skill of the programmer has a bigger effect on performance than the language used.

However I do not think that C# (or Java) is dynamic or high level enough for the game logic - you would be much better off with a so-called scripting language such as Python, Ruby, or Lua.

Another language to consider is Erlang - I have not used it myself, but I know it is a dynamic, high level language designed from the ground up for concurrent processing. I read of a comparison between the apache web server (written in C) and a web server (Yaws) written in erlang. Apache maxed out at 4,000 simultaneous connections, while the erlang server could happily cope with 80,000 on the same hardware.

Regards,

Dave - The Developers' Coach (and ex-games programmer)

[1] actually it uses Stackless Python, a variant of python optimised for running large numbers of micro-threads.

BTW, as you implied in your original post, the biggest limiting factor for a program like this is having lots of independent objects all running concurrently. If you try to create a separate OS thread for each object then you will run into big, big trouble, especially on Windows. Each thread on Windows can take up to 1Mb of memory, and has a large overhead for swapping between them. Linux is generally better but still cannot scale to the level needed for a large game. This is a much bigger limiting factor than the raw speed of the language used.

The alternative is to use a technique that does not require a separate thread for each object, such as coroutines or microthreads (also called fibres). Each of the languages I mentioned - stackless Python, Ruby, Lua, Erlang - support these in one form or another. Standard Python also has a 'greenlets' C extension available that adds microthreading capability, and is having coroutine-like capabilities added in the next release.

As far as I know C# has no facility for coroutines or microthreads. Ditto for C++, but then I have not seriously looked for either language.

Dave - The Developers' Coach

No particular reason, I'm doing this (more than anything else, other than a burning desire to make this work) to learn, and initially I was thinking of writing it in C++, but then one of my friends told me to have a look at C#, and what can I say it seemed




I guess it doesn't matter too much then what language is used, as long as, like you said, the time-critical, or at least time/resource intensive bits are written in C/C++, but on the other hand the majority of the base would be written in C/C++ then, because nothing is more time critical than having a persistent world, with minimal lag.....



I've never done anything on this scale before, so I have no idea what you mean by that, could you by any chance explain that a bit more?



I guess I'll have to have a look into that, thanks for the info though,



I guess I expressed myself badly then, that was my original idea, but I scrapped that once I realised the amount of overhead it would generate.



Thanks for the info, I'll have to look into that.

When it comes to the actual networking, no, there is little performance difference between C++ and C#. I've used both as part of the same system, so I speak from experience. C# merely wraps native winsock sockets, and the overhead of managed code is minimal in this case.

The question of the game, however is a different matter. C# has an advantage in that it's managed code, so the possibility of wayward pointers and memory leaks is nill, and trust me, if you use c++ you'll be dynamically allocating pointers left and right. However, that's counterd in C++ by the fact that C++ has deterministic object destruction (no garbage collection). When you free that memory, it's free, period, right then and there.

IMO, C# -- properly designed and on the right computer -- could easily handle being a server for a massively multiplayer game.

The question becomes which you prefer to code in.

Devcoach -- Win32 has fibers, and you can easily call Win32 from c++.

Thanks heaps for all the info, I would prefer to do things in C#, since it just seems so much simpler, though pointers did seem a very nice way to speed certain things up, I think I can manage without them,



Can you easily cal them from C#, or would I have to include some C++ code?

It's not that hard to call C code from C#; check out pinvoke.net for information on calling unmanged code from C#, especially ConvertThreadToFiber:

http://www.pinvoke.net/default.aspx...rtThreadToFiber

Also, definitely check out the classes in the System.Runtime.InteropServices namespace:

http://msdn.microsoft.com/library/d...ropServices.asp

Finally, I'm not sure you should do this. I don't know a whole heck of a lot *about* fibers, other than their existence. There is some overhead involved in calling unmanaged code from C#; it might be more than the performance benefits of using fibers in the first place. I think performance testing might be appropriate.

C# is actually very fast, and it also has pointers! They are classed as 'unsafe' code but if you need them they are there. If you know C# quite well then it is going to be a lot simpler to do it in C#.

Is Windows written in C# (or any .NET for that matter)? No, because the 800 billion lines of C code are much faster than the managed code. I agree that you have much more control over performance type issues when allocating memory manually and creating your own pointers and all of that, but C#, IMO, is certainly easier than C or C++.