Optimize Math functions
Currently the JITer doesn't do a good job with a lot of the .Net Framework, and the Math functions in particular.
Example: Math.Abs
The emitted assembly is pretty much the same for all types. It should optimize to take advantage of x86 instructions that have been around for more than a decade.
cdq
xor eax,edx
sub eax,edx
ret
War
shared this idea
5 comments
-
Anonymous
commented
a couple of examples where the core math services in Microsoft software stack could use some fresh muscles.
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2643778-support-int128-on-64-bit-platform -
![David Berg [msft]](http://www.gravatar.com/avatar/435e500d8269abb10ac8c417f1a1abae?size=40&default=http://cdn.uservoice.com/images/admin/icons/user_40.png)
David Berg [msft]
commented
FYI. There's a difference between the results your code returns and the Math.Abs function. Specifically ABS(int.MinValue) in your code returns int.MinValue (a negative number) while Math.Abs will throw an exception.
-
Anonymous
commented
Actually, .NET should get the Math functions to use the SSE2 or AVX equivelants.
-
Martin Costello
commented
From what I've seen in the .NET source (via Rotor), most of System.Math is implemented in native code from within the runtime, so I'm guessing it would never be JITed.
-
War
commented
The problem is that they are unwilling to write code the is specific to a specific type. They don't want to have to test and maintain several different versions of the same function. I was told this by a member of the .Net team.
The idea solution would be that the JITer is smart enough see the type, the operation, and emit the correct optimized assembly. Then all code would get faster, not just the .Net Framework.
