XNA Framework

Re: Vector2 maths slow on 360

Bruno Evangelista — Sun, 06 Jul 2008 22:14:46 GMT

ShawMishrak:
The ref version of Matrix.Multiply comes in at 521 instructions. :)

That's really a lot of instructions for just a matrix multiply where everything is passed on the stack.

jwatte:
Although ideally in a new thread, as the poor guy at the top probably isn't being helped so much more in this thread :-)

So, can anyone create a new thread? =)

Re: Vector2 maths slow on 360

jwatte — Sun, 06 Jul 2008 21:54:04 GMT

Once you have some disassembly, you can diassemble a function that calls a delegate (and one that creates a delegate) to figure out the precise calling convention, rather than guessing. Unfortunately, blr can come in the middle of the function, too, for early returns and stuff. Some compilers also hoist things like switch tables to after the main return code. I suppose you can just keep fetching until you run into an address not valid exception :-)

Oh, and please do post more findings such as the Matrix.Multiply instruction count! Although ideally in a new thread, as the poor guy at the top probably isn't being helped so much more in this thread :-)

Re: Vector2 maths slow on 360

ShawMishrak — Sun, 06 Jul 2008 21:05:40 GMT

jwatte:
I would create a delegate for the function, and then cast the delegate to int*, and dump some first and second level indirections from that and see what comes out. I e, dump the first 8 words of the address of the delegate, then the first 8 words of each of those words treated as a pointer. Perhaps follow another level, too, just for good measure.

Good call, that worked. You just need three indirections from the delegate pointer on the stack to get the address of the first instruction of the target method. I still need to figure out the layout of the data structures in the intermediate indirections, but using the first word in each seems to do the trick for both static and instance methods. The real problem is determining code size. At the moment I just make a guess of the number of instructions in the function, and keep going until I hit a blr instruction. If 'blr' is guaranteed to be the last instruction in every method, then it may be possible to just dump until you see 0x4E800020 (the encoding for blr). This is turning out to be quite educational!

The ref version of Matrix.Multiply comes in at 521 instructions. :)

Re: Vector2 maths slow on 360

ajmiles — Sun, 06 Jul 2008 14:35:39 GMT

jwatte:

I bet you could use unsafe code to do a memory dump of the entire memory image of the executing .NET CLR, and somehow get it back to the PC. Probably through Console.WriteLine() (ugh!) and then take a disassembler to that to see what's going on. Would be very slow. Perhaps an alternative would be to see if Xbox/PC Live! were interoperable, and try to get data out that way, although I think that's not going to work.

I don't see what the problem is with just using the Network API... put them both in a System Link game and away you go... (at 39KB/s), no need to use Console.WriteLine() for that (or screenshots) any more.

Re: Vector2 maths slow on 360

jwatte — Sun, 06 Jul 2008 06:33:30 GMT

I would create a delegate for the function, and then cast the delegate to int*, and dump some first and second level indirections from that and see what comes out. I e, dump the first 8 words of the address of the delegate, then the first 8 words of each of those words treated as a pointer. Perhaps follow another level, too, just for good measure.

Then try to disassemble each of those dumps (assuming you get valid addresses at all) and see which one looks like good instructions :-)

To get the address of a delegate, create a local variable holding it, with some ints or something you can take the address of around it, and hope that it shows up in the middle on the stack. You can probably do this by just looking at the memory window in the debugger.

Re: Vector2 maths slow on 360

ShawMishrak — Sun, 06 Jul 2008 04:50:16 GMT

jwatte:
I bet you could use unsafe code to do a memory dump of the entire memory image of the executing .NET CLR, and somehow get it back to the PC. Probably through Console.WriteLine() (ugh!) and then take a disassembler to that to see what's going on. Would be very slow. Perhaps an alternative would be to see if Xbox/PC Live! were interoperable, and try to get data out that way, although I think that's not going to work.

I don't know why I have not thought of that before! Sure enough: unsafe code for stack inspection + Debug.WriteLine (in formatted hex) + Hex Workshop + IDA = "static void Main(string[ args)" disassembled. :)

It's a pain in the behind to figure out the actual function start addresses, but nothing a big memory dump and an IDA analysis can't solve.

If anyone knows how to get the address of a method in C#, please let me know. :)

Re: Vector2 maths slow on 360

