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)


Tomasz Juszczak

Lead Tools Programmer

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *