[Official] The collected il2cpp forum topic.

http://thenextweb.com/google/2013/0...lity-will-block-most-plugins-in-january-2014/

The other one could be Firefox. Additionally, all mobile browsers don't support unity webplayer.

 

Compiled native code has no meaningful variable or function names, or for that matter anything which resembles .NET code.
So yes, it will help a lot.

 

They've already explained that there's significant per-platform work for Mono. Maintaining two version of that will have a pretty hefty time penalty, which may push the benefits back such that it's actually slower for everyone. Plus, that kind of highly specialist work always comes with risk (they also mentioned that the people with appropriate expertise are quite hard to find), so taking on more of it will involve a hugely increased risk profile.

In other words, I totally do see the point of delaying the Mono upgrade until such a point where they're doing it for fewer platforms.

 

I think a lot of people would love to see Mono Develop customization brought out into a plugin so they can run the latest version of Mono Develop (which is like 20 versions ahead of what ships with Unity and will likely remain at this version for a long time).

There is already a plugin that gives 98% of the functionality, but it does not completely work exactly like the Mono Develop shipped with Unity. This is likely very short project (like a day tops) and would help minimize one of the biggest gripes Unity developers have.

Right now Unity uses a very old version of Mono Develop, even the recent major upgrade from like 2.8 to 4 is still 20 versions behind and according to the guys at Xamarin you guys don't submit any bug reports to them at all and fork old versions.

 

They have been avoiding the risk of upgrading to a new version of mono now for several years (while the number of supported platforms was increasing). Of course there is a per platform cost of doing it, but there is no way around it.
They already said that they will support a new mono version on the editor and windows standalone builds (the porting cost will be minimal for windows builds anyway because the platform is supported by mono natively)
And frankly I think it was a mistake to expand to so many different platforms before they had a solution for this problem.

 

At the time, that *was* the solution (writing a custom port of the Mono runtime). It probably made sense at the time.

The reason for IL2CPP now is AFAIK entirely because of WebGL, since it's required in order to compile with Empscripten (and then UT probably thought "hey wait a minute, now we've got this C++ code...")

 

Thanks for the link, that is perfect.

Actually yes I do. But not because they are idiot coders, because their priorities do not always line up with their customers. This should have and would have easily been done years ago. This should been a very high priority as you can tell spending five minutes in the forums Mono Develop is one of the biggest thing people complain about. Prior to 4.3, Unity was running like MD 2.8 I when 4.x was out. That's crazy.

This would make it easier for them, but also make it much better experience for end users.

 

There may indeed be no way around doing it for multiple platforms, but if "multiple" is for example 6 instead of the whopping 22 they currently have then I'd say that's a huge win.

And it might not even be six. In the best case perhaps it could be as low as two - IL2CPP for AOT platforms and a single Mono for everything else.

Also, for what it's worth, I don't think the approach has been a mistake. Certainly for me it's been more important to have increased platform reach than to have an updated scripting runtime.

 

I like what I am reading. Congrats on taking bold steps in this direction.

As a Unity user I don't really care how things work under the hood, and I assume that many Unity users out there don't either. As long as we are writing C# code, get native or near-native performance and have access to "current" platform features. Looks to me like il2cpp brings us a lot closer to this goal.

However, I wonder why il2cpp for standalone desktop build is not a higher priority? As far as I can see, Unity is following a "bottom-up" strategy of growth for maybe the last two years. They would like to grow bottom-up from the mobile/low-end indie scene to dare I say triple-A productions. Hence features like DirectX11, Mecanim, Unity5 rendering and next-gen console deployment. Whereas Epic would like to grow "top-down", i.e. from a firm grasp on the triple-A console market down into the mobile/indie space. Hence, the promotion of mobile development during the UDK phase and now the new pricing model for Unreal 4.

So, I would argue that il2cpp for desktop should be higher priority just for the performance gains alone - right?

 

This will shrink the community exponentially. I will be out of here one-two if that happens. Same with HAVING to use C# which is like talking backwards to my coding sensibilities and techniques I have developed over the last 15 years.