jwatte — Sun, 06 Jul 2008 04:24:04 GMT

I only worked on the Mac and BeOS versions, and only back right before it was released, and a little bit after. I did not have much to do with the Windows version of the NetYarouze version or any other such version, honest! (And it certainly rocked compared to the then quite buggy Symantec C++ or the command-line-only MPW)

Re: Vector2 maths slow on 360

David Weller — Sun, 06 Jul 2008 03:37:23 GMT

Adam Miles:
You worked for the company responsible for CodeWarrior...! That IDE is the bane of my existance, it is so so poor. Long live Visual Studio.

I'm guessing he wasn't responsible for your pain. And if he was, he certainly didn't mean it :-)

Let's not beat up on the MVPs too much though -- those guys are the backbone of these forums (because the XNA Community Manager got all uppity and quit Microsoft because he put his family first :-)

Hopefully Shawn Hargreaves or somebody else on the framework team will offer some ideas on what to do. In the meantime, you might want to look/listen to Frank Savage's talk from last year on CLR optimizations.

Re: Vector2 maths slow on 360

ajmiles — Sun, 06 Jul 2008 01:44:18 GMT

You worked for the company responsible for CodeWarrior...! That IDE is the bane of my existance, it is so so poor. Long live Visual Studio.

Re: Vector2 maths slow on 360

jwatte — Sat, 05 Jul 2008 21:18:59 GMT

learning about PowerPC

Most I know I learned from reading the "PowerPC Architecture Compiler Writers Guide" and the "PowerPC System Architecture" documentation -- this was 10-15 years ago, though, when I worked on compilers and debuggers for PowerPC at a company called Metrowerks, and later worked on an OS for multi-CPU PowerPC systems called BeOS. The Xenon is somewhat different, as it's a later generation embedded chip, but it's surprisingly similar to the 40x series and the PowerPC 603 core in many of its basics (such as being in-order, etc).

I bet you could use unsafe code to do a memory dump of the entire memory image of the executing .NET CLR, and somehow get it back to the PC. Probably through Console.WriteLine() (ugh!) and then take a disassembler to that to see what's going on. Would be very slow. Perhaps an alternative would be to see if Xbox/PC Live! were interoperable, and try to get data out that way, although I think that's not going to work.

Re: Vector2 maths slow on 360

Bruno Evangelista — Sat, 05 Jul 2008 19:17:41 GMT

Hum, interesting point.

Anyway, I feel so clueless in this thread!At least I am learning a lot of things! =P

Re: Vector2 maths slow on 360

ShawMishrak — Sat, 05 Jul 2008 19:06:09 GMT

Something else to keep in mind about leaf functions is that it may be impossible to have them in user C# code. I have not looked at the Xbox CLR implementation so I cannot say for certain, but the Desktop CLR does some per-method call validation that compiles down to call instructions in the preamble of each method, even with JIT optimizations enabled. If the same occurs on the Xbox CLR, then user C# methods may never compile to leaf functions.

Re: Vector2 maths slow on 360

Bruno Evangelista — Sat, 05 Jul 2008 18:42:50 GMT

jwatte:
calling a leaf function (one that doesn't call other functions) is actually "free," through the magic of the link register and branch prediction (call and blr are always predicted taken, so no pipeline bubbles).

Jon, can you point out a good reference where I can find this kind of information?

Sometime ago I read these articles, which contains good knowledge about the Xeon architecture:
http://arstechnica.com/articles/paedia/cpu/xbox360-1.ars
http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars

Re: Vector2 maths slow on 360

ShawMishrak — Fri, 04 Jul 2008 19:53:14 GMT

This is just another time when PPC assembly dumps would prove very valuable, if for no other reason than to see exactly what the JIT'er is doing and how to massage your code to help it.

Re: Vector2 maths slow on 360

jwatte — Fri, 04 Jul 2008 18:35:14 GMT

Note that using macros only removes function call overhead, not the bad FP code generation.

Part of removing function call overhead is the removal of parameter passing, true, but on the PowerPC, calling a leaf function (one that doesn't call other functions) is actually "free," through the magic of the link register and branch prediction (call and blr are always predicted taken, so no pipeline bubbles). The reason I put "free" in quotes is, again, that I've heard that the PowerPC Compact CLR passes arguments on the stack rather than in registers, so there's still stack spill going on which isn't free.