Xamarin now free (and supposedly open source)

W̶a̶i̶t̶,̶ ̶y̶o̶u̶ ̶d̶o̶n̶'̶t̶ ̶h̶a̶v̶e̶ ̶s̶t̶r̶i̶k̶e̶t̶h̶r̶o̶u̶g̶h̶ ̶t̶o̶o̶l̶?̶

 

IL2CPP is about a 3rd faster then Mono but not .NET.
.NET Core (aka coreclr) is about a 3rd faster then older versions of .NET with my tests [.NET 3.5] (would have to check again) and the old versions of .NET were already faster then Mono and IL2CPP.

Now I know its a HUGE project to update anything to .NET over Mono as the embedded APIs are different. Also IL2CPP may be more portable then both .NET and Mono because of how it compiles out into C/C++ code... a method I personally agree with and wish .NET itself would implement over LLVM back-ends as it allows you to target VC++, GCC, CLANG, etc compilers.... much more practical.

Because of this I wish IL2CPP would contribute to the .NET foundation and not just consume it by open sourcing IL2CPP at some point. If anything porting over IL2CPP peaces over in some way that allows .NET to have a MSIL to C++ backend would be awesome!

 

Is there actual proof to what you're saying about IL2CPP being slower than net (if that is what you're implying) ?

I imagine it would be hard to test .net clearly vs mono vs IL2CPP on a phone, as you did of course? Because IL2CPP isn't available on desktop at the moment and such tests would have to eliminate Unity itself as an overhead to be clear.

(as obviously if IL2CPP isn't as fast as .net then we don't really want to be using IL2CPP for anything except WebGL).

But I'd like to see hard data rather than your word (not doubting, just requesting for clarity).

 

How does CoreCLR factor into this discussion? It's an entirely different beast and not even relevant.

 

lolz...

but the emails were sent out yesterday to us... so ya, wewt!.. glad I didn't buy that ridiculous license afterall.

 

I think MS mostly brought them in because Unity is a very popular .NET-based game engine, and MS is starting to gather every very popular .NET-based anything under the umbrella. I think Unity's popularity would have guaranteed them a seat at the table even if MS thought that their runtime was terrible. Honestly I wouldn't be surprised if MS also pushed them to put IL2CPP on the back burner and instead switch to the new open source MS/Xamarin runtime.

 

Okay, but how about for those of us targeting Steam :v

 

Doubtful, and even if it were the case they'd be far more likely to aid in transition from IL2CPP to .NET Native.

 

I don't know... .NET Native has some downsides similar to IL2CPP like lacking the Dynamic reflection features and such; .NET Native seems more geared specifically to phones or embedded apps where the .NET code itself has to eke out as much performance as possible... Unity's engine itself is already mostly native and the .NET layer is just for game logic, where I think added features and compatibility would be more beneficial than a slight performance enhancement. But... we'll see I guess. Any change in direction would be good. I just don't want to see them say "Yay, we can now legally update our .NET runtime for the first time in a decade. But instead we're going to hold out just three or four more quick years to iron out the bugs in IL2CPP just to show Xamarin and MS we don't need their help."

 

That's really grabbing at straws. A pessimistic view. I think they're instead practical: WebGL isn't going away. IL2CPP has to be made regardless. Might as well make it really good.

 

Edit: Wow ok, obviously nobody finds IL2CPP's name a little funny..

Anywho, if it works as well a later versions of Mono then fine.. There are quite a few features in C# 6.0 that'd be handy though.. So a long a we can have our cake and eat it, no problems.!

 

I don't think they need IL2CPP for WebGL; they could just use Mono now.

 

No they can't. Webgl is based on asm.js, a precursor to webassembly, and it needs byte code. As to .net native vs il2cpp... They have exactly the same limitations that mono already had on iOS. It's AOT. In fact, the original bits of my asset that are ported to work on iOS worked out of the box with webgl and on all other il2cpp (and AOT) platforms. The only real downside is that il2cpp forces AOT compilation onto all platforms and I mostly despise AOT. On the other hand it also makes implementations consistent across platforms.

 

I'll admit I haven't used Unity's WebGL yet, but as I understand it it takes C#, compiles to CIL, uses IL2CPP to convert CIL to C++, uses LLVM to convert C++ to IF, then uses Enscripten to convert IF to asm.js. Instead of going through all that, they could go from C# directly to LLVM to asm.js using something like LLILC and Roslyn. All these acronyms are giving me a headache. I guess mainly my point is that I don't see a "need" to get to C++ for WebGL, the only purpose it's currently serving is as a middle step in the long conversion of .NET to WebGL.

I also mostly despise AOT which is why I'd rather have real .NET than .NET Native. But I'd gladly take .NET Native over the current Mono runtime or IL2CPP.

 

Why do you guys despise AOT?

 

AOT is very rigid. It involves some magic to get some things working. Reflection is particularly problematic, at least I'm terms of dynamic type creation and instantiation. Even generics don't work well with AOT which is where some of that magic happens. There's actually a kind of JITish bit that happens, involving heavy use of trampolines that bounce in and out of semi managed code to support them. The exceptions generated by AOT issues are also problematic and often hard to track down. The older mono runtime resulted in bugs with AOT that were difficult to work around. I've seen at least as many in il2cpp generated code on some AOT platforms (xbox one in particular) that are brutal, one of which was reported over a year ago and I still don't think Unity has fixed it.

The biggest issue I feel with it (AOT in general) is that we are using a managed framework with some very nice features that AOT limits or eliminates. Even with an upgraded .net profile we will likely never see the introduction of dynamic support as I'm not sure it can be made to work in an AOT environment. In most cases it's better to avoid dynamic anyway but it can be very handy when working with nosql databases and even quick serialization and deserialization.

 

I do, mainly because I have the "IL2" part stuck in my head as "I love to."

 

I see yeah. I tend to avoid most of C#'s exotic features (one might call them standard) but I'm pretty basic in terms of what language features I use, so I'll most likely never encounter these problems. I can see how they'd plague people who architect code.

 

Yeah it's a personal preference for me. However, as I alluded to as well, the benefits of consistency and eventually performance once il2cpp is stabilized will outweigh the cons.

 

I just want the garbage collection problems to go away, or at least diminish drastically. I just had a case where Unity's terrible GC pretty much stalled me on a game. It wasn't because of my own code, but a 3rd party's networking solution that simply had terrible garbage collection problems. And 3 or 4 months of work came to a halt for me, and now I have to find a new networking solution as well as restructure my entire game to work with the new system. All this because the garbage collection in Unity is just really bad.

 

That just sucks. Yeah... Glad unity is doing something about the Garbage collection issues

 

Sounds to me at least part of the blame lies with incompetent third party developers.

 

Windows Store is stupid, anyway. Another GFWL, except now it supports apps too. I wouldn't be even surprised if it'd turn out GFWL and WS has similar code base.

 

It's a whole different animal. UWP uses .NET Core and compiles to .NET Native before publishing.

 

Ye, me too. For me 'New Mono' (or .NET) = new GC. That all.

 

Probably but I am guessing this is a huge area of optimization that would help a lot of folks regardless. I remember on IRC chatting with one of the Trion guys using UE4 and talking about how I was using pooling for all my enemies and various components to avoid GC and he was like "what? never had to do that, just instantiate a new one". Seems like an easy win.

 

Yeah, UE4 *does* suffer the same gc stalls. So presumably, he's not pressuring it enough.

 

Could be, also it was desktop

 

I think the point was, it's harder to pressure the GC in UE4 because it's better... as in, it's not something you have to constantly worry about.

 

I think you should constantly worry about it regardless unless you want to just waste performance, which is what it sounds like. For the best game, regardless of language or engine, you want to use best practises.

 

This. No more excuses. Time to swallow your pride of IL2CPP and focus on the customers now. It is incredibly frustrating and depressing to see the world continue to progress forward while Unity stubbornly remains in 2009.

The feature set is already broken between platforms (with Windows Phone), and WebGL is still not ready for prime time anyway. So even if IL2CPP is required for WebGL, let WebGL be the one under constant development with IL2CPP and let everything else get the upgrade now.

 

If you want faster desktop engine, go use UE4 ?

 

I dunno if it is faster though.

 

Well ... at least he will get a better garbage collector

 

Dunno if it is. https://wiki.unrealengine.com/Garbage_Collection_Overview
After a while you wonder why UE4 bothers with a gc if it's so hands-on. Might as well just have really nice ways to manage memory manually.

I guess it's really only intended for beginners to get up and running before switching code over to manual control when things get slow.

Which isn't really any different to avoiding allocations in Unity (which you will always need to do in game development if you want perf).

