[Official] The collected il2cpp forum topic.

Well, I believe that you guys have seen improvements compared to the existing Unity runtime; I don't necessarily believe that the improvements are just because you're going from IL -> C++ -> Native instead of IL -> Runtime. How is the performance of a C# function through your compiler vs a C# function compiled with MS's compiler and running in .NET 4.5? Or through the latest Mono? I'm concerned that you could get the same (or better) performance increase by just updating to a newer compiler and runtime rather than writing your own.

I guess that's fine; I was hoping that this announcement was going to finally be the announcement about the solution to the Mono problem, but I guess this isn't it. This doesn't really solve anything from your users' perspective as far as garbage collection, incompatibility, or being long overdue for a .NET upgrade. To me, it just seems to introduce even more instability and unknowns into garbage collection, incompatibility, and the potential of ever seeing a .NET upgrade.

I get this, but the solution I was hoping for was that you guys would leverage the decade's worth of work that Microsoft and Mono have put into .NET, not write your own from scratch.

 

I may be wrong, but it seems from this post:

that once iOS has il2cpp, then UT can update to the latest mono.

 

I'm not trying to agitate you but you do realize that what you'd hoped for is exactly what's happening right?

Environments requiring AOT is what's holding back the mono upgrade. This announcement is the first step in removing the dependency on Mono AOT. Once this solution is in place they are free to upgrade Mono.

Unless I misunderstand you that is exactly what you wished for.

 

Sorry for all the ranting. Let me try and clarify my thoughts. Here are the problems I've had as a Unity developer with Mono and the things I wanted to see:

1) I want a garbage collector that is fast and lets me do many small allocations often without worrying too much about it. The current MS and Mono GC's are good at this, mostly due to being generational and parallel.

2) I want to be able to stay current with .NET, and use the existing .NET 4.5 features, and ideally be able to keep up with new .NET releases at a decent pace.

3) I want to be able to use current and future third party .NET libraries and code without worrying about compatibility.


Those are the main things that the Mono problem was holding back for me, and the main things I was hoping to see solved. This blog post doesn't solve any of those, and to me just puts up a roadmap that will make it so that now there is another year or two of development work just getting this new .NET solution in line with what we have now before we even think about solving problem number 1, and it pretty much guarantees that problems 2 and 3 will never be solved due to dropping JIT.

 

How about you re-read this thread from the start and also check the blog again and the comments in there...

 

You're right, I did miss that. If that's indeed what they do then I would be ok with it. But they've talked about using il2cpp and AOT on all platforms, which is not what I want. If they limit it to iPhone and WebGL but let us use JIT and a normal runtime on Windows it would be great.

 

For anything serious it is much faster, always. I don't link benchmarks this time, makes no sense with you. Just see other posts of people porting their game to UE4, same code is 300%-1300% faster in C++ for them.

Yes it is a limitation. But it is faster without JIT (see previous point). And for certain people being able to drop a CPP-file as a resource makes Unity 1000 times better. And I don't know if you really read the blog post (or understood what it says). You do not lose your JIT if you don't want to. And this stunt of Unity even gives you/Unity the newest Mono for free down the road.

So I think this is a smart move to out-play Xamarin (if they implement it well and can solve the debugability problem).

---

I don't know if your love for JIT comes from missing knowledge (disclaimer: I coded for Java compilers and Java JIT compilers). The base intermediate language that is run by the baseline compiler before a JIT compilation is triggered is of poorest quality (from speed view). Just analyze .NET assembly intermediate code, you would cry. For hotspots the JIT compiler does optimize that, but the JIT must be fast still, it cannot do many things a standalone compiler would do. And certain language features prevent a lot of other optimizations you can do for C++. Of course a JIT can pull certain tricks that you cannot do with static compilation, but that does not change the fact about what each serious benchmark will tell you.

 

As for the benefits of an AOT feeding an existing C++ compiler performance wise, as long as we haven't posted benchmarks (and you are right, it's fair to compare to newer implementations of .NET runtimes too) it's hard for us to convince sceptics. As said, we will follow up with more blogpost that go more technically in depth on development and exactly these type of topics ("how can it be faster?").

What I can tell you is that over the benchmarks that we did do we see performance gains as a constant factor.

