3 ms·

I took a look at the code and I was wondering about the implementation performance where there are a lot of if() statements in the low level functions. Like Vec

by djmips 7y ago

I took a look at the code and I was wondering about the implementation performance where there are a lot of if() statements in the low level functions. Like Vector4F DotProduct2D() has if (Sse41.IsSupported) else if (Sse3.IsSupported) else if (Sse.IsSupported) and finally a default implementation. This seems inefficient but I don't know if somehow the booleans are more like compile time flags and the extraneous code disappears in a puff of logic.

jdmichal 7y ago
Those might fall out during JIT compilation as constant expressions. Would be worth running it through ngen to see what happens. (I'd do it myself but I'm not at a PC at the moment.) EDIT: Just realized the Intrinsics namespace was added in Core 3.0 preview. I don't have the setup to test this myself right now. I did find an online compiler, but it looked like it optimized away everything in release mode.
- Faark 7y ago
  There was some discussion here on hn a few days ago [0] that linked to a blog post about those intrinsics [1]. Those should indeed be optimized away. The relevant section: > The IsSupported checks are treated as runtime constants by the JIT (when optimizations are enabled) and so you do not need to cross-compile to support multiple different ISAs, platforms, or architectures. Instead, you just write your code using if-statements and the unused code paths (any code path which is not executed, due to the condition for the branch being false or an earlier branch being taken instead) are dropped from the generated code (the native assembly code generated by the JIT at runtime). [0] https://news.ycombinator.com/item?id=20915430 https://news.ycombinator.com/item?id=20915430 [1] https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in-net-core/ https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...
gameswithgo 7y ago
branch predictor gonna work well on those at least, if the jit doesn’t make then go away entirwlyy
- nick_ 7y ago
  came to say this. +1
legulere 7y ago
The JIT optimizes them away: > The IsSupported checks are treated as runtime constants by the JIT (when optimizations are enabled) and so you do not need to cross-compile to support multiple different ISAs, platforms, or architectures. Instead, you just write your code using if-statements and the unused code paths (any code path which is not executed, due to the condition for the branch being false or an earlier branch being taken instead) are dropped from the generated code (the native assembly code generated by the JIT at runtime). https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in-net-core/ https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...
johnkellyoxford 7y ago
yep, the JIT fully removes those checks when native code gen occurs :)

by djmips 7y ago

jdmichal 7y ago

Those might fall out during JIT compilation as constant expressions. Would be worth running it through ngen to see what happens. (I'd do it myself but I'm not at a PC at the moment.) EDIT: Just realized the Intrinsics namespace was added in Core 3.0 preview. I don't have the setup to test this myself right now. I did find an online compiler, but it looked like it optimized away everything in release mode.

Faark 7y ago
There was some discussion here on hn a few days ago [0] that linked to a blog post about those intrinsics [1]. Those should indeed be optimized away. The relevant section: > The IsSupported checks are treated as runtime constants by the JIT (when optimizations are enabled) and so you do not need to cross-compile to support multiple different ISAs, platforms, or architectures. Instead, you just write your code using if-statements and the unused code paths (any code path which is not executed, due to the condition for the branch being false or an earlier branch being taken instead) are dropped from the generated code (the native assembly code generated by the JIT at runtime). [0] https://news.ycombinator.com/item?id=20915430 https://news.ycombinator.com/item?id=20915430 [1] https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in-net-core/ https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...

gameswithgo 7y ago

branch predictor gonna work well on those at least, if the jit doesn’t make then go away entirwlyy

nick_ 7y ago
came to say this. +1

legulere 7y ago

The JIT optimizes them away: > The IsSupported checks are treated as runtime constants by the JIT (when optimizations are enabled) and so you do not need to cross-compile to support multiple different ISAs, platforms, or architectures. Instead, you just write your code using if-statements and the unused code paths (any code path which is not executed, due to the condition for the branch being false or an earlier branch being taken instead) are dropped from the generated code (the native assembly code generated by the JIT at runtime). https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in-net-core/ https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...

johnkellyoxford 7y ago

yep, the JIT fully removes those checks when native code gen occurs :)