[Official] The collected il2cpp forum topic.

Thanks for the clarification.

 

How often does this happen for you guys? I've had it once (pretty sure I fixed it by adding an explicit command to an XML document somewhere?).

While it's less of a concern for me, it's still a bit of one. If nothing else it means we have to explicitly test for this stuff, which is time I'd rather spend elsewhere.

The good news is that it sounds like you guys have a pretty solid repro case.

 

It happens a lot more than I'd like to. I'm coming from Scala background and using functional programming techniques a lot to write shorter, bug free code.

While this works with jit platforms, with some minor annoyances, it totally flops on ios. Most of our structs are defined as classes on ios, because it's too much of a hassle to type hint every possible combination of types which aot does not calculate.

Check out http://github.com/tinylabproductions/tlplib and grep the code for "bug". You'll see a lot of places where perfectly valid c# code crashes mono compiler, runtime or fails on aot platforms. And that definately isn't seamless porting experience Unity touts in their webpage. :-(

I understand the legal and technical challenges behind it, but at the end of a day it's just wasted time spent searching for bugs in unity codebase, not my code.

And then you start wondering whether you are really more productive with C# than with proper C++.

 

This one was a ton of fun, in example...

https://github.com/tinylabproductio...Assets/Vendor/TLPLib/Functional/Tuple.cs#L130

It's not even aot related

 

Have you guys considered open sourcing il2cpp?

I am sure it has applications well beyond game development, and some compiler freaks (like myself) might pitch in a patch or two.

I have some math heavy scripts that will greatly benefit from this (procedural terrain generation), and will probably spend quite a bit of time making sure it runs as fast as it can

 

and

at 58:38


What are the chances of this feature surviving the beta?
And if it does survive, do you envisage any limitations?

We've always been limited to Mono/C# as far as 3rd party libraries, to build to the WebPlayer. So this is *game changing* for us, and I imagine a host of other non-game applications that require a 3d web front-end. It means we can drop in mature C++ geometry libraries to target the browser. It means we can stick with our current C#/Mono codebase, and ultimately, Unity.

 

Hi Guys

It is very interesting idea to convert IL to CPP. But may I ask some questions.

Will it support generic virtual methods and generic methods in interfaces?
example:
interface IHello<T>
{
void Print (T t);
}

interface Foo
{
IHello<U> Test<U> ();
}

Will it support static members with default initialization?
example:
private static int[] array = {0, 1, 2, 3};

Thank you.

 

there is already plenty open-sources in this area.

 

The goal is not to learn how compilers work, the goal is to make my unity code run faster. I don't care if there are other open source compilers, that does not help me in any way.

 

http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
http://blogs.msdn.com/b/dotnet/archive/2014/11/12/announcing-net-2015-preview-a-new-era-for-net.aspx
Just curious, is this somehow related to IL2CPP?

 

No, the two are totally unrelated.

 

Does IL2CPP support code being run at run time? There's a name for it but I can't remember but the way IronPython works? IIRC it doesn't run on IOS ATM.

 

I still could not understand, why AOT preventing Unity from updating mono? Is the current mono in Unity for iOS not AOT?

 

Mono AOT is currently used on iOS and the consoles. The newer, open source, version of mono AOT for the various targets is licensed with LGPL and is thus not an upgrade option.

IL2CPP replaces mono AOT where it was used before and then goes further, thus opening up for the option of upgrading mono as a whole.

 

Fully understood now. Best wishes for IL2CPP ^^

 

Will loading new classes in C# still be supported after IL2CPP?

I ask this because my game that I'm working on right now is supposed to teach users how to code in C# (in a fun way, hopefully ). The user writes some code, then the game compiles it using a modified version of gmcs and writes the executable to disk. Later, the game loads the code up in a secure sandbox and runs it. I know that its a really small corner case, but I wanted to know if it will be possible in IL2CPP.

Thanks,
Arka M.

 

Even if it doesn't, you could just run without IL2CPP (sounds like this is a desktop game?)

 

Thanks for the info and the ideas, I think I understand better now.

 

