[Official] The collected il2cpp forum topic.

Do I read that right, that the first platform will be WebGL, the second iOS? Do I miss "PC, Mac Standalone" or is that intended for a future release?

 

Thanks for a great blog post there. IL2CPP sounds very exciting but, I'm with Carpe Denius here, I'm a little worried that 'PC, Mac, Linux' standalone doesn't seem to get a huge amount of attention.

 

I'd assume that's because IOS is already AOT.

 

Seriously?!? I mean... seriously?!?

 

Can you specify that question?

 

Do consoles already run on a different base or are they Mono? Probs will be a big wait if all the consoles need to be ported before the normal platforms.

 

- VM machines for every platform which means binding people on those VM for several months
- Reimplementing the entire CLI background (not the entire toolchain... at least, they didn't do that...)
- Going from JIT to AOT (AOT is platform dependent, so you ideally need a compiler and SDK for that platform)
- WebGL as first platform (WHO is going to use that if you have to pay this... or are you going to drop the webplayer?)
- Going from C#/UnityScript/Boo(?) to IL to CPP to machine code adds an additional layer of possible "S*** that can go wrong"
- Still in research...
- ... and thus could be not viable on specific platforms... which means that the difference between the platforms can and will be increased as we cannot be sure anymore that the code on one platform runs smooth on another one.

Knowing Unity and their history of long turn around times, we can expect the scripting features go downhill for a while before climbing back up the hill again... has been like that with any other feature Unity has provided up to now... will not change in the future (unless you prove me wrong)...

 

il2cpp sounds very exciting!

I'm using Unity views as a part in a bigger, native iOS/Android app quite often. The communication is from CPP to C# is via MonoBindings.

In a future with IL2CPP, will it be possible to hook up custom C++ code? In other words, will we have access to the unity generated code BEFORE final compilation? Or is the only way to do so by loading runtime libraries?

thanks!

 

Thanks a lot for sharing that information! This is really appreciated!

 

I forgot about that. So stuff like reflection won't work anymore with IL2CPP?

 

@RalpH so standalone are less stable in IL2CPP?

 

I'm not completely surprised by this announcement, having been at the GDC WebGL talk. They hinted at other possible uses for the technology, but it's definitely a bold direction to move in. While I actually do find this to be very cool (I love C#), it sort of begs the question... why not just allow side-stepping to c++? I mean, it's not my favorite language, but it would not be the end of the world for me, and it would enable those who want the performance to get it.

 

Most of reflection will work, just not dynamic code generation.

 

First thanks for sharing the insight on this future tech!

In my opinion this is great news. Seems like win-win to me, you're regaining control of key technology and provide what looks to be a much improved solution (both on the users side and on your end). Sure it seems overkill to have to reimplement your own Mono VM and AOT but seeing the potential benefits it seems like it's the right thing to do for the future.

Congrats on the hard work!

 

I'll be happy if 4.5 has WebGL beta il2cpp in it. I have some easy tests.

 

Yeah, ILCPP is slick, but why concentrate on iOS first? While I understand why it first should be for WebGL (new target + optimization for web games weren't always good from my experience, excluding simple demos), choice of iOS as second platform baffles me. If you want to go about improving performance of mobiles, go for Android (most of Android device aren't necessarily as powerful as iDevices). Not only you'd target platform with biggest market share around the world, but also performance improvement will be visible, especially on lower-end devices.

But I'd prefer next platform that will support IL2CPP to be desktops, as even with simple objects that have physics enabled and some game logic attached (tried to do game like Tiny Big), it has big performance impact - and I know it is because scripts, because when I remove them from objects in question, it makes game run smoothly, even though they still have physics.

 

How do you plan to compile the code for a target platform? What I mean is that now you can build a Mac binary on Windows and vice versa, but if you're planing to use target platform compiler wouldn't it be a little more constrained?

 

Fair enough. My question was more to the second point, rather than the plugin approach. It's just that to an outsider, this method seems to be so much more difficult in terms of UT's effort, though obviously it's basically transparent to the end user.

EDIT: I think this is definitely cool tech, if you can pull it off on a wide scale. I'm personally cautiously optimistic, though already people are showing skepticism.

 

Thanks for your replies

It's one things to adapt an existing codebase (i.e. Mono for different platforms) than to rewrite and entire VM/CLI from scratch. So, the number of people you have to bind on those tasks is much higher than improving existing stuff. Doing this platform by platform will require a team of specialists for each platform who cannot be put on other tasks, because of bugfixing/enhancements/improvements/...

Well... reimplementing CLI and VMs sounds like reinventing the wheel to me.

So, will you deliver all compilers needed? Do we get all SDKs from you? Or do we have to side-install those (as we already have to do for Android/iOS)? Which compiler on Windows? VS, gcc, Intel?

Well... then do it the flash way... drop it...

With the difference that there is an additional CPP layer which doesn't exist now. Plus the AOT compiling... Also, those problems have been solved on the different platforms (using Mono, etc), so it's not really a "research" topic anymore...

As you've said yourself, the AOT will not be feature complete for the stand alone version... thus you're trying to solve the problem by worsening the situation and then catching up again...

Don't get me wrong... I see the benefits of rolling it this way... But this new "feature" is currently not what people have expected of Unity. There are too many other things to fix. How in hell can we be sure that a bug is related to the new scripting or to the feature itself?

 

To be fair, this does address a number of major issues and complaints people have had for a long time (GC, outdated .NET).

 

What? I've seen a lot of requests for Mono upgrade (Unity 5 announcement, How can we serve you better topic, ...). To me it seems there weren't a lot of available options since Unity editor and runtime seem to be tied quite deeply to Mono/.NET: either throw an unknown but probably insane amount of money at Xamarin or rewrite the key parts themselves.

 

Thanks for the update, this sort of information is very interesting and useful for planning. I appreciate this is an early view and it's a long way out most likely.

Am I correct in thinking the process would be:
I write C# which is
... compiled to .NET assemblies by (upgraded!) Mono
... compiled by Unity's new il2cpp tool to standard C++
... compiled by an existing platform compiler to native code
... which uses a Unity "VM" (more of a HAL?) to provide a consistent view of target platforms

Is libgc an improvement over the GC in the current Mono Unity uses?

FWIW, a C++ intermediate layer like this is the same approach as some other frameworks I've used (Monkey and OpenFL-based Haxe), where it's worked well and given decent native performance.

 

OK by me. That makes my easy tests easier.

 

Cross-compiling would be nice. One could do all work on PC and avoid upgrading macs every 3 years and when you do upgrade it's be for 1/4th the cost. Apple will love it.

 

Oh, I absolutely agree on the point regarding transparency. I think it's a perfectly sound approach to release this information at this stage, especially since there are live demos of the tech in action, even if WebGL isn't inherently a good platform to demonstrate that, given the performance hurdles unrelated to IL2CPP.

I think, seeing the tech working already is where the "optimistic" part comes in. Getting this working across all the major platforms any time soon... that's where the "cautiously" part comes in.

 

Out of curiosity, what kind of features would this limit? Is dynamic code generation used by LINQ? Are there any popular Asset Store addons that use dynamic code generation? It seems a reasonable limitation given the nature of IL2CPP but I'm curious about the impact.

 

It seems that the technology is very similar to that of .NET Native (http://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing-net-native-preview.aspx)

Since .NET Native seems to be further along in development and aims to support the whole and newest .NET runtime wouldn't it be an option to just licence that technology instead of making the huge investment of building something very similar on your own?

Also even if building it on your own I agree that the far best option would be to open source IL2CPP so that it can benefit from user submitted patches, I assume that the interest in IL2CPP would be rather big even outside the game-development community.

 

iOS, already uses AOT, so you can kind of use that as a baseline for what will and won't work. I think things like sorting using .ThenBy() in LINQ won't work, but most things do work.

 

Yay Unity adopts C++ as it's programming language!

 

Ok... I get that... basically, you split the cake in two: instead of writing a JIT compiler, you write a IL/Cpp converter which takes into account the specifics of the target platform (compiler specifics, target platform capabilities, ...). Then a 3rd party provider delivers a compiler (whoever that is) and you/we rely on that compiler to do the right optimization for the code.

Wouldn't you still have to make sure that the compiler doesn't "overoptimize" and rearrage API calls? How can we determine which layer is responsible for a bug? (i.e. is it due to a bug in the VM/HAL, is it a bug in the translation IL2CPP, is it a general API bug/misunderstanding of the API)

 

Well... updating Mono (espacially the GC part as requested by many) and making some alternative, non-memory-allocating calls, or rewrite key parts are two different shoes. Finally it comes back to the estimation: How much does it cost me to do it myself (estimated # of man-months x salary x security value) or buy it from a 3rd party provider.

As it is now, there has been requests to improve Mono, but seeing this announcement and the responses to the questions tells me that a complete switch from current Mono/JIT to AOT compiling and IL2CPP is still several years away (complete means switch all platforms; feature complete). And this most likely means that there will be no changes to the current Mono/GC issues.