[Official] The collected il2cpp forum topic.

Let me clarify. Could one use your AOT technology to build standalone DLL's, and if so, can you foresee any benefits in doing so?

 

I'm not sure what you are asking, but currently for the standalones (we use them for development, they are not ship ready), il2cpp does this already, it builds a (native) dll of the user script code out of the cpp files that come out of il2cpp. But those are *native* .dll's and not the managed dll's you are probably referring too.

 

So I am just confused right now, what is IL2CPP? In comparison to the Visual C# compiler or the Mono C# compiler? And how will it affect us?

 

Feel free to correct me if I'm wrong, but I understand it to be this:
Rather than compiling your code to IL (as the MS/Mono compilers do), which then require the core .NET/mono framework on the target platform, the IL2CPP compiles your code to C++, and then straight to native - eliminating the need for the mono runtime to be bundled with your app.

How will it affect us? Certain things that required the Mono runtime to be present will no longer work - eg: reflection, dynamic code compilation. Initial reports from the Unity team suggest a significant performance boost, and will eliminate the issues that arise from being stuck with an old version of Mono (for example GC spikes).

It should also benefit us in the long run - Unity doesn't need to waste time/resources getting mono to work with new platforms and hopefully everyone will benefit from a unified code base across all platforms (Can anyone from UT confirm that my thinking here is correct?).

Initially this will only apply to WebGL and (later) iOS, with other platforms coming later - but it also means that other platforms can get a much-needed Mono upgrade in the mean time.

 

Yeah it means back then, when they need to add a new platform to Unity that doesn't have a Mono VM for it, they would have to port Mono to that platform.

Now, since your scripts are converted to C/C++ code (and any platform you're gonna see is going to support at least that), the C/C++ code simply needs to be compiled with the tools already available for that platform.

 

Most things in the Reflection namespace will work just fine. Things like Reflection.Emit ,which allows for dynamic IL generation, won't work. I assume it's because IL2CPP won't be around at runtime to convert the Generated IL into C++ and there won't be a C++ compiler present to compile to the target platform.

 

IL stands for 'intermediate language' it's a state that .net code goes through before being compiled into binary. Why? The idea was to let many different languages compile to IL (relatively easy process) and have one hardcore team write the IL to Binary Compiler (Hard). UT want to take this IL and write thier own binary compiler... but since they are lazy they realized if they turned IL into C++ they could get a C++ compiler to do the heavy lifting for them.

Basic Diagram:

 

Since they are smart.

Is the outputted IL the same regardless of outputted platform? I wonder if Unity could allow people to write their own build platforms. the issue I think would be things like Enlighten and Physx.

 

“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.” <Unknown>

IL should be identical regardless of platform, it's in the binary compilation that platform specific changes are made. Do note that with the existing workflow there are some platform specific changes made to the input of the IL compilers that will change output (e.g. in text we can set platform defines, use different language features, target different libraries etc).

 

I'm curious, will there be something similar to inline Statement and Expression blocks, similar to how the Flash translator allowed injecting raw AS3 code to the underlying compiler?

 

You guys are geniuses.

there is so much work involved in such project its almost unthinkable.

and for the demo you mentioned earlier, it does feels like another engine

its shows unity is evolving..

 

That's probably why he's unknown. If you choose a smart person to do a hard job, you end up with a better result. In this case, C++ compilers have a *massive* head start in terms of optimisations that would take Unity years to catch up on.

 

Haha, that "unknown" guy is in fact Bill Gates.

Why do you assume "lazy" to be mutually exclusive from "smart"? I used to always joke at people that "it's not lazy, it's efficient", and... well, this is the same kind of thing, right? I've seen "hard workers" repeat significant effort time and time again when very small effort looking into alternative solutions would have rendered most of the work moot. That's both "smart" and "lazy/efficient".

Here at work, if we decide we need to make a similar change to, say, every object in 3 scenes, there are people in the office who'll happily sit there and hand select and modify every one of hundreds of objects. Me? I'll spend 5 minutes writing a script to do it for me. That's the kind of thing I think that quote is talking about, in that my unwillingness to do batch jobs by hand at some point lead me to figure out how to automate them, and has allowed me to take a comparatively "lazy" solution (with better results!) ever since.

 

In addition to AngryPenguin's awesome comments...

Okay, now how do you pick a smart guy? No, not just your average hardworker or reasonably intelligent guy, I'm talking about the 'gifted and talented' the top 5% or top 1%, the 'genius'. Let's say in a classroom context (because, in my boredom, I've been sitting in education lectures).

Is he (or she) the kid who always hands in homework on time? Is he the kid who pays attention to the teacher, sits quietly and raises hands in an appropriate manner. Who consistently completed assignments and exams with A rating? The hardworking one?

Nope.

Often the smartest kid in the school is the kid who doesn't hand in assignments, distracts other kids, ask irrelevant questions, doesn't show working in their maths test (etc) and is often called 'lazy'.

Wait what? It's simple - following instructions and being a 'good student' involves a lot of hard work and being reasonably bright. Being bored and distracted because the subject matter is simplistic and you're not being intellectually stimulated requires very high intelligence (or perhaps, aptitude).

As such, teachers are taught not to look for the high performers, but look for the kids who aren't performing well, but actually understand the topic at hand.

So that's another angle on the issue. It's not just lazy people often try to figure out how to minimise work, but often the most gifted are mislabelled as lazy.

As a side note, is there any evidence that this is actually true?

 

That first bit almost perfectly describes my early gradeschool years. My mother had me reading Harry Potter at home, but in school we were still "learning" the letters. Had me absolutely bored crazy.

As far as C++ compilers, it's possible for them to achieve much better optimization because they don't have to perform any on-demand compilation unlike a JIT compiler - they can take their time, whereas a JIT compiler has to provide results as soon as possible.

 

A kind request to everyone to stay on topic. How academic achievement relates to being perceived lazy or smart is definitely *not* on topic.

 

And as nice as that is in theory, it's A) theory and B) irrelevant, we're replacing a AOT compiler with a AOT compiler.

 

Only in the case of iOS and other AOT platforms. Other platforms are JIT, so they stand to make *potential* performance gains.

 

They'd have to be a very convincing reason to replace the JIT platforms with AOT. My understanding is that we're talking about improving AOT platforms (and thereby allowing the entire platform to update to more modern mono). Lastly, we can already AOT compile for the JIT platforms... and the performance improvements are not worth mentioning - so yes, we're still talking AOT vs AOT.

 

No you can't. Also, don't assume that using a JIT compiler to do AOT gives similar results to our AOT approach, in which a C++ compiler is allowed to do whole program optimisations and things like auto vectorization, etc

 

I'm pretty sure I can.

Which is the claim made, it'll be interesting to see the actual impact made.

 

From http://www.mono-project.com/AOT

So no x86 here, and that's with the latest Mono version. And AFAIK, Mono version that is used by Unity now is only capable to do AOT compilation for iOS.

 

AMD64 is x86-64, so it does work for 64-bit x86.

 

IF the OS is 64 bit. I still use 32-bit version of Windows personally, so that won't work for me, and for a lot of people that don't need more than 4 GB of RAM.

 

And?

My point does not require you to be able to use 32bit (though, if you dug deep enough I'm sure you could).

My point is that there's a lot of claims about the supposed performance increases a C++ compiler will magically give you... but very little evidence to back it. That's not to say Unity won't get performance increases - I suspect they'll get substanital increases, especially on mobile - but what these increases are, and how much they are actually attributable to going down the C++ route is as of yet unknown.

 

I know 64 bit allows bigger address space but will 64 bit and new il2cpp speed back up all the slow downs in Unity 4.5?

 

Maybe a bit. Actually, 64-bit code is usually a bit faster than 32-bit code, up to 15-30% faster in some cases.

 

Any slowdowns in 4.5 are unintentional, and you should file a bug. It should work the same speed on all mobiles as 4.3, and same speed on all sm3.0 hardware before and after.

If it isn't, please file a bug.

 

It is hard to say from the post exactly why it maybe happening...

But in general there is some overhead when running 32-bit apps on Windows 64-bit bit that is caused by the WOW64 x86 emulator that is used to run 32-bit apps on Windows 64-bit

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384249(v=vs.85).aspx

so if you run 64-bit windows app vs 32=bit windows app on windows 64 the 64-bit version would more likely run faster because it would not need the WOW64 x86 emulator the the 32-bit version would

 

I was debating that and whether I need to upload the project or just describe my 'test'.

Do I need to upload anything? My 4.5 tests are just UMA Crowd Customization with Pro Option turned off Soft Shadows turned off.

 

bingo

i worked many years on operating systems and programming languages and there is a reason a deep rich history behind why things are the way they are

there is a reason and a history why c has all those need optimizations we all take for granted, but it was not always the case. also there is a reason and history why il languages like java and c# are the way they are to this day and why some of the optimizations that are done lets say in by c compilers are not done by just in time compilers. ok not all of them and perhaps as time passes as it did with c compilers those optimizations will make their way to just in time compilers, but it takes time and money and effort and between the generations something is lost, forgotten and rediscovered.

so enjoy nice thread.

 

It can be as small as you like - I know for sure Unity personally checks each bug report, but they must be able to reproduce it, so just mention your hardware specs in case - and provide a scene of any kind that runs faster in 4.3. If it runs slower in 4.5 it'll get treated as a regression.

and we can't really say that word without it Unity going to Defcon one, arming the nukes and generally barricading all doors. If it is the R word it should get fixed quickly tho.

 

interesting project which seems to be similar in concpet to il2cpp and it's opensource on github:

http://alexalbala.github.io/Alter-Native/

https://github.com/AlexAlbala/Alter-Native

 

I think this question hasn't been answered yet:

Will the new IL2CPP be incomptabile with Native Plugins? I'm almost certain it will be, but would like confirmation. There are some high-end tool developers that sell their add-ons as native, binary-only plugins. E.g., I think IKInemas upcoming support for Unity seems to be like that. Such add-ons will never work with the IL2CPP pipeline, right?

 

Hi i'm interested to know how is IL2CPP going to alleviate garbage collector pressure?
Does it do more stack allocations and/or reference counting if it can ensure there is no circular reference?

 

http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/

 

How is this relevant as long as we still got 2 year old exploits that still allow us to run native code on web players

 

I want to ask a question here as well: http://forum.unity3d.com/threads/is-il2cpp-going-to-solve-the-broken-aot-compiler.252599/

 

Hi Jonas, let me clarify my question: can you confirm that the new IL2CPP pipeline will be incompatible with native plugins that are available as binaries ONLY? You don't mean to say that the new pipeline can decompile object code that was generated by a C++ compiler, right?

 

Ah, now I get it, I was having trouble dissociating IL2CPP as a build pipeline from WebGL! So I guess then nothing changes w.r.t. native plugins, only those targets that exclude them anyway (WebGL) will continue to exclude them...

 

It seems my link went through unnoticed, so I'm pasting my question directly here.

Is IL2CPP going to solve the broken AOT compiler?

We're currently experiencing that the AOT support in current version of Mono is pretty abysymal.

For example, given this code:

Code (CSharp):

1. using com.tinylabproductions.TLPLib.Functional;
2. using Smooth.Pools;
3.  
4. namespace com.tinylabproductions.TLPLib.Iter {
5.   public interface ICtx {
6.     void release();
7.   }
8.  
9.   public static class Ctx {
10.     public static ICtx a<P1>(P1 p1) {
11.       return Ctx<P1, Unit, Unit>.pool.Borrow().set(p1, F.unit, F.unit);
12.     }
13.  
14.     public static ICtx a<P1, P2>(P1 p1, P2 p2) {
15.       return Ctx<P1, P2, Unit>.pool.Borrow().set(p1, p2, F.unit);
16.     }
17.  
18.     public static ICtx a<P1, P2, P3>(P1 p1, P2 p2, P3 p3) {
19.       return Ctx<P1, P2, P3>.pool.Borrow().set(p1, p2, p3);
20.     }
21.   }
22.  
23.   public class Ctx<P1, P2, P3> : ICtx {
24.     public static Pool<Ctx<P1, P2, P3>> pool = new Pool<Ctx<P1, P2, P3>>(
25.       () => new Ctx<P1, P2, P3>(),
26.       ctx => ctx.reset()
27.     );
28.  
29.     public P1 _1 { get; private set; }
30.     public P2 _2 { get; private set; }
31.     public P3 _3 { get; private set; }
32.  
33.     internal ICtx set(P1 p1, P2 p2, P3 p3) {
34.       _1 = p1;
35.       _2 = p2;
36.       _3 = p3;
37.       return this;
38.     }
39.  
40.     public void reset() {
41.       _1 = default(P1);
42.       _2 = default(P2);
43.       _3 = default(P3);
44.     }
45.  
46.     public void release() { pool.Release(this); }
47.   }
48. }
49.  

which should be pretty straight-forward to generate AOT for (and it works in trivial call stacks), we get this with real usage:

Code (csharp):

1.  
2. ExecutionEngineException: Attempting to JIT compile method 'com.tinylabproductions.TLPLib.Iter.Ctx:a<System.Collections.Generic.IList`1<string>, int, bool> (System.Collections.Generic.IList`1<string>,int,bool)' while running with --aot-only.
3.  
4.  
5.   at com.tinylabproductions.TLPLib.Iter.IterExts.iter[String] (IList`1 list, Boolean reverse) [0x00000] in <filename unknown>:0
6.  
7.   at com.tinylabproductions.TLPLib.Configuration.Config.getConcrete[JSONClass] (IList`1 parts, com.tinylabproductions.TLPLib.Configuration.Parser`1 parser) [0x00000] in <filename unknown>:0
8.  
9.   at com.tinylabproductions.TLPLib.Configuration.Config.fetchSubConfig (System.String key) [0x00000] in <filename unknown>:0
10.  
11.   at com.tinylabproductions.TLPLib.Configuration.Config.trySubConfig (System.String key) [0x00000] in <filename unknown>:0
12.  
13.   at com.tinylabproductions.TLPLib.Configuration.Config.getSubConfig (System.String key) [0x00000] in <filename unknown>:0
14.  
15.   at TLPConfig..ctor (com.tinylabproductions.TLPLib.Configuration.Config config) [0x00000] in <filename unknown>:0
16.  
17.   at TLPConfig.<apply>m__14A (com.tinylabproductions.TLPLib.Configuration.Config c) [0x00000] in <filename unknown>:0
18.  
19.   at com.tinylabproductions.TLPLib.Concurrent.FutureExts+<map>c__AnonStorey7B`2[com.tinylabproductions.TLPLib.Configuration.Config,TLPConfig].<>m__16E (com.tinylabproductions.TLPLib.Configuration.Config v) [0x00000] in <filename unknown>:0
20.  
21. UnityEngine.Debug:Internal_LogException(Exception, Object)
22.  
23. UnityEngine.Debug:LogException(Exception)
24.  
25. com.tinylabproductions.TLPLib.Logger.Log:error(Exception)
26.  
27. com.tinylabproductions.TLPLib.Functional.Option`1:each(Act`1)
28.  
29. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:tryComplete(Try`1)
30.  
31. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:complete(Try`1)
32.  
33. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:completeError(Exception)
34.  
35. com.tinylabproductions.TLPLib.Concurrent.<map>c__AnonStorey7B`2:<>m__16E(Config)
36.  
37. com.tinylabproductions.TLPLib.Functional.Try`1:voidFold(Act`1, Act`1)
38.  
39. com.tinylabproductions.TLPLib.Concurrent.<map>c__AnonStorey7B`2:<>m__16C(Try`1)
40.  
41. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:completed(Try`1)
42.  
43. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:tryComplete(Try`1)
44.  
45. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:complete(Try`1)
46.  
47. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:completeSuccess(Config)
48.  
49. com.tinylabproductions.TLPLib.Concurrent.<map>c__AnonStorey7B`2:<>m__16E(JSONClass)
50.  
51. com.tinylabproductions.TLPLib.Functional.Try`1:voidFold(Act`1, Act`1)
52.  
53. com.tinylabproductions.TLPLib.Concurrent.<map>c__AnonStorey7B`2:<>m__16C(Try`1)
54.  
55. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:completed(Try`1)
56.  
57. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:tryComplete(Try`1)
58.  
59. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:complete(Try`1)
60.  
61. com.tinylabproductions.TLPLib.Concurrent.FutureImpl`1:completeSuccess(JSONClass)
62.  
63. com.tinylabproductions.TLPLib.Configuration.<getConfiguration>c__Iterator1E:MoveNext()
64.  
65.  
66. (Filename:  Line: -1)
67.  

Practically it seems that AOT fails on it's head regarding everything but the most trivial cases. This makes coding on iOS VERY VERY hard unless you limit yourself to kind of unityscript with c# syntax.

With the advent of IL2CPP and new mono coming up, can we expect that this situation will improve? Or will it actually worsen (given the case that AOT failures will eventually apply to MORE platforms than it does now)?

 

I apologize if my question is slightly off topic, but what does ICtx mean? How about P1, P2, P3, _1, Smooth.Pools, TLPLib.Iter?? What?

I keep reading this code over and over and it keeps annoying me

 

At the end it doesn't matter. It is possible to write very simple code that uses generics here and there and the AOT will not be able to compile it, which means you end up getting runtime errors.

 

It's a part of TLPLib, our unity3d library that we use for our games.

Iter is allocation free linq like library that is a spinoff of smooth foundations.

At the end - it really doesn't matter. What matters is that you never can be sure whether your code will run, crash the aot compiler (we had that one) or fail at runtime.

This has been the main motivator for us of evaluating UE4 as an alternative, because if you can't use C# as C# across all platforms you might as well go and write c++.