It is faster than the old Mono they ship.
Their Mono is at best Mono 2.10, about three years old, without any of our optimization work for three years, very notably, a lot of the LLVM support, or the new garbage collector.
That said, the il2cpp looks like a very promising an interesting project, so kudos for that!
My information may be out of date, but typically people tell me that Mono tends to not match Microsoft's .NET implementation in speed, and in turn, .NET tends to not match native C++ either. So I would still guess il2cpp can win here. Or are there benchmarks showing Mono matches .NET and/or native C++?
C# is ment to be a safe language, unlike C++ which has, among other things, the notion of undefined behaviour and manual memory management. This is what makes C# initially slower than C++. You might be able to compensate with a JIT, but safety still costs. Not to mention, the Unity guys will still probably have to implement their own GC and spend years on optimisations.
Also, several games are using dynamic loading for things like plugins and mods, as far as I know, il2cpp will force them to change how this is implemented.
From my standpoint. The cheapest option, and best option for everyone really, is to continue using (an up-to-date) Mono and instead allow for writing games in C++ as well.
Yes. It seems logical that there have been some licensing negotiations that we're not aware of, and maybe all this is part of ongoing negotiations too.
What's puzzling is that they're keeping il2cpp closed. Opening it would make sense and would show they mean serious business but keeping it closed makes me wonder if their risk will pay off or if it's just a bluff.
However, unlike PHP which is dynamic, C# is statically typed. It is a much more direct match for C++, and performance should be pretty good.
But with that said, I think your point still stands, as there are still things like bounds checks in C# which would need to remain when compiled to C++, while idiomatic C# might not have those checks.
I wonder though if those bounds checks couldn't be disabled in some cases. Sandboxing isn't a concern on the Unity WebGL port, for example, since the browser provides that, so il2cpp code doesn't need to be safe in that sense.
GC is going to be the big hit as you're still going to need to pay for that even in C++ land. I'm not really seeing what you'd get over just C# with a more modern JIT unless you start converting to non-safe C code and doing sneaky c stuff behind the scenes (and I'm sure absolutely nothing will go wrong*).
The webgl stuff is fine to not be bound (I'm assuming it's being converted to js anyway?) but anything running in the plugin better be.
Let's see if with the new RyuJIT and the AOT compiler sharing the Visual C++ compiler backend in the upcoming .NET, that still holds.