Of course, a math heavy benchmark alone doesn't prove this to be true for all code, but we did a few differing benchmarks over time and saw these performance increases constantly. And adding to that; we know that we can gain even more, because we do control the code-generating we can do unity specific optimisations. A funny one that is implemented today; fast paths for UnityEngine.Mathf. That's just one tiny example of course, but it is indicative of how we can speed up existing code with a very specific optimisation.

As my closing thought for you on this is; we are not the only ones going down this path of an AOT compiler linked to a "native compiler"; as you might know, Microsoft is going down a similar path with .NET Native.Equally, Mono is (in some cases) able to leverage optimisations in LLVM. Here's a take from Microsoft on it; http://blogs.msdn.com/b/dotnet/archive/2014/04/24/dotnetnative-performance.aspx

I think we outlined in the blog quite well that while we are still researching GC (which is a general statement, not one only applying to il2cpp, or just confined to the actual runtime, but also the pressure our api's potentially create), that's on a path forward and we realize the importance.

As for .NET upgrade compatibility, it has been explained in the post and in this thread, so I'm not sure what information you are looking for, but I'll be happy to provide what I know both on this and your questions/conceptions about our GC statement.

We are not writing everything from scratch, are working with Microsoft to ensure fidelity on this front and equally will remain to be heavily leveraging all the great work that went into Mono. We are however implementing an AOT compiler and runtime environment (which we call a VM in this case), that we believe, after a *lot* of research, is the right way forward to support a large number of platforms in Unity, while also upgrading platforms to the latest Mono.

 

The reason that is a problem is because it causes a huge feature gap (iOS would be stuck on the old class libraries and you'd end up with more incompatibility issues). Replacing Mono AOT with IL2CPP on IOS will allow them to update the class libraries (getting all the newer .NET features within the same limitations that exist today on IOS), AND on standalone, a newer version of Mono will be available.

So that solves issue #1 (non-AOT platforms will get a new version of Mono, with its newer GC - AOT platforms will get IL2CPP, which will also have a better GC), #2 (class libraries will be updated for both) and #3 (as long as the C# library supports Mono AOT, it should support IL2CPP's AOT... and on standalones dynamic code generation will still be available).

 

Would be nice to swap Mono sooner rather than later, but this comes from a desktop developer, not an IOS developer.

 

Thanks for responding to my ranting calmly; I know if I was you guys I would probably just tell me to shut up.

I have read about .NET Native but even MS says that it is a tradeoff; they are not just planning on replacing .NET entirely with .NET Native. As they say, it's a useful tool on mobile platforms where CPU and memory are constrained, and where devs are willing to accept limitations on features to eke out more performance. But on PC and consoles, we don't need the performance boost and I'd much rather retain JIT features and compatibility. I guess all I can ask is that you guys try to find a way to allow non-mobile platforms to use JIT and leverage the existing MS or Mono runtimes. I know it fractures the cross-platform compatibility a bit but IMHO it is worth it.

 

Man, read the blog post again. That is exactly what they are doing. You do not lose your JIT if you don't want.

 

@Makeshiftwings it's good that you've identified you've been ranting, I don't think overall we can allow a constant barrage from any member on these forums. We would like to keep the forums civil and logical - that is - don't let emotion get *too* involved. It's clear that with testing, Unity found this method to be beneficial at many things, presumably because what we're doing is comparing mono compiler, not the ms .net compiler. There's a pretty big gulf in optimisation here which the web doesn't pick up on.

So please - act with restraint, as this is far from your usual manner.

 

I'd just like to say, there's quite a few reasons native C++ code can end up faster than .NET/Mono code:

* No JIT compilation, it's all compiled already. JIT does have some amount of overhead. Once everything's been compiled it pretty much goes away, but you still have to go through that first compilation step for every section of code.
* Eliminating the script <--> engine boundary. There's overhead in going back and forth between C# and C++. But, since everything gets compiled down to C++, you can pretty much get rid of that boundary altogether.
* UT staff mentioned earlier in this thread that there could potentially be a lot of optimizing options here, for instance getting rid of array bounds checking and disabling runtime exception handling. Both of these could result in minor performance boosts.

So this announcement is really quite a big deal.

EDIT: Plus, for platforms where Mono is already supported out of the box, they did say IL2CPP would be entirely optional.

 

That actually puts most of my fears to rest... I just wish I didn't have to wait until IL2CPP was done before finally getting an update. It sounds like the Mono update is planned for Unity 6 or at best late in the Unity 5 lifecycle, which is potentially quite a ways off, and we'll probably be seeing .NET 5 by then.

I'LL RESTRAIN YOUR FACE! ...sorry, sorry. Ok, I think my ranting is done now. Carry on.

 

Sigh

 

@ Unity Engineers:

This seems like a great time to support other .net Languages like VB!

 

People use VB for game dev? ಠ_ಠ

 

Can Unity share some early performance? It would be cool to get a desktop test build of Angry Bots or something using il2cpp and one with mono, I loved the way Unity has demos of Web GL... but the performance wasn't the best their.

 

I am glad this has been made official but I am surprised Windows/Mac/Linux is most likely not supported at the first release. This is still good news and a great step in the right direction for Unity 5.

 

I don't know about VB for game dev, but I could definitely get behind official F# support.

 

What I would really like to hear from one of the Unity Engineers, or anyone really, is why C#?

All this work to convert C# code into C++, when we could just be writing C++, right now even. Being able to write C++ plugins is not the same as having the language integrated into the engine, and the editor, the way that c# is. I'm talking about extending from Monobehavior in C++ and dropping .H files on game objects.

I like C# and all, but another one of the developers in my office, who is a big native-code guy, not a Unity programmer. He really had to pose the question, why doesn't unity just let you put CPP or .H files on GameObjects? What benefit does C# really offer? It seems to be alot of runaround to provide C# for no reason other than to not alienate a user base and code base.

And you know when he told me this, it really did make me think. Why so much effort for C#? Is it really doing anything other than just offering backward compatibility at this point?

It initially seemed to me that Unity jumped on Mono VM because it offered the most ideal way to make a web player at the time, otherwise they would of had to write there own VM. And then that brought C# which was cool.

But now that whole initial reason is gone. We no longer need a VM for a web players. But everything is bound to C#. So now this big huge runaround is taking place to make a design decision work, for which if the design decision were to be made again with no prior constraints, then it wouldn't be done.

So you break compatibility with all prior projects. You break compatibility with all asset store assets. Basically would be an entirely new system. But you know, Apple has done that before. It's why OSX is so good now.

I think its better to do just do what the absolute most intelligent thing is to do, even if it s a bit more painful, difficult and a struggle. In a most ideal world and platform, does Unity being bound to C# rather than just straight CPP really offer anything that great anymore? Seems to me like it's becoming a big messy drag for no reason other than to keep incapable programmers, who probably weren't even doing that good on C#, from feeling more alienated.

 

You are right you can use the VB dlls, but that is because the .net DLLs are not language dependent as they have already been converted to IL. Its just not the same though as actually being able to script live with VB or other .Net languages. Mono already supports VB so it shouldn't be a huge leap, in fact I bet it would be more work just to update the docs than to actually support VB.

 

I really, really like C#. And I would really hate to have to use C++. C# is so much more productive for me to code in without all the hassle C++ provides.

I think being able to drop C++ files in your project and call them from C# scripts (without actually scripting with Unity's API using C++) is a great idea. And that's coming (or likely coming)? I believe I heard something along those lines in here.

That would make me happy. But I do like C# and .NET, and I think many other people do as well. It wouldn't be nice losing that great convenience.

 

No where did they say they will be changing their scripting engine... I think you may need to reread the blog post bro, don't fret.

 

I think makeshiftwings summarized what a lot of us were thinking when we first read the announcement, but we'll get over it I trust UTs judgement - I'm sure they've had plenty of internal discussions/experimentation around IL2CPP vs .NET Native etc.
It's a little strange to me, but now that Unity is no longer tied to a third party system we should see some great improvements. Looking forward to any benchmarks/in-depth posts you have to share

 

I think that was in response to someone else who said that they couldn't see what benefits C# had over replacing the scripting with straight C++
Which, frankly, I find a ridiculous notion. But maybe that's just me.

 

.NET Native is no option. It is windows only. You would have to adapt it to each supported platform. It would be 1000 times more work. With IL2CPP, you do this once and just use the the platforms C++ compiler (and implement the platform abstractions in the "pseudo VM").

 

Most games have a lot of non performance sensitive code it seems overkill to write in C++. You could implement another language (LUA or something) for it but they've already got C#.

A similar question to me is why continue supporting anything except C#. The other two languages are so much less productive it seems like the inevitable life cycle of a new Unity dev is to end up writing C# code even if they start somewhere else. Might as well make it easier on noobs and start them with C#. For "designer friendly" rather than a language marginally more friendly than C# some native visual coding tools would work better. Unless supporting the other languages is trivial in which case I guess its a great marketing blurb.

 

I think the issue is that with the position they're in now, it would be difficult to remove the other two options without upsetting massive amounts of people.
I personally am totally in favor of it as well - there's a lot of cases for it:

* Asset store package interoperability. It's nigh on impossible to get asset store packages working together when one is UnityScript and the other is C#
* Supporting said interoperability. On the flip side, there's also the asset makers - and it's frustrating to say the least to have to deal with the fact that many of your customers insist on you supporting languages which have absolutely no real benefit and require you to jump through hoops to ensure support.
* Maintenance. I'm sure UT engineers would appreciate not having to touch their UnityScript code ever again - opting instead to just let the Mono team deal with C#

But then again, think about how many UnityScript users you see on the forums. I'm sure they wouldn't be happy about it - they can and potentially should learn C#, but probably wouldn't be very happy about it at all.

 

Good point - still, I think they have weighed up any other options themselves. We just have to trust their judgement.

 

I can think of one thing we could do with... a tree-based discussion forum.

This thread has already reached the length where people are jumping in with brash and loud opinions without having read from the beginning, creating escalation of spam.

While it is annoying, it is also an inevitable consequence of the existing structure.

Would that it were a tree, then I could collapse the rotten branches.

An intelligent mechanism for organising information would pay dividends over time.

 

Agreed

 

The blog post mentions that the Editor will use the Mono runtime rather than IL2CPP. Could this instead be made optional once IL2CPP is ready for PC/Mac platforms? I see it as being pretty important for when we're optimising high-performance code areas, because the workflow for that is going to be super painful if we have to make a whole build just to clock some changes in the target runtime. (In some cases we'll need to do this anyway because the physical hardware is different or whatever, but it'd be nice not to have to where it can be avoided.)

 

I agree, it's trivial to hit shortcut to build and autoconnect the profiler - doesn't take any longer than pressing play if there's just the single scene in build settings. Benchmarking within the editor has always been a bit hit and miss with editor overhead, sporadic updating and so on... I mean you still could, but knowing the target build is likely to be faster probably reduces your need to worry about it further still.

Another reason to keep with JIT/Mono for editor is that it really helps with those fast coding iteration times. Unity's ruined me in the sense that I can be so creative as a programmer play-test-play. That's gone with AOT. Also I would really hate to have to reboot the editor each time I make an editor script.

If you've a game which requires going through menus to playtest a level, you're definitely doing it wrong.

 

I highly doubt it would be feasible. You know how the UE4 editor has to be restarted when you make changes to your C++ code?
It's because you can't really hot-reload C++. So if they added IL2CPP to the editor, you'd have to restart the editor every time you need to recompile your code.
So really, it wouldn't solve anything.

 

Absolutely.

To be clear, I'm not talking about profiling the whole scene or even using Unity's built in Profiler. The particular use case I had in mind when writing that was a recent one where an operation on a large data set was being optimised, which was implemented as a single loop called in a single function. Changes inside that seemed to have a similar effect whether run in Editor or in build, which I wouldn't expect to be the case if there's a different toolchain and runtime between the two.

 

Isn't it the same as hot-reloading any other DLL?

 

If it was that easy, don't you think Epic would have just chucked the game code into a DLL?

EDIT: Here's a pretty good answer to that provided on GameDev StackExchange:

 

I don't know. Hence the question.

 

UE4 can hot-reload C++ code. Not all code, it depends on what and how you do it (if I remember correctly you cannot change interfaces in header files). But just changing something in the implementation is no problem.

Edit: from UE4 about page:
Make updates to your gameplay code while the game is running using Unreal Engine 4's popular Hot Reload feature. This tool allows you to edit C++ code and see those changes reflected immediately in-game without ever pausing gameplay.