3 ms·
I'm excited about new native interop api (function pointers, UnmanagedCallersOnlyAttribute, etc.). It removes "managed code tax" for calling into dynamically lo
by SparksAndQuarks 6y ago
I'm excited about new native interop api (function pointers, UnmanagedCallersOnlyAttribute, etc.). It removes "managed code tax" for calling into dynamically loaded OpenGL/Vulkan methods from c#.
I'm playing around with GLFW via PInvoke, which meant marshalling openGL function pointers into managed delegates. In net5.0 preview, I can simply cast IntPtr into a function pointer, and boy, a call to your average openGL method is literally an order of magnitude faster.
Similar optimizations might have been technically possible before, but it required some icky bytecode tinkering.
- mads_ravn 6y agoSounds really interesting. Do you have samples, benchmarks or other resources you can share?
- bob1029 6y agoThis sounds very interesting. I didn't realize there was that much of a difference using the new APIs. I have been playing around with interop against LibJpegTurbo Encode() and I am now curious if I've been leaving a ton of performance on the table.
- Const-me 6y ago> It removes "managed code tax" for calling into dynamically loaded OpenGL/Vulkan methods Interesting, never heard of that. Do you have a source? I haven’t noticed much overhead when I measured, take a look: https://github.com/Const-me/ComLightInterop#how-it-works https://github.com/Const-me/ComLightInterop#how-it-works That library compiles and runs with .NET Core 2.1. Update: also there https://docs.microsoft.com/en-us/cpp/dotnet/calling-native-functions-from-managed-code?view=vs-2019#performance-considerations https://docs.microsoft.com/en-us/cpp/dotnet/calling-native-f... they wrote “PInvoke has an overhead of between 10 and 30 x86 instructions per call” It roughly corresponds to my observation, and I find it fast enough for all practical applications, including GLES rendering on ARM Linux: https://github.com/Const-me/Vrmac/ https://github.com/Const-me/Vrmac/