Xamarin now free (and supposedly open source)

Of course, and I've written plenty of code in my life to do just that (though I'd typically say "caching" rather than "pooling" -- to me "pooling" has overtones which relate more to connectivity reuse from my socket, DCOM, and DB / LDAP days). But there are plenty of code scenarios where it literally doesn't matter at all, and since Unity is so hyper-sensitive to allocations and GC, it seems like something that would at least warrant a mention here and there.

But similar to Hippo's comment, I see the tutorials as a way to hook newcomers long enough that they can find their way around and figure out how to do things right. They'd probably lose too many people if those tutorials were "done right".

 

I still don't see any of this as an excuse for Unity not to upgrade its GC system, if there is a path for it to do so. And the sooner the better.

 

I didn't mention culling. Octree has nothing to do with culling. It's about fast lookup of objects to a criteria, for example you need to know all the enemies in this area? or maybe you want to store a ton of items in a certain location but only want to spawn them when you get near? or for AI etc... it's just a structure, but something I think many people abuse physx for or just brute force solve, and that's not really good for them.

 

This is something i made by code , some 2D array updated as enemies move around , store them on the right array space based on their position.
Anyway having octree in the engine as C++ , and have some option to enable it in the engine with some parameters, than have the engine dealing with octree automatically and having exposed octree functions would be usefull , there is many uses like streaming also.

Octree has nothing to do with physics ?

 

agree adding to that also the messaging on which unity is built (update method ets) also are done with same approach in mind, if they would require user to actually use override and interfaces it would be harder to get newbs to grasp easily,
but the tradeoff is 5x more overhead from Update than from a cached delegate invocation. I tested.

 

Physics.Overlap sphere
and ofc it has, since all physics colliders etc all are cached in trees under the hood.

 

from my experience with octree it is ineficient to build generic version of them, you will lose a lot of extensibility and performance. Performance wise you would take simple generic version and adapt it to particular situation,
that said you can search github for unity octree, which is exactly that.

 

Thanks i will actually try it.

 

You mean we can use Unity in engine Octree system for our own needs ?
Anyway i found many implementations :
https://github.com/Nition/UnityOctree
https://github.com/Pixelstudio/Octree
http://stagpoint.com/forums/threads/octree-for-unity.13/
I'll dig these and see what i can use for personnal needs.

 

well if you do stuff like OnCollisionEnter etc, its sort of using the octree of physics engine to your own advantage, more relevant example is OverlapSphere which gives speed results comparable to octree search so its fast (but not as a well optimized octree for single object type, because they as far as i understand have to store and process a lot more info).
Here are examples of what you can do with optimized octree that i did

here using sphere overlap -

notice that the lag comes only when the simultaneous collision count and their chained calculations (i.e. 100 cubes each affect all other 100 cubes at the same time) but the actual lookup speed is good

another cool thing

here its octree, each cube is a separate local event system that does look up for surrounding event systems and is extremely fast, as in 10k objects lookup is the fastest out of all means. Here the lag comes from using DOT tween for material animation, which was a mistake i did not realized at the time.

octrees are awesome for complex things and huge scale games, however they again need subtle optimizations to be really efficient, since insertion /removal can dramatically slow it down if not done smart, as well as in node distance calculation method.

 

Mono's AOT system that runs on all iOS devices right now, .NET's lilac MSIL to LLVM AOT system.

Mono has had AOT support for ARM64 devices before IL2CPP did, so I'm not sure what you're trying to say...

 

Player7 rant was removed? anyways @Player7 try my implementation
https://github.com/pointcache/UnityStandardScripts

ill write some quick documentation for it

 

(Yes - please keep on topic, ranting is really drifting - make new threads for new soapboxes)

 

lol that's rich.. I somehow went offtopic..its been offtopic for the past 2 pages.. jeez hippo

 

Ranting puts it over the edge. Get back on topic everyone.

 

There is nothing more to discuss about Xamarin, Unity is aware, let's see if something will happen ?
Anyway some off topic was more usefull and very informative and somewhat on track because it is about performance.

 

Yep but forum rules can only support so much drift. When it turns ugly, it stops.

 

What it is uggly ? This is informayion sharing, usefull.

 

I'll find somewhere to dump that rant again sooner or later hippo..my rants should be left untouched I wouldn't bother posting them if they had no point to be made, so don't get to carried away with that moderating.

 

Isn't that what blogs are for?

 

I dunno why you would ask me that knowing such discussion would be derailing this highly ontopic of xamarins blog thread/performance/etc/ etc/ but no Unity rants allowed thread.. I guess its ok to derail topics on passive nonsense but not critical points.

 