When is this sort of nonsense going to stop. It seems entirely selfish from those such magnanimous suggestion pipe in with. To counter your suggestion I say we go with US all the way to avoid having to write docs for all you already knowlegable C#/C++ heroes. You like that? Probably not. Same diff.

 

Typical..cater to your needs and trash the rest of the communities needs. Selfish. No longer code once and compile to many platforms. Just break it..what the hell aye..yer happy. I say make the whole API Unity js and get rid of all the selfish C# guys..Jeesh.

 

Wrong?

For a start, since when has there been code performance problems for desktop? I can't recall any threads on it, games delayed, alternative engines chosen because of this issue.

 

What are you talking about? Unity js wouldn't even be affected by this.

 

Was referring to fragmentation and threw the in ,js stuff as another metaphor constantly burbling around here that is irritating.

 

While you were having a rant and conflating numerous issues did you ever stop to think that there already is fragmentation? From a functional perspective the mono frameworks supported by desktop and mobile vary - especially if one employs build stripping (as is regular, to keep apps small). Moving JIT platforms to a more modern Mono version wouldn't harm AOT platforms, and would empower JIT platform developers to use technology, libraries and techniques that are currently unavailable.

Being multi-platform does not necessitate limiting functionality to the lowest common denominator.

 

What I care about is not all the under the hood stuff though I am in the business of knowing tech to be able to engineer the art projects I take on or add features to things that make the clients and my agent go wow.. I care that what I have written can be compiled to another platform without going through a bunch of scripting changes because I used something from one version of Mono that won't compile on that platform. An entirely reasonable stance IMHO. I script, I compile, it works. That is what drives my bank account. I already know good code practices for tight clean code and am creative and clever in setting up a codebase for performance based on the Unity API for even very complex interlocking subsystems. I read these technical threads to try to glean info from smart fellas like yerself and the Unity devs and used to as a child read mags like Scientific American or the university level Industrial Chemistry book I found from cover to cover even if I understood 10% of it. I eventually understood 90% of it and got all the jargon and the way things work under my thumb. I make my money with industrial design, oil painting commissions, giant sculpture installs like largest art install at the 96 Olympics and statues like this https://www.flickr.com/photos/cicidia/2439909372/, digital billboards up to 20x80, interactive kiosks and video walls. As with any of these I expect my tools to react in a certain way that I have taken the time to train myself with.

You are an advanced code guy who has all the jargon under your thumb and understand it's technical implications. When I use Unity I often have to slot the same codebase across multiple platforms, iDevices and the web. If I have to make a separate codebase for someones contract they don't care the extra hassle I have to go through. They contract me based on a good price and understand hardly anything except the final compiled output. They won't bite on Unity based stuff if the price has to be notched up because I have to spend extra time figuring what the heck needs repurposing because I compiled to another platform whose functionality is hobbled by the difference in Mono versions. From what I understand with all the jargon on this thread is that Unity is doing what it does...making their wonderful engine be a write once deploy anywhere experience. If it takes time to get that working I am fine with that. I don't ask Unity to do things that will hobble other users like just let me write in .js and ditch C# because I don't use it much for my stuff and frankly think it is rude and selfish were I to do so.

 

As I understand it, .net's foundation is like a bytecode stream that has very simple opcodes (sort of like assembler?) and all of the languages `compile` to it. For some of us, it would be quite interesting, and perhaps especially in terms of maximizing performance, to be able to write bytecode `code` in Unity as well... or inline snippets of it within other languages. I know the compilers etc can do lots of optimizing but sometimes there are optimizations that compilers simply can't do in competition with foreknowledge on the part of the developer to be able to cut corners and change algorithms etc to make something ultra efficient. We know better what can be chopped out or skipped or done in a way that is reuseable etc.It used to be that within C programs etc you could bring in some assembly language parts for code that you wanted to run extra efficiently. I'd like to see Unity get this same boost potential where we can write, optimize and include raw bytecode programs in with our other code. Or maybe I'm mistaken and it's already possible to do this somehow? Like with dll's or something?

 

