Internals question
by Xavier "eXoDuS" Amado · in Torque X 2D · 12/12/2006 (9:35 am) · 16 replies
This is just curiosity. But what makes TorqueX?
I'm guessing it's TorqueLib code modified to use XNA API calls instead of the old platform code and wrapped on C# API calls for importing in a project. Am I close or way off?
Regards.
I'm guessing it's TorqueLib code modified to use XNA API calls instead of the old platform code and wrapped on C# API calls for importing in a project. Am I close or way off?
Regards.
About the author
#2
12/12/2006 (10:27 am)
So there's no code shared with the legacy Torque engines? Interesting...
#3
12/12/2006 (12:19 pm)
Some of the code was ported from C++ to C#, but yes, its all C# now.
#4
12/12/2006 (2:23 pm)
And TorqueX acts more like a library now right? You link TorqueX to your application, am I right?
#5
12/12/2006 (2:24 pm)
Yes. You use the TorqueX Framework (library) in your game project.
#6
Thanks for your answers guys.
12/12/2006 (3:04 pm)
Interesting, sorry for my ignorance, I'm still used to the Torque way, been around since the v12 days :)Thanks for your answers guys.
#7
12/12/2006 (3:05 pm)
Another question.. has any of you guys tried benchmarking the same game on TGB and TorqueX? Wonder what the impact of all the engine code being in C# is.
#8
12/12/2006 (3:16 pm)
I don't have any personal experience with it, but so far the results I've heard from others and hearsay seems very favorable for comparison. I'm sure someone will correct me if I'm wrong, but I believe that the Torque X team was very surprised at the (great) performance they got out of Marble Blast "X", which looks very much like Ultra. C# a great language and you might be surprised how performant it can be.
#9
I know the numbers must be good, that's why TorqueX and XNA are so great, but I'm just curious what the numbers say :)
Regards.
12/12/2006 (4:53 pm)
C# is a good language, but it's not the language that matters here but the virtual machine and the class libs :)I know the numbers must be good, that's why TorqueX and XNA are so great, but I'm just curious what the numbers say :)
Regards.
#10
12/12/2006 (6:03 pm)
Well one of the little know facts about C# is that while it is compiled to byte code by your compiler it is compiled to machine code before it is executed. I have done extensive benchmarking and you lose 20% performance max (normally less) for the C# code. HOWEVER C# so far can not take advantage of compiler based optimizations at all. So if you can heavily optimize your c++ or write it such that it takes advantage of things such as SSE3 you might find that in those cases C# performance falls behind
#11
12/13/2006 (9:54 am)
It also depends on the programmer. A damn good C# programmer can write a game that outperforms an average C++ programmer.
#12
I'm asuming both TGB and TX core has been built by damn good programmers, so that's discarded. I've worked myself on and with the Mono .NET class lib, and the performance was great, even better than Microsoft's .NET in some parts (specially XSLT and XML iirc).
12/13/2006 (10:15 am)
Yeah I'm not talking about the people factor here, just the platform :)I'm asuming both TGB and TX core has been built by damn good programmers, so that's discarded. I've worked myself on and with the Mono .NET class lib, and the performance was great, even better than Microsoft's .NET in some parts (specially XSLT and XML iirc).
#13
12/13/2006 (12:34 pm)
But the people factor is what is the most important. Sure, managed code traditionally can loose up to 20% over it's unmanaged grandma, but that doesn't mean you can't beat the crap out of the managed code to squeeze that drastically down to an acceptable level.
#14
As far as 2D games go, we're spending quite a bit in rendering in a lot of cases. This obviously wouldn't be sped up by using C++. A lot of games these days, in fact, are gpu bound, so slowing down 20% on the cpu side isn't a big deal.
One thing I've noticed about C#, though, is that it has some performance pitfalls. It does a poor job, as far as I can tell, of inlining even simple expressions when the length of a function gets too long (won't even inline simple properties sometimes). You also pay a heavy price for using interfaces if they need to get accessed over and over. E.g., our scene object is an interface and when querying for objects we were seeing a large slow down. Turned out we were spending about 20% of our time in one bad case accessing properties on the interface. I gather that this is because as an interface it has to turn this into a virtual function call (I do wish interfaces could have _some_ implementation details). When I added some trickery to make this inlined things sped up quite a bit.
On the plus side, I've been amazingly surprised at the low cost of memory churn. We've been downright paranoid about memory churn throughout this project. One example of this is object pooling. We wanted to make sure you could simply turn on object pooling for things like projectiles so that you don't get tons of memory churn. On the C++ side I've found this to be incredibly important, especially for servers which will be running 24/7. It was only late in the project that I felt prepared to do some actual testing (we needed enough infrastructure to be able to get real results).
The test I ran was to do different amounts of memory churn every frame. I broke the allocations up into a bunch of allocations which would each have different lifetimes (averaging around 5 seconds I think). The cost of allcoation was larger on the 360 so I'll focus there. Allocating 8 megs/sec cost around 5 ms. That's pretty tiny when you consider that we never churn near 8 megs/sec. In fact, 100k/sec is a large churn, and the .06 ms cost of that is inconsequential.
But average cost was never my worry. I worried about frames that would take a long time because of having to do a garbage collection. I especially worried about this on the 360 where we are stuck with the compact framework which has no generazational gc. Well, the long and short of it is that as long as you are under 1meg/sec even the variance and max frame time are affected only slightly. They are affected though, so it's still good to avoid churn, but the cost is pretty small compared to what you might think.
Hope that answers some of your questions.
12/18/2006 (11:34 am)
Xavier, I'd love to have numbers for you -- I love good graphs -- but I haven't done any direct comparisons. I do know, though, that C# is performing pretty well. The MBU demo had cube mapped marbles, poly level collision and 20K polys in the level and we were getting around 60 fps on a reasonably powerful pc. Unfortunately, the original MBU didn't have poly level collisions so no direct comparison.As far as 2D games go, we're spending quite a bit in rendering in a lot of cases. This obviously wouldn't be sped up by using C++. A lot of games these days, in fact, are gpu bound, so slowing down 20% on the cpu side isn't a big deal.
One thing I've noticed about C#, though, is that it has some performance pitfalls. It does a poor job, as far as I can tell, of inlining even simple expressions when the length of a function gets too long (won't even inline simple properties sometimes). You also pay a heavy price for using interfaces if they need to get accessed over and over. E.g., our scene object is an interface and when querying for objects we were seeing a large slow down. Turned out we were spending about 20% of our time in one bad case accessing properties on the interface. I gather that this is because as an interface it has to turn this into a virtual function call (I do wish interfaces could have _some_ implementation details). When I added some trickery to make this inlined things sped up quite a bit.
On the plus side, I've been amazingly surprised at the low cost of memory churn. We've been downright paranoid about memory churn throughout this project. One example of this is object pooling. We wanted to make sure you could simply turn on object pooling for things like projectiles so that you don't get tons of memory churn. On the C++ side I've found this to be incredibly important, especially for servers which will be running 24/7. It was only late in the project that I felt prepared to do some actual testing (we needed enough infrastructure to be able to get real results).
The test I ran was to do different amounts of memory churn every frame. I broke the allocations up into a bunch of allocations which would each have different lifetimes (averaging around 5 seconds I think). The cost of allcoation was larger on the 360 so I'll focus there. Allocating 8 megs/sec cost around 5 ms. That's pretty tiny when you consider that we never churn near 8 megs/sec. In fact, 100k/sec is a large churn, and the .06 ms cost of that is inconsequential.
But average cost was never my worry. I worried about frames that would take a long time because of having to do a garbage collection. I especially worried about this on the 360 where we are stuck with the compact framework which has no generazational gc. Well, the long and short of it is that as long as you are under 1meg/sec even the variance and max frame time are affected only slightly. They are affected though, so it's still good to avoid churn, but the cost is pretty small compared to what you might think.
Hope that answers some of your questions.
#15
12/18/2006 (12:02 pm)
Great to hear from you Clark and it's much appreciated. It's too bad you guys aren't a multi-billon dollar company as it would be cool to have you build an exact port of MBU and then run the C++ version side by side the C# version and benchmark the two.
#16
And btw, I love good graphs and numbers too =]
Regards,
Xavier.
12/18/2006 (2:18 pm)
@Clark: Thanks a lot for taking the time to write that up, it's really appreciated. Your explanation is very good, and it seems there has been lots of work regarding performance. The fact that MBU with polygon level detection ran at 60 fps is amazing, I've learnt myself that polygon detection is very expensive on the cpu. As you say I think that 1meg/sec of allocation is probably over the normal, so we should be fine with memory allocation. It's interesting that the cost of allocating memory was higher in the 360. Would be interesting to hear what you learn about that.And btw, I love good graphs and numbers too =]
Regards,
Xavier.
Torque Owner Pauliver