By Majority you mean 4 out of 11?

But yeah, point taken, IL2CPP is an evolving thing... Only I don't see it evolving all that fast (numbers? stats? anyone? I haven't noticed it getting much faster with time) and Mono performance would increase too though, it's just that Unity isn't updating it. (for reasons that are no longer valid).

And maybe IL2CPP has the potential to become much much faster all around even than the latest mono, but when will Unity get there? How many years?

EDIT:

Okay, in the end I don't care. They should do what they think is best. If the think IL2CPP is the way to go, they should (are doing) do that.

I want to say I trust them to do the right thing, but I guess I don't, it's the same company that decided to go with enlighten after all, but that's another story that has been already told many many times.

 

Will we really gain a performance boost ?
Unity 5.4 is a huge step in the right direction with threading and instanciation, and i think Unity should keep working in that direction bringing new features that brings performance instead of betting too much in IL2CPP.
Some examples from UE4 GDC :
- animation threading and update rate at lower rates for distant characters, skip interpolation for distant meshes, update separate populations
-per LOD limit
- Custom physic solver faster than Physix used for characters items for example
- Apex per character cloth budget and moved to threading
- reduce tick manager for some objects or use time manager
- improve particles initialisations
-HLOD to merge meshes and materials and bake material attributes
- capsule shadow maps
- particles alpha cut out
- SSS per vertex possibility etc ...
I think there is lot of room for improvments that could be done first and that are not related to language.

 

I know Mono has one but I did not say iOS, I said all AOT platforms which may include iOS but also such as WebGL and consoles? lilac AOT was only in planned stated when it was open sourced and that's not too long ago.

 

Which would be a valid point if all open issues and roadmapped projects had people assigned to them...

 

Here is some food for thought. Everyone I think is making the mistake of treating Mono and IL2CPP as completely separate entities. IL2CPP is a compiler (or transpiler maybe) that essentially converts the IL generated by .NET / Mono into native code.

Getting IL2CPP onto all platforms really is a move in the direction of updating the .NET Runtime. Unity have said it previously themselves. Once IL2CPP has been updated to all platforms, the .NET Profile can be updated as well (which also means updating IL2CPP to support the new profile so it's a long process).

Edit: While this was a bit off topic, trees like Octree are methods of special partitioning which is why they are unrelated to specific things like culling or physics. They are just tools. A Quad Tree is another kind of tree that just uses x, z and not y so it partitions in 2D space.

I gave a .NET user group presentation on spatial partitioning to solve business problems. For example a taxy company with 2000 taxies needs to know how many taxies are in a certain area. They could ping all 2000 taxies and ask for their location and then do distance math, or they could have taxies register and deregister with nodes in a quad tree. They use super fast self-culling lookups to find which node(s) encompass the desired area and then all the taxis in that container are what they're looking for.

If you have Silverlight installed (this was an old demo), I built an example application that shows quad trees being used. Load it up and check the "Show quad division" box in the upper left corner. Move your mouse around the map to see the quad divisions and taxis found. In the upper right it shows you the number of queries (i.e. it might e 2 instead of 2000).

http://www.dustinhorne.com/quadtreedemo.html

 

Since IL2CPP is of limited usefulness now (at best), it would seem to make a lot more sense to switch the .NET platform first, which I think is the point a lot of people have been trying to make. I agree they aren't independent, but to me it looks like a lot of throw-away work to build so many dependencies on something that is already outdated.

 

Well we'll have to wait for Unity to say something about it. We don't know the facts, but Unity probably does. What if IL2CPP is still faster? What if .NET for whatever reason can't be massaged to run on target platform?

Unity's made blunders before like supporting Flash, then sunsetting it. If it turns out there isn't a speed gain from IL2CPP and there is no reason to go C++ first, then, obviously, IL2CPP is pointless.

But if Unity blogged about it recently saying IL2CPP is going ahead regardless, we should be asking WHY not telling them NOT to. Because we don't have the facts and they do.

If it turns out there are consoles or devices NET just can't reach at the same performance then it's very clear.

So Unity, why still IL2CPP?

 

Maybe @JoshPeterson can comment something or maybe they have not yet gone through everything in detail with all the options they now have available with the latest changes.

 

How faster can it be from .Net ? Is there some early performance tests ?
For PC games i am not sure it will make a real difference.

So when IL2CPP can be expected to come for PC games ? end of year ?
Or can we expect some updraging .Net soon perhaps ?

 

I'm not an expert, so does this mean a better garbage collector for PC games?

 

Certainly, and this is something missed by most benchmarks. I'm guessing it will lead to faster code under the hood in the long term such as not having to copy data so much, and kind of work on the same piece of data the engine would.

 

Agreed, the 1000 Update() blog post really showed just how bad this is. A staggering amount is spent in the interop service. It will be a great day when this is gone.

 

The original post explaining why IL2CPP was being created was that Unity did not want to upgrade the .NET profile on any one platform until they could do it on iOS, and at the time, the only way to do it on iOS without paying Xamarin was to write their own runtime. And the current timeline says that the .NET upgrade will not even be considered until IL2CPP is done. I don't necessarily disagree with that decision, since having wildly different .NET versions on different platforms would be confusing. But that means IL2CPP is, in fact, preventing you from upgrading the .NET profile.

 

But if they didn't have it, some platforms would be quite unavailable. Overall this is faster progression.

 

They could now go back to using Mono on iOS, and use an existing tool to convert .NET into WebGL. I mean, iOS has always worked without IL2CPP, and the only reason they need it for WebGL is as an intermediate step in the conversion from .NET to WebGL where they are already including a chain of third party cross-compilers anyway.

 

It's not just for WebGL though. At some point, you hit platforms which need to be fed C++.

 

I seriously doubt that the news of Xamarin acquisition and subsequent licensing consequences arrived to Unity at the same time they arrived to us. They probably arrived earlier, since they are a strong player in the industry. Chances are, bright minded engineers, marketing directors etc, had the time to weight the options and select a strategy. For some reasons explained above, this strategy includes both IL2CPP and incorporating the latest mono. I am not a big fun of IL2CPP myself, especially the slow compile times it gives drive me nuts. But it is useful now, might prove even more useful soon and does not halt integration of the latest mono. It seems like we have some good news, why not enjoying it ?

 

I don't think there is anything that needs C++ itself; there are just platforms that need native code and have libraries written in C++, like PlayStation. But that is what Mono and MS .NET runtimes are; they run natively and convert .NET IL into native code and run it natively. I think any future platform that is invented is going to have support from multiple languages pretty quickly.

I mean, if someone from Unity gave a reason they "needed" it then I would (probably) stop whining. But the Unity post above is just about how, theoretically, given time, it might, theoretically, be faster, more stable, and more portable than everything Microsoft and Xamarin develop in the future. I just don't have that much faith, nor do I think it's a good use of Unity's time. I don't mean this as a knock to Unity devs. I don't think any major software company is going to be able to write a .NET runtime that's faster, more stable, and more portable than the one that will come from the combined powers of Microsoft, Xamarin, and the whole open source community.

 

Only if the platform allows it. There are platforms, with Apple's iOS being a common example, that require AOT compiling.

 

AOT is still running IL natively; it just doesn't let you generate or run new IL at runtime. IL2CPP doesn't get around that: you can't generate new C++ and compile/run it at runtime on iOS either, as far as I know. I mean maybe you could, but that would be specifically hacking around the security in the OS designed to stop runtime code generation which I'm sure is frowned upon in the app store.

 

This!

Plus, it's already been explained that porting that to platforms where it doesn't already exist is quite a lot of work, where adding support for a new platform to the new pipeline is comparatively much less.

That's not to mention the cost of upgrading on a system where Unity is providing their own support, too. There's no avoiding some level of that, and one of the things IL2CPP does is help minimise it.

Define "need", then.

There's more than one way to skin this cat, so there's no unavoidable requirement for any sole approach. What could someone say to possibly convince you that this approach is at least as reasonable as others?

 

Part of the reason it was hard was that they were not allowed to update their Mono runtime or use anything that Xamarin or Microsoft had released in the last ten years. Now they can.

Also, I'll believe that it "only takes a week" to port IL2CPP to desktop when they actually do it. Since it doesn't even have an ETA yet and has been in the works for over a year, I have some severe doubts that it's actually only going to take them a week when they finally get around to it.

The fact that they couldn't afford a new Mono license from Xamarin but wanted to update .NET on iOS was a real "need". Now that need is gone, though.

 

I don't know how long some of you have been around, but Unity used to work just fine on iOS before they started the IL2CPP project. You can still download older versions of Unity and publish to iOS using Mono instead of IL2CPP. It's not something they need in order to compile to iOS; you can use AOT with regular Mono.

 

See my edits.

Another part of the reason it's hard is that they were supporting platforms that those others were not. I don't know which of the two dozen platforms those were, but they've explained that all of those platforms have existing support for C++ which they can leverage.

No, AOT takes the bytecode and turns it into machine-dependent code prior to deployment to the device. No IL gets deployed to the device.