It wouldn't work on AOT platforms, but there is Reflection.Emit.
On a side note, I don't see the point. The point of inline assembly is that you can do really weird platform-specific tricks like register wizardry or other things to speed up your game. On the one hand, you don't get this in .NET IL bytecode. On the other hand, with IL2CPP it's just getting translated to raw C++ anyway.
So really, there's no point to it. Compilers these days are already really good at what they do. If something is slow in your game code, it's surely not because of inefficient IL output.

 

I don't know why you would want to do that though. And doesn't Unity make it CIL at build time and then at runtime Mono turns that into assembly, but AFAIK the CIL is the same every time then somehow JIT can change that around when it compiles meaning you might not get the desired results from an optimization.

 

Good. We are not asking for that to change - trust me as someone who is an 'advanced code guy who has all the jargon under [his] thumb and understand it's technical implications.'

 

Lol, yeah like foreach loop.

Why do you say that?

@imaginaryhuman: +1. I'm with you, writing in IL for Unity would be awesome! Just can't figure out how to do it in MonoDevelop...

 

After having read through most of the posts, I think I can summarise it so no one has to read 12 pages to catch up.

There are basically 3 or so schools of opinions:

1.) Optimists:
This is an awesome Idea, We think Unity should totally go for it!

Some of us also want to have it in the editor! Why is that not going to be possible?
Unity: Because it's gonna be slow to do a three step compile (C#->IL->C++->Native Binaries) each time you hit play which will be bad for quick Iterations which we currently enjoy with the editor today. Oh and by the way you won't get it on the web player either! It's not really worth it for a target that will eventually get killed by two top browsers once they stop supporting plugins.

Some of us also want it released on some platforms first and are wondering why IOS has to go first after Web? Why not Android or PC/Mac.
Unity: Well we think IOS will be kinda easy because it's already an AOT target.The rest run IL on the mono VM, so a few challenges there. but we will release for those platforms as soon as we can. this post was not to tell you when we will but rather to give you a glimpse of the future (near and distant). Mean while, all the platforms will be getting a brand new mono runtime sometime soon so that's sort of a consolation for you Yey!

The rest of us think IL2CPP is awesome tech and will have many uses beyond games (you should know where this is heading by now)! It's like .Net native, but for all platforms! Why not you Open Source it? Besides you'll get massive inputs from the open source community which might mean quicker iterations per platform. Do it! Do it! Do it!
Unity: Well we kinda considered this, but we feel in the end we stand to lose more than we'll gain if it's open sourced. So we'll just keep it to ourselves for now but hey we're still thinking, maybe sometime in the future we might. You never know.

Pessimists:
Errrm guys, We think you should just leave things the way they are. We're fine with Unity as is. You risk introducing new bugs in a new runtime. There will be quite a bit of fragmentation. Just leverage of the time tested work of Mono and continue to run against their VM. You guys may never be able to build a run time that's as good as Mono let alone better.
Unity: Errm, yeah, we admit there will be a bit of friction with this change, but we believe in the long run to will benefit both us and the community. For us, We'll maintain a simpler codebase which consists of a small runtime package (Which we kinda call a VM but is not a VM in the same sense as the mono VM) and our transpiler IL2CPP. We'll the leverage on the existing C++ compilers for each platform to port and optimise for each platform. We're also free of Mono runtime licensing setbacks with Xamarin. For you, this means for performant code per platform (early tests have shown considerable improvement in performance). Waiting for the 5 years to support the latest and bets versions of .Net will be a thing of the past because we'll not have to create new runtimes for each platform. awesome right?

Ok sure, that's all well and good! but you're gonna break existing code because AOT code does not support very fancy refection (AKA: Reflection.Emit). Some of us do that kinda stuff in our code you know?
Unity: Yeah, we know we're gonna break that! But it is a small sacrifice to make for what we stand to gain with native-like performance, direct linking of C++ libs (and maybe even source) instead of expensive marshalling with existing code. There are ways around using Reflection.Emit, which are less performant, but you won't have to worry too much about that now because you are as close to the metal as you can get with native binaries ;-D

