3 ms·
Roll on 2011, and my lovely Matrix44.Multiply(Vector4[] foo) neither inlines the internal Matrix44.Multiply(Vector4 bar) nor does it SIMD any of it even if I in
by kenjackson 15y ago
Roll on 2011, and my lovely Matrix44.Multiply(Vector4[] foo) neither inlines the internal Matrix44.Multiply(Vector4 bar) nor does it SIMD any of it even if I inline it myself. Ditto for Matrix34.Multiply(ArrayOfStructs baz).
The CLR does inline, but it has restrictions that you're probably hitting. But it doesn't do processor specific opts. That does suck.
Then there are the kind of performance guided global optimizations that you could do with a language like C#, using data-driven compilers, or manual-driven attributes.
The CLR does have a profile based optimization system, but according to this article, it is internal-only. http://msdn.microsoft.com/en-us/magazine/dd569747.aspx http://msdn.microsoft.com/en-us/magazine/dd569747.aspx Oh well.
- ldar15 15y agoThe CLR does inline, but it has restrictions that you're probably hitting. It has restrictions that I am absolutely definitely hitting, and that I hit whenever I want to do something that would actually benefit from inlining. Inlining a property get on a windows form in response to a mouse click - not very fucking useful. Not inlining a matrix multiply of a few million verts = guaranteed downcode to native. Not inlining a single matrix mult? Now I have to determine if the call to native, and the associated compiler, linker bullshit, is worth the effort. Ok, for games its obvious that one has to just jump in and write native code. But its a shame because the C# and the CLR should be able to out-perform the C++. There are tons of applications where it could be much faster but isnt, and where there isnt a programming team ready to drop down to native. Its a shame Intel can't write their own JITter.