I doubt there is one available now, its very new and no one would have had the chance to build an MMOG! You could be the first to try :)
I believe its possible.
Nick Darnell wrote:
One should never say never...but you do lose 15-20% performance moving to C/C++ to C#, possibly more depending on your code, and memory consumption is going to be a lot comparatively speaking.
If you're seeing that kind of performance hit, your code is very poorly written. C# performance is maybe 1-2% slower in some situations. In some situations it's actually faster than C++.
Jim Perry wrote:
Nick Darnell wrote:
One should never say never...but you do lose 15-20% performance moving to C/C++ to C#, possibly more depending on your code, and memory consumption is going to be a lot comparatively speaking. If you're seeing that kind of performance hit, your code is very poorly written. C# performance is maybe 1-2% slower in some situations. In some situations it's actually faster than C++.
Or it could be that your C++ code is poorly optimised! The trouble with these comparisions is they only tell you the relative performance of a given scenario, and assume that both languages are coded equally well.
I've benchmarked performance using Scimark2 in C++, Java and C#. This only tests scalar numeric performance, but it does tell me that in the given test cases Java now outperforms C++ on many of the tests, and equals it on all the others. C# however clocks in at a lowly 65-75% of the performance of C++. So in this case, C# doesn't perform very well (and the test cases are well written in all 3 languages).
Back on topic - the performance of a MMORPG server is all about architecture and nothing about raw language performance. If you have the skill set to design such a system, and the time, it could be implemented equally well in C++, C# or Java. But you have to understand how to build a system that scales well across 50 to 100 servers if you are going to emulate something like Everquest.
Jim Perry wrote:
Nick Darnell wrote:
One should never say never...but you do lose 15-20% performance moving to C/C++ to C#, possibly more depending on your code, and memory consumption is going to be a lot comparatively speaking. If you're seeing that kind of performance hit, your code is very poorly written. C# performance is maybe 1-2% slower in some situations. In some situations it's actually faster than C++.
Nick,
IThe 'middle man' you mention doesn't have to take something away from performance. In the case of Java, it allows highly optimistic compilation to take place, which can be dynamically recompiled to work in a less optimistic manner when the highly optimistic case would break the program. This simply isn't possible in C++.
For instance, a program might provide several integration methods for rigid body simulation - Euler, Runge-Kutta etc. Now ordinarily you would access these via a function pointer in C, or via polymorphic classes in C++. In either case, the code will never be inlined, as we don't know which the user will choose at runtime. The JVM is sneaky - it sees that only one of the classes is called during profiling, and inlines the code giving a huge speedup. Clearly this would break the program if the user changed to the other integrator at some point later on, so the runtime detects this and recompiles the code if it happens.
Now if you add up enough of these type of optimisations you can exceed the speed of the 'pre-compiled' C++ code. Of course you won't believe me, so I can only suggest you go and try it for yourself.
PS - In case I come across as a managed code evangelist/nutter(!), or something like that, I should point out I started out writing assembly language programs, and have been writing C for 18 years and C++ for 12 years. I take a lot of convincing about performance claims made by plaform vendors...
AndyL wrote:
Back on topic - the performance of a MMORPG server is all about architecture and nothing about raw language performance. If you have the skill set to design such a system, and the time, it could be implemented equally well in C++, C# or Java. But you have to understand how to build a system that scales well across 50 to 100 servers if you are going to emulate something like Everquest.
Agreed completely - just look at Second Life - they have their own interpreted language that is used for the server-side scripting of every object in the game world!
I'm interested in that kind of stuff, so I found this video particularly fun and recommend it to anyone else who may be looking at this area:
(note that the first half is all about Second Life, and the second half is all the technical details) - if the link doesn't work, find it on http://www.langnetsymposium.com/speakers.asp
Nick Darnell wrote:
Edit: Managed vs. Unmanaged (Not even outperformed, but even came close to the same performance.) I mean we can play Theory-Development all day long, but until I see some real world applications that match or come within that (1..2% slower claim) in terms of performance with an unmanaged version. I can't help but maintain my position.
Nick,
Good to see you have a healthy degree of scepticism as well! I can't show you the stuff I have, but it's physics engine code and runs just as fast in Java - this isn't the case in .NET by the way. I also suspect you overestimate the degree of optimisation of games and middleware code - those companes want you to believe they have perfect and amazingly fast code.
Like I said, you just have to see for yourself.
I am really not sure about using properties in a game, sure they are great for business apps where encapsulation could be important but for a game engine... im really unsure.
Infact I did a little test to see if setting a public field directly is faster than setting a private field through a public property. For 1000000000 iterations of getting and setting a property VS the same iterations for getting and setting a value of a public field.
it took approx 12ns for each iteration of the property and approx 3ns for each iteration of the field.
of course my test might be innacurate with only me judging it and the code I used may not be a legitimate test but they are the results I got.
So considering Axiom uses properties everywhere, this might be a problem when performance is a concern.
Here is the test code, someone tell me if I am going about it the wrong way :)
using System; using System.Collections.Generic; using System.Text; namespace PropertyVsFields { class Program { static void Main(string[] args) { PropertyVsField obj = new PropertyVsField(); int loopCount = 1000000000; long startTime, endTime; double nanoseconds; Console.WriteLine("Public Property"); startTime = DateTime.Now.Ticks * 100; for (int x = 0; x < loopCount; x++) { // put the code to be tested here // set obj.PublicProperty = x; // get x = obj.PublicProperty; } endTime = DateTime.Now.Ticks * 100; nanoseconds = ((double)(endTime - startTime)) / ((double)loopCount); Console.WriteLine(nanoseconds.ToString("F") + " ns per operation"); Console.WriteLine("Public Field"); startTime = DateTime.Now.Ticks * 100; for (int x = 0; x < loopCount; x++) { // put the code to be tested here // set obj.PublicField = x; // get x = obj.PublicField; } endTime = DateTime.Now.Ticks * 100; nanoseconds = ((double)(endTime - startTime)) / ((double)loopCount); Console.WriteLine(nanoseconds.ToString("F") + " ns per operation"); } } public class PropertyVsField { private int privateField; public int PublicProperty { get { return privateField; } set { privateField = value; } } public int PublicField; } }
Even though you can't show us source, if you've done accurate profiling, you could easily tell us exactly where your engine is slower and probably why if you disassemble those sections and look at the IL. Give us real data and not handwaving and excuses.
AndyL wrote:
Good to see you have a healthy degree of scepticism as well! I can't show you the stuff I have, but it's physics engine code and runs just as fast in Java - this isn't the case in .NET by the way. I also suspect you overestimate the degree of optimisation of games and middleware code - those companes want you to believe they have perfect and amazingly fast code.