Hi!
Welcome to the News Corner! Today is my first blog post, I hope you will like it, like all previous posts π Today I will talk about .NET integration in the current project and possible outcome of coreclr integration as main CLR in Flax.
Walking on spikes in the darkness. Mono CLR
Every project until this point used Mono, as the main host for C# code hosted in C++. Mono was created 2 years later after Microsoft created its framework .NET. As it was a miracle for all developers, that loved C# and wanted to use it with C++ performance. Being open source, created a whole new level of support for all platforms. But it also had some flaws. It was very buggy, performance was not great, and crashed a lot. I mean a LOT. And this project, as many others were started without documentation for hosting.
13 years later, we had miracle number two and three π Microsoft created CoreCLR and made it open source! Since now we have access to low-level C and C++ code that powered .NET from the beginning, with its performance and stability on all platforms to this date supported only by Mono. But not all gold what shines.
CoreCLR struggle
The CoreCLR was launched with a capability to run on almost every platform and made applications with ASP.NET cheap to deploy on Linux machines, but as one of the developers said on their github page:
So after initial research, and few good posts how to start my first hosted application, I have stumbled across few major issues with coreCLR:
- There is no way right now to call C# method fast from C++, from current coreCLR dll.
- There is no way right now to call C++ method fast from C#, as there is only one possibility with PInvoke.
- coreCLR compiles 60minutes on my i7 4790k and SSD, from scratch.
To show how slow this is with its current state, I have compared simple method, fired 50000000 times on C++, C# (.NET Core), C++ Hosted coreCLR, and C++ Hosted Mono to compare results. All that method does is adding 1 to input value and returns it.
Test results:
|
Managed Type |
Operation type |
Time in seconds |
Operation time |
Overhead time |
Invoke cost |
|
Core CLR |
C# -> C++ |
3.0591326s |
0.2116895s (JIT) |
0.6535993s |
2.1938438s |
|
Core CLR |
C++->C# |
2.1351920s |
0.1544130s |
– |
1.980779s |
|
Core CLR Custom |
C# -> C++ |
0.374816s |
0.2116895s (JIT) |
– |
0.163127s |
|
Core CLR Custom |
C++->C# |
0.221428s |
0.1544130s |
– |
0.067015s |
|
Mono Invoke |
C# -> C++ |
– |
– |
– |
– |
|
Mono Invoke |
C++ -> C# |
12.181169s |
0.2116895s (JIT) |
– |
11.9694795s |
|
Mono Thunk |
C# -> C++ |
0.5575844s |
0.1544130s |
– |
0.4031714s |
|
Mono Thunk |
C++ -> C# |
0.43943s |
0.2116895s (JIT) |
– |
0.2277405s |
Now I will shortly describe, what those magic number means π
To create full hosted applications we need to call to C# (C# -> C++) and from it (C++ -> C#).
Time in seconds is the total time from begin of the measure to the end.
Operation time is the total time that took when the code is called in a language that invocation was begun on.
Overhead time is a specific case since we have the operation of Marshaling that is not the method itself, but additional overhead that needs to be done in order to call have proper values on hosted platform.
Invoke cost is the time in seconds, of the only language to language execution. (Time in seconds – Operation time – Overhead time)
And you might be wondering, what is Core CLR Custom and why its performance is so good. Well, I had taken coreclr code from Github, and added method invocation of external C# dll, directly from the coreclr library π This is cheating a little bit since there is no way I can use this code in Flax (yet). But there is a possibility. For those who might want to do the same thing I send you to documentation π
Also, I would like to add, that performance on this might be even better in the future since I made it βJust Workβ. I would predict that it can be as fast, as calling C# method itself, or even faster!
The Future of Flax
Today I can say that coreclr is a great initiative, that Microsoft took, They still lack proper hosting. One can only dream that this will be added in future versions. For now, I had decided that I will pass implementation of coreclr and will move fully to work on Mono. There is big refactor coming to our internal Mono proxy, and will maybe in future support coreclr as the second (better) CLR.
For now, I will leave you with custom support editor draft pipeline π
(Click to zoom)
0 Comments