Does Silk.net have more perfomance than C++? #752
-
My question surrounds the perfomance area, if it is worthy to start creating things with Silk.net instead of C++ - Which has a lot of information, books and courses available online and signs of good and sometimes extraordinary perfomance. Is it worth to get to know the Silk.net environment? And is it actually a better choice than C++ when it comes to perfomance? Please give me some more information regarding the perfomance part in Silk.net compared to C++ |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
Silk.NET is slower than if you were to use the APIs C++, because it's basically impossible to achieve equal or better performance due to C#'s runtime: managed-to-native (and vice versa) transitions are expensive (at least compared to a native-to-native call), and is completely unavoidable. However, in some cases you may benefit from .NET's JIT and its profile guided optimization, where it's able to detect code paths that aren't used often, and recompile the method at runtime to prioritise those that are. But given C++ is a systems language (about as bare-metal as you can get), it is basically impossible to beat it with a managed language such as C#. However C# is much nicer to use than C++, so you should decide on how much you care. The overhead isn't significant enough to be a massive blocker whatsoever, and there have been many games using C# and Silk.NET that all run smooth as butter. So yes it is slower but not enough to actually matter. If that answers your question please click the "mark as answer" button. Thanks. |
Beta Was this translation helpful? Give feedback.
-
for additional info, it supports NativeAOT so you can avoid a lot of the overhead that comes with regular managed languages. And helps with the final size too, so a simple hello world program with opengl will no longer be tens of megabytes, it'll just be ~2MB. |
Beta Was this translation helpful? Give feedback.
Silk.NET is slower than if you were to use the APIs C++, because it's basically impossible to achieve equal or better performance due to C#'s runtime: managed-to-native (and vice versa) transitions are expensive (at least compared to a native-to-native call), and is completely unavoidable. However, in some cases you may benefit from .NET's JIT and its profile guided optimization, where it's able to detect code paths that aren't used often, and recompile the method at runtime to prioritise those that are.
But given C++ is a systems language (about as bare-metal as you can get), it is basically impossible to beat it with a managed language such as C#.
However C# is much nicer to use than C+…