Maybe this will light a fire under Unity to get a recent version of a C# compiler. No one has ever been able to point me to an official explanation for why theirs is so far behind.
That was my number one reason for moving to UE4; announcing Unity 5 with no Mono runtime update was the last straw. Current versions of Mono could probably do a serviceable job with simulation-heavy games, but not Unity's ancient one.
Bizarrely, they don't even have a C or C++ API. You can add native code libraries to your project in Unity Pro, but you always have to go through Mono to interact with the engine.
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!
Yes, I think those benchmarks are based on the Mono they use, which is indeed old. I would be very curious to see benchmarks compared to trunk Mono - should be interesting.
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++?
It's important to consider that C++ code, is not the same as C# to C++ code. The Facebook guys originally converted PHP to C++ code for speed, just like il2cpp, but eventually they wrote a JIT because it was faster AND they could keep the dynamic features like code generation and dynamic loading.
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.
> 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.
Good point about code compiled to C++ not being the same as idiomatic C++ code.
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.
C# has very defined behaviour that when "ported" to C++ is going to result in similar speed hits. Allocations are zero'd out. boxing/unboxing objects, array bounds checking.
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.
First and foremost, compiling to C++ means you then optimize it using a full C++ compiler like gcc or clang+LLVM. Not only are those compilers generally better than JITs, they can also do whole-program optimizations. JITs are getting that too (Dalvik=>ART, newer .NET runtimes), but the C and C++ compilers have a big head start.
(In theory a JIT can do all the things C++ compilers do, of course.)
Aside from performance, Mono must be ported to each target platform (I've heard this can take significant effort). On the other hand, well-written C++ code should just run (the rest of the engine is in C++ anyhow).
edit: yes, Unity compiles C# to C++, then to JS to run in the browser.
All true, but you're forgetting that Mono can AOT compile C# to native code using LLVM. That's how Xamarin.iOS works. So il2cpp doesn't really bring anything new to the table.
But it does solve their biggest issue - ultimately enabling Unity projects to publish to the web without plugins (WebGL / javascript).
Once all code in a Unity project eventually ends up as C++ (even if it started as C#), they can leverage Emscripten, asm.js and related technologies to enable Unity devs to use C# in the editor, which is converted to C++, and ultimately Javascript. It seems crazy, but it might just work!
Can't be understated - I've benchmarked my current MonoGame stuff with 2.10 and 3.10 and the modern stuff is leaps and bounds better in terms of GC performance (that alone being my biggest hurdle). Perf improvements have been coming very steadily and while there are areas I wouldn't recommend it for I wouldn't hesitate in recommending it for the logic level of many games.
But why? Why not directly compile it by implementing an LLVM frontend? And if you're going to transpile like this, I would assume translating to Java would be easier, since the languages are really similar. The JVM is, depending on task, as much as four times faster than Mono, and that's the official Mono, not Unity's stagnated one.
Mono is open source and free software. Because of the "single static binary" policy (no dynamic linking) of app stores you have to obtain a proprietary license from Xamarin.
• The C# compiler is dual-licensed under the MIT/X11 license and the GNU General Public License (GPL).
• The tools are released under the terms of the GNU General Public License (GPL).
• The runtime libraries are under the GNU Library GPL 2.0 (LGPL 2.0).
• The class libraries are released under the terms of the MIT X11 license.
and:
When do I need to obtain a license from Xamarin to the Mono Runtime?
We only require licensing for uses of Mono and Moonlight on embedded systems, or systems where you are unable to fulfill the obligations of the GNU LGPL.
>We only require licensing for uses of Mono and Moonlight on embedded systems, or systems where you are unable to fulfill the obligations of the GNU LGPL.
In other words, you have to pay a license fee for shipping the Mono runtime in a proprietary game, which is what Unity does.
So Unity has negotiated a license deal with Xamarin for the Mono runtime version they use, and if they want to use a newer version they will have to pay more, which they aren't doing.
Instead Unity has developed il2cpp which means that they no longer have to ship the mono runtime with each game and therefore no longer have to pay the license fee for shipping mono.
Unity has negotiated a license with Novell. Now they would have to do it again with Xamarin for the newer version of Mono. But we don't know if Unity was really nice to the Mono guys when Novell pushed out what would quickly become Xamarin.
As always, if it were only money things would be simpler. But if there is some beef things will drag.
Plus, Unity has forked Mono and they contribute to their own internal version. At the same time they are working hard on their own proprietary il2cpp (to export to C++).
The writing is clear: they will drag things as long as possible with using their old version of Mono until they are able to switch to il2cpp.
My personal opinion is that Xamarin guys are better at Mono and that UE4 coupled w. Mono/C# might put quite a bit of pressure on Unity.
>Unity has negotiated a license with Novell. Now they would have to do it again with Xamarin for the newer version of Mono.
Ah, so the deal was before Xamarin bought the rights to Mono from Attachmate/Novell, I didn't know that.
>At the same time they are working hard on their own proprietary il2cpp (to export to C++). The writing is clear: they will drag things as long as possible with using their old version of Mono until they are able to switch to il2cpp.
From what I understood they would still ship Mono as part of Unity (as in development framework), however what they want to avoid is the license costs that comes with shipping the Mono runtime with each Unity game, hence il2cpp, but perhaps I'm mistaken here ?
For them to invest serious resources into a Mono fork and also in a proprietary solution (il2cpp) shows that they do not believe in a deal for a license of their liking, whatever the reasons: interpersonal or purely monetary.
You can bundle LGPL libraries with proprietary applications quite easily; it just has to be possible for the user to replace it, which is rarely a problem because the usual situation is that your proprietary code sits "above" the LGPL library.
But reportedly Apple does not allow LGPL in its app store for some reason.
Well there are likely lots of potential markets where a prerequisite of allowing the end user to swap out LGPL libraries won't be accepted (sadly), not only Apple but the consoles as well, so from that perspective Unity needs to buy a license which allows them to forego the LGPL requirements.
It's not just mono they need, it's the IDE. The default IDE that comes with Unity is MonoDevelop. If they upgraded the runtime, they'd have to pay for Xamarin's IDE. I wonder if embedding the java runtime would have been cheaper in the long run.
Our IDE is free for anyone to use, whether you are using our iOS, Android or Mac products or not. It's also open source (except for the addins that work with our iOS, Android and Mac products).
There are a lot of Unity customers on our forums using Xamarin Studio already.
I suspect the issue is related to the licensing fee which might be on a per dev seat and hence might not fit unity 3d's business model.
Unless there is a hard stop issue, business wise, it won't happen.
