[azakai]

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.

[virtue3]

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.

[azakai]

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.

[Skinney]

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.

[pdaddyo]

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!

[cwyers]

"But it does solve their biggest issue - ultimately enabling Unity projects to publish to the web without plugins (WebGL / javascript)."

I'm not really sure that is their biggest issue; HTML5 publishing of Unity games seems mostly a novelty at this point.

[azakai]

It is still pretty new, yes, but it seems to work well (see for example https://hacks.mozilla.org/2014/10/unity-games-in-webgl-owlch... ), and it's been one of the most-asked for features by Unity users on their forums.

[Skinney]

Regarding the C# -> C++ -> JS thing, it really must alot easier to do a C# -> JS conversion...