However the downside in Unity is that you often can't avoid it. Because things like OnCollisionStay can't always be avoided unless you want a game that doesn't work as well as it could.

Basically long before Unity overhauls it's GC it should provide means for us to avoid using the GC to begin with. Currently that doesn't look so easy. Even the new cinematic post allocates data with command buffers. Lots of that needs to be fixed before GC since those problems are not going away with a better band aid.

 

A newer mono would be good.

And I'm not completely sold on IL2CPP. It's really debatable if it's faster than the really old mono we have right now (old link, but I can't find anything more recent: http://jacksondunstan.com/articles/3001 see the benchmarks at the bottom), so it's a pretty safe bet that it's not faster, currently, than a recent Mono.

Maybe it has the potential to be faster assuming enough work goes into it, maybe not, I wouldn't know.

 

Yes this is definitely true. But I can't put the third party developer in a headlock and force him to fix his asset, or make him restructure it. And fixing it for him would require even more time than if I simply cross over to another solution. In the end it just cost me time and money. Live and learn though as they say. It's just one example why I want Unity to have faster garbage collection though. Is there anyone who likes Unity having a terrible GC?

 

IL2CPP performance increases all the time though, so it's far from a safe bet. It's not static. The link on that page shows the majority of tests were faster with IL2CPP when set to release.

 

And one of which is never to optimize prematurely. As in, don't try to optimize memory, unless it becomes an issue on the target hardware. Also, "practises"? I've thought better of you, hippocoder.

 

Correctly allocating memory and not being wasteful are best practises, it's what you do by default. That has nothing to do with optimisation, which can lead to bad design patterns. Using memory correctly is a good design pattern.

It's normal. I'm saying a lot of users use Unity (and other engines) abnormally because they're not used to game development or lack experience in game development. For example in any AAA game you've got, 100% chance they're pooling stuff.

Pooling isn't optimisation. It's normal. Not pooling is simply deliberately thrashing memory, you have to go out of your way to do it. It's as if you're rebooting that part of your game constantly. That is why it is a design practise and not an optimisation.

In any case, the focus is on what we can't work with, allocations which are unavoidable, these are what the focus is about and best practises cannot avoid these.

 

Kind of interesting that none of the Unity video tutorials... well, none of the beginner to intermediate (the only ones I've watched)... even use the P-word, if I recall correctly.

 

Unity advocates using instantiate and co routines, both which personally I find counter productive in producing full working fast functioning games.

I think the take away is, that the learn tutorials are designed to aid people with zero experience in game development.

Pooling and even Octrees, spatial stuff, are essential core features of any game really, and Unity does not natively support either. Should it? Yes - if it can be done higher performance and simpler than using C# for the job, since all games will at some point benefit from them.

 

Umbra does take care about culling, so you don't need octree culling ?
About pooling there is some plugin you must buy , but it is easy to create a pool using some array , still i agree Unity should have prefabs pooling functionnality as a C++ in the engine.

 

Does a pooling asset (or engine feature) really save much dev work?

 

What? How is it not? Mono and .NET can fully share any of there code with one another... this could mean a lot of things but may mean very little depending on how things play out for Unity on this.

1) .NET and Mono are now both part of the .NET foundation under the MIT licence. (What does this mean for IL2CPP and Unity's Mono in terms of performance and features?)

2).NET is a baseline for performance comparison when it comes to Mono or IL2CPP in Unity3D. Its very relevant to this topic in that aspect.

3) Because .NET and Mono are now both MIT it opens up questions about what direction Unity should or will take in the future. (Update Mono, switch to coreclr or keep pushing IL2CPP even though its way behind in features but not performance).

4) This is a general discussion form for a reason and the topic was meant to spark discussion about what this news might mean for Unity and the C# / .NET ecosystem. Performance in my mind is in the top two... so if there is something wrong with bringing this up.. tough.

 

Hmm... what is your solution for the AOT platforms if you want to get rid of IL2CPP? AFAIK IL2CPP is currently ahead of everything when it comes to total of supported platforms and development stage.

 

info from where? last time ive seen the actual numbers it felt more like they struggle to fulfill the promises, because in many cases on many platforms in common scenarios numbers were WORSE than on mono. So i think you are wrong.

 

why would anyone do that.
#MShater

 

its more of a common code paradigm than some unity specific thing. Any small object can be reused to decrease memory footprint and increase performance by minimizing allocation, in unity world is some kind of buzzword.