Hey Josh, how far along is IL2CPP in terms of working with Generics and Reflection? I ask because I've been working on getting my JSON .NET asset working with WebGL and so far it is a no-go. I can compile, however there are runtime exceptions. So far I've only been able to serialize and deserialize a basic type (Vector3). I'm using pre-compiler directives and using the exact same code that I use for iOS which works without issue.

And on that note, since my asset makes heavy use of reflection, would anyone there at Unity be interested in using my asset as a base for some IL2CPP / WebGL testing?

 

Also, I have another question just about IL2CPP: will we get to see the C++ code that IL2CPP generates?

 

Now that IL2CPP is going to be available to 4.x users for iOS builds is there any chance it will be available for PC builds in 4.x?

 

Is IL2CPP available for x86 on 5 Beta or is it a later feature and will it be available for all platforms?

 

I believe right now it's available for WebGL only... not sure if the iOS x64 support has made it in or not as I haven't tried it.

 

From some careful reply (don't remember who's) I understood that it will be mainly WebGL, iOS, consoles in 2015 and then maybe? 2016 desktop and others. I think it was low priority for desktops cause of mono upgrade and etc.

 

How are the "Script Call Optimization" options affected by IL2CPP?
http://docs.unity3d.com/Manual/iphone-iOS-Optimization.html
Will they remain as are or will they change?

 

So does this mean we can use the newest version of Mono now once the 64-bit iOS requirement is in place? Forgive me, having a hard time understanding all of this.

 

I think the idea is that after IL2CPP has been ported to all necessary platforms (iOS, consoles, etc) then supposedly Unity will be able to update Mono without having to pay incredibly high fees to Xamarin (which, from what I can tell, is what's been preventing a Mono upgrade?)

 

Ah, ok. So then are there no real performance/optimization gains with IL2CPP if it's still the same ol' mono?

 

There are, since with IL2CPP you're no longer using Mono, but C++ code. That's what IL2CPP means: IL to C++.

--Eric

 

That's my understanding. In fact, I don't think it even has to be Mono - I expect it'd be anything that outputs valid .NET-compatible IL.

 

Thanks for the responses. This all makes sense now.

Sorry if this has already been asked, but are there any benchmarks available regarding iOS IL2CPP vs current Mono? Particularly interested in GC.

 

So I'm assuming this means code like this won't work either:

Code (CSharp):

1. var lambda = Expression.Lambda<Func<object>>(body.Arguments[0]);
2. var resolveArgument = lambda.Compile();
3. var argumentValue = resolveArgument();

 

Most likely not. This is also why some linq is not aot friendly today. If it wont work for IOS today without aot errors it probably wont work in il2cpp

 

Cool, thanks for the response. Hopefully this won't be too limiting with other 3rd part libraries.

 

it seems that C# socket is not supported in IL2CPP in Unity 4.6.x? how to fix this problem?

 

I'm assuming you're talking about IOS and not webgl since you mentioned 4.6. Maybe file a bug report... Not sure why sockets wouldn't be supported, except for webgl where they won't.

 

Sorry for the n00bish question guys but it seems that mono already supports LLVM compilation which is basically the intermediate step for compiling C++ to asm.js.

If the purpose of IL2CPP is to provide HTML5 support, why not simply convert C# to LLVM and then to asm.js instead of going through C++...?

I understand that mono licensing is a pain in the ass for Unity, however, hiring and group of developers (50 - 100 K per dev and per year) to develop the home made IL2CPP also seems to be a pricey solution in my opinion...

This is also a very risky since there are few only chances the compilation results with IL2CPP will perform any better than Mono since those guys have been developing it for years already, and furthermore with the help of the .NET foundation it will keep growing stronger and more reliable...

So would it no be more preferable if Xamarin and Unity3D would try to find a agreement instead quarrelling ?

 

UT employees and moderators, I appreciate your posts here. I just now read all of your posts in this thread, and I feel for you, having to deal with all of the "sky is falling" posts, and the people who say "I think you should abandon C#" (I wonder why such people don't use another engine, and I think C# is one of the strongest points of Unity, but anyway.) Keep up the good fight

You say after IL2CPP, a mono upgrade is on the agenda. One thing I don't understand is how you plan to upgrade mono when Xamarin isn't providing a way to get around the LGPL license*? Can you use an up to date (LGPL?) mono runtime on desktops, and then IL2CPP on iOS/WebGL?

If so, perhaps I do understand. I have been compiling C# using Visual Studio and .NET (not mono) and bringing in the DLLs (which are just IL) for Unity to use... always seemed to work for me (notwithstanding my iOS AOT nightmares of tracing crashes and assert fails through the pseudo-JIT/AOT/IMT bowels of mono -- which forced me to give up on Unity for a while but I want to start using it again someday).

So now is it just a matter of making sure I can create DLLs that are AOT-ready for IL2CPP? Will I be able to provide IL2CPP with any .NET DLL (made for .NET 2.0 or some day 4.0/4.5 ), and it will tell me what non-AOT code needs to be stripped out? Or will I have to run it and wait for a crash at runtime when a non-AOT chunk of code is reached?

* Those jerks! Maybe I should stop adoring them so much as a Xamarin customer (making non-game apps) and bashing you guys for having an old mono. Are they holding out for a big payday or what?? Hoping some competitor of yours hops on the C# bandwagon and cuts a huge deal? I have been crusading against the LGPL everywhere I go, because it is a disaster for multi-platform game development -- I did convince one library author to switch to a more permissive license. (Score!)

 

One thing I have not seen asked or discussed is what does the roadmap looks like for having IL2CPP for Android?

That would be a massive benefit for me personally (sorry everyone else - I'm being selfish here!!! )

Currently I maintain native libraries for each platform we deploy to (for some maths heavy custom physics) and having the ability to have that built as part of the Unity tool chain would be a massive benefit.

Anyway my question is really just - what is planned for IL2CPP with regards to Android? Can we expect anything soon?

I'll add that this is excellent news Team Unity! Exactly what we need IMO and I've just tested one of our large projects with IL2CPP for iOS and it worked flawlessly on a large existing project - excellent work guys! Obviously this won't come as a surprise to most given that iOS was already AOT but still excellent progress!

 

UT has finally set my mind at ease regarding mono! It has been a while since I watched what was going on in Unity land, but IL2CPP sounds like an ideal approach. I realize now how bogged down you guys must have been with the platform specific problems, and I am glad things will be easier with C++ as a common intermediate compilation target.

(I will sure be happy when the day arrives with an up to date .NET 4.x+ support and bug free iOS AOT in Unity! Also looking forward to WebGL, and the new open source UI.)

Well, I had to give up on Unity's AOT on iOS when I tried to port an existing .NET codebase, so I don't really know what is supposed to work and what has been patched since I was using it (3.5.7. I know at least one AOT bug with generic interfaces was finally fixed a few months ago I think). When you mention Mono AOT, are you talking about Unity's older/forked Mono AOT, or Xamarin's current AOT?

There were 3 ways a dll could blow up on me at runtime with Unity when running in an AOT environment like iOS:

1) assert fails in the bowels of the mono runtime. g_assert, IMTs, more than I ever wanted to know about how mono works.
2) wacky behavior like setting IMyObject<MyType> obj = objInstanceThatIsNotAString, with obj.GetType() then telling me it is typeof(string). (Can't remember the exact repro that caused the glitch in the Matrix. "They've changed something.")
3) Runtime exception: "ExecutionEngineException: Attempting to JIT compile method". This is so much nicer than #1 and #2 that I almost want to give it a hug.

But nicer still is if the IL2CPP compiler can tell me at compile time whether it will even be possible for my code to throw an ExecutionEngineException, so that I don't have to worry about code coverage tests. (I'm assuming #1 and #2 are bugs that are specific to the mono implementation and I won't have to worry about them with Il2CPP.)

I wrote a tool that did some analysis of IL (using Cecil) to try to detect some cases of AOT-incompatible IL. (https://github.com/jaredthirsk/AOT-Compatlyzer - I see that some have starred and forked this on github -- cool, but I worry about the fate of these poor souls.) My tool also rewrote some IL to fix some of the issues, such as C# events which were implemented with Interlocked.CompareExchange<T>().

Anyway, if for some reason IL2CPP didn't detect non-AOT-able code at compile time (although I would think it should at least warn on most or all cases), it might be nice to have an official static analysis tool like this to tell us: "warning: your code might blow up at runtime because of generic virtual method X, or whatever."