You and the optimists keep going on about how this is more performant because now C++ makes everything magically faster. This is not necessarily true! People just need to know how to write efficient code and stop going on about the awesomeness of native speeds. Today's VM's have near native performance and in some few cases can outperform native counterparts!
Unity: We're not claiming to be believers in Magic. Real tests with number crunching algorithms and saw 2 to 3X improvement in performance. So Yeah! We might also allow for some fancy native-like foot shooting by stripping out exception handling code, bounds checking and some other safety features which will make for some more performance gains.

Ok fine, But you guys are gonna make things complicated! Errors are gonna show up on one platform that won't show up on others!
Unity: Right! Yeah! That already with Mono, sooo nothing new there. That said we're, building this awesome c# debugger that should help we things in this regard.

Opportunists:
Yeah, that's all cool ! But , guy, guys, guys, listen B-) Why go through all this pain to build this IL2CPP thing for your shinny new awesome runtime hu? I mean come on? Why not just add C++ support or better still get rid of the whole darn .NOT and Nono dependencies ? We're ok messing with pointers and bad ass C++ programmers. And by the way, don't forget that there are lots of libraries out there which are built in C++ we want to be able to use those. And if you can't code in C++, just learn it! No one ever said Game Dev was a walk in the parc# :-D
Unity: Well we still consider the productivity of C# a valuable asset to most of our users. What we're trying to do here is to give the users the productivity and predicability of a managed environment language, and the performance of native code! Bam! Best of both worlds. That said, if you're hell bent on writing some C/C++ code because you want the Mallet...er...erhn... sorry...Malloc to be left in your hands we allow your to drop your DLLs and call them from your C# code. Hell, We might even make it possible to drop C++ source files in your assets bin and call them from your code. But absolutely no extending MonoBehaviors in C++ we're sorry.


hweeew. Ok there! that's 12 pages summarised!

 

Or the alternative perspective is that we're not happy with the way things are, but that doesn't mean there's a lot of trust or faith in UT's ability to deliver right.

There's a perception out there that this is largely an effort to avoid paying license fees to mono... by a company that's got an issue about half a decade old, and has failed to implementation simple functionality like GUI. Furthermore the same company is very happy to brag about the millions of dollars it's spending on other, less essential middleware.

Where has this been addressed in depth? I may have missed it.

It would be wise to take any claim of 'faster performance' for non AOT platforms with a decent kilo or so of salt. AOT compilation isn't new, has been done more than once before by competent teams and hasn't resulted in noticeable performance increases for general use-cases.

The concept of 'speed' increase is often by people thinking C++ or native code is inherently faster than C#... what they fail to recognise is it is all assembly at the end. Furthermore the removal of JIT functionality has a range of implications - many of which are loss of functionality. In the few cases I have seen Reflection.Emit done for speed, the improvements made are unlikely to be possible with il2cpp due to the nature of the improvement.

 

Will asm.js support multi-threading in the future, as it doesn't appear to have it now?

 

Have to say, I'm pretty excited about this!

I see the appeal from an engineering standpoint, it should make it easier to support new platforms as well as maintain the current ones.
You keep Mono for the Editor, so we avoid the long compile times (I assume, from my memories of your Flash translator) of the IL2CPP pipeline.

I'm going to assume C++ files dropped in the Asset folder will no longer go through the marshaling costs of going through the C#/Mono boundary and we'll be able to link C# and C++ code willy-nilly, subject to us having to manage the memory for our own cross-language objects.

From my experience with the old Flash plugin, when you do allow dropped C++ files, please do make sure we still have a way to provide alternate C# paths if those files are not compiled so we can still test in-editor, maybe a #define UNITY_IL2CPP when it's actually going to run?

@koblavi
The only way this is going open source is if Unity's competitor(s) develop their own equivalent, as this is a very interesting competitive advantage.

I like it, hope you get to roll it out soon!

 

Reflection.Emit dynamically generates code. Therefore, doesn't work in AOT platforms like iOS.

What on earth would compel you to do so....?

 

To Xamarin, yes. That and being able to have a WebGL target.

Which should give you a good idea of what Xamarin's price was, since they were unable to reach an agreement with them.

--Eric

 

Why are you brining Reflection.Emit into the discussion? You make it sound like tweaking the IL automatically calls Reflection.Emit??

