AndyL

As my thread on 360 performance has somehow drifted way from my original theme, I'd like like to follow up on a comment made in that thread here:

 EmoSaru wrote:
Well, I think the BEST solution all around is to extend the API to provide optional use of intrinsics.  Just like with the standard devkit, let ME decide when I want to use intrinsics and vectorized code and when I don't. :)

I would not be opposed to offering separate types for intrisic versions of vectors/matrices/etc., so long as the appropriate conversion operators/functions are provided.  It seems like this gives you the best of all words, insofar as within tight loops the native instrinsic code should not be hard to produce, but you don't have to worry about the global LHS problem.

Some internal math libraries at my workplace provide, as an example, FPU and VPU versions of their types and functions.  For compatibility's sake, the Math namespace could be treated as the FPU namespace.  I would expect to be able to declare and convert between Math.Vector3 and Math.Vpu.Vector3.

I have to say my first reaction to this was one of thinking that this would be like regressing back to the way C++ works, and that really the JIT should take care of this. But after some pondering, I think it might well be the right way to proceed, as it would open up all of the functionality of the vector unit not only to straightforward vector maths, but also to more unusual stuff that might be packed as a structure of arrays (SoA), as opposed to an array of structures (AoS). (This kind of stuff should be familiar to you if you have programmed vector units before).

It would also allow all of us who are using our own Maths libraries to use this optimisation for things like dot products and vector/matrix products (you can transform a matrix using 4 dot products, which on the XBox will give around a 5x performance boost, or put another way will get it back to the perfomance you see on your desktop PC).

If the VMX methods were implemented as JITted intrinsic methods, they would be properly inlined, and combined with unsafe code blocks to remove array bounds checks (that does still happen on the 360, doesn't it ), we could get some really performant code for things like physics, video decoding, audio processing, and generally speeding up things like procedural geometry generation (perhaps by 5-10x).

Andy.



Re: XNA Framework VMX library on XBox 360

AndyL

I have also entered this into connect.



Re: XNA Framework VMX library on XBox 360

Walther Gropius

Sorry for hijacking your last thread mate : (




Re: XNA Framework VMX library on XBox 360

AndyL

Walther Gropius wrote:
Sorry for hijacking your last thread mate : (

No problem Walther . I guess you will be interested in VMX optimisations for the stuff you are doing, so go and vote for it!