3 ms·
I agree with your conclusion (suffering for lack of modern native code development) but disagree with your solution. C# still has the potential to be vastly su
by ldar15 15y ago
I agree with your conclusion (suffering for lack of modern native code development) but disagree with your solution.
C# still has the potential to be vastly superior to C++ for "native" development. The problem is that they spent the last 10 years working exclusively on neat features like LINQ instead of something that they promised back in 2002. I wish I had a link to the article, but back in 2002 I read an article from one of the C# leads stating that, unlike C++, the CLR would be able to do processor specific optimizations at code generation time. It also talked about inline functions, and that it didnt matter that C# didnt have an inline keyword because of course the JITter would do that automatically.
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).
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. Memory management, for example, could be class/struct specific giving those classes performance as good as any C++ custom memory management (e.g. pools), while allowing initial development to proceed rapidly.
Sadly, none of this came to pass. If anyone wanted to hire me to work at a games company it would be on the condition that the first thing I got to do was write a C# toolset that did exactly this. (Funnily enough, nobody has hired me, but the idea of scrabbling in the just-post-punch-card shit that is C++ is enough to discourage me from dropping the requirement).
- kenjackson 15y agoRoll 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.