Oh, several reasons. To help solidify my understanding of the 3 unity languages. And, as I said earlier, foreach produces horrible IL.

 

Yeah, none of us pessimists have been saying that. Everyone wants a Mono upgrade. The pessimistic view is that pushing back the Mono upgrade until after Unity develops il2cpp might be pushing it back until forever. Like npsf says, one of the main points of il2cpp is that Unity thinks the years of development cost to figuring it out will be cheaper in the long run than paying Xamarin for a license upgrade; the pessimists just wish Unity had stopped playing chicken and just agreed to pay Xamarin for the license upgrade years ago. If Unity fails to get il2cpp working and end up giving up and just paying for a license upgrade, then that will just be another 2-4 years wasted for nothing.

Also, as they said, the performance gains are showing Unity's current (broken) Mono vs il2cpp. I would suspect that if they ran tests of the new Mono or MS .NET vs il2cpp, they wouldn't see the same performance gains. If they could get the same (or better) performance by just paying the license upgrade fee to Xamarin, it's not particularly exciting.

 

That is a bug in Unity's current Mono compiler. If you compile in Visual Studio first and then copy the DLL into Unity, it fixes it. Or if you use a newer Mono compiler.

 

Earlier, I mentioned Reflection.Emit for producing straight IL code, and that it wouldn't work on iOS and other AOT platforms.
That was what you quoted.

 

The Pessimist response
Well personally I think most people opening the hole where they put food in should just close it until they see the end result. Unity is doing an upgrade, and people bitch about that? no wonder they're not real game developers or anything. If they put 0.1% of this energy into into actually making and finishing a great game maybe I'd bother reading their unimportant drivel.

The Optimistic response
Hey maybe it's good to question Unity all the time. Perhaps it makes for more dialogue and I feel like I have a voice! I don't need to finish any games but I'm really happy just trolling the forum all the time.

The Opportunistic response
I wonder how I can leverage the entire universe for my own gain...hmmm....



(Joking aside, do you not think it's slightly absurd harassing Unity over actually improving things?)

 

So the il2cpp code could not be wrapped to work with Googles native client tech then?

 

oh.... You mean use Microsoft .NET instead of Mono? How?!

 

I personally would be willing to pay more to get an updated Mono now, especially if the alternative is waiting for a few years. I don't know the details of the Xamarin-Unity standoff... I always imagined it as both of you throwing hordes of lawyers into a an underground fighting cage filled with hundred dollar bills and waiting to see who would come out alive. So I worry that the cost of that pit fighting cage, plus the tigers that you might have to throw in there, plus the cost of developing a Mono alternative for several years might add up to more than buying the license would have been. Oh well.

I should say I AM glad that there is at least a solid decision now to shut down the pit fight and declare that you're going to move on without paying the license. It gives some clarity and shows there is a plan going forward other than just more lawyer-wrangling. Now it just has to actually work.

 

That's nice and all, but outdated Mono has been a problem for years.

 

You can't actually run through Microsoft .NET, but you can compile with the Microsoft compiler instead of the Unity one, and then run the generated DLL through Mono. The normal Unity workflow is:

C# files -> Unity Mono compiler -> IL -> Unity Mono Runtime

You can't change the runtime, but you can do:

C# files -> Microsoft compiler -> IL -> Unity Mono Runtime

You just compile all your C# files as a Class Library project in Visual Studio, and then copy the DLL into one of your Assets folders in Unity.

 

I understand. Thank you for the reply.

 

So il2cpp is made by Unity yeah?

 

That's my understanding. Unity makes the IL2CPP and then uses a third-party C++ compiler to compile that into an executable.

 

What are the possibilities regarding the interaction between AOT and JIT code?

The ability to interact an assembly that runs as a semi-contained entity (e.g. own, specialized garbage collector) could be interesting.

 

That would also mean shipping 2 runtimes in one binary; and this is not something we are going to do.

 

So, when I build a Unity project it is only my scripts that are anything to do with Mono. then things like Nvidia Physx and Enlighten would be C++ all the time (they were never CIL) yeah?