Unity 5 and Mono Runtime

How do you figure? It's under the "research" section as ".NET Profile Upgrade" which is "long and uncertain timeline".

 

On the 5.3 column they expect to upgrade to MonoDevelop 5.9 which supports .NET Framework 4.5.

 

Don't confuse MonoDevelop with Mono. MonoDevelop is the program you use to write code. Mono is the compiler and runtime. MonoDevelop 5.9 may support .NET 4.5, but Unity will not because it's using an old version of Mono.

 

I don't know what made you think it is just around the corner. When Unity updates Mono, this has to be done on all platforms at once and all that needs to work with il2cpp as well. This is a huge undertaking.
You definitely can't compare that with the delayed UI, because they haven't delayed the Mono upgrade so far, not even once.

 

That's not the message I get at all. It doesn't matter how much you want to do something, you can't start until the dependencies are ready. In this case, IL2CPP needs to be rock solid before they start relying on it for literally everything, and while platform ports may be "easy" there's still quite a few of them, and they all have to be thoroughly tested and ironed out.

Check out IL2CPP on iOS for an example - it's mostly good, but they're still working through issues and there are still usability improvements to be made. Fingers crossed that each platform "completed" makes ports to further platforms more efficient and faster, but remember there are 20+ additional platforms that needs to be done for yet. I think the timescales they've mentioned are perfectly reasonable.

 

Since the thread has resurrected...

There's nothing we can do about the GC, but it's possible to use Task Parallel Library and the latest language features (except dynamic) in Unity if we really want to:

http://forum.unity3d.com/threads/c-6-0.314297/#post-2108999

 

I thought IL2CPP converted .Net IL code (mainly scripted code, UI and 2D code) to C++ code so once you have good coverage of the .Net IL code base then you should be more able to roll it out to other platforms. As you just then need to link in the C++ code to the native Unity modules.

I don't know why people think IL code base and C++ code is going to have to be massively different for each platform. It is only the core Unity modules that should already be built for each platform that need to be linked to and there is already an API defined for this.

For instance I bet that a competent C++ coder could take the C++ code generated when building a WebGL app and with the appropriate Unity core code build to their game to native Unity.

I'm surprised that Unity has not considered allowing coders to do this, they don't need to release the core Unity code base just a core DLL or set of modular DLL's that can be built into a game.

They would get a massive amount of testing and debugging of IL2CPP by the community.

 

No point adding extra noise before the platforms needing the IL2CPP are more stable. Thats why they probably start with only Android next and with a preview tag.

 

There you go again with platforms, the IL2CPP 'platforms' are .Net IL Code and C++, the native side should already be a valid build of the Unity core systems using C++???

The IL2CPP pipeline should be the same until final compile and linking for all platforms. As only in the final compile to native will the native system specific components be combined and these should already be there for existing builds of the engine.

 

Why?
APC sounds like it is a mechanism to pass info to a separate thread are you multi-threading the IL2CPP code into your new task management system?

 

I don't know how Unity pipeline is exactly done but I have based my comments on what I remember and have seen in the iOS megathread where @JoshPeterson has been very active and sometimes commented with details. If there has been platform specific mono stuff going on before IL2CPP was announced that would mean it's possible that new platforms might bring new scenarios that have not been previously encountered with the existing IL2CPP platforms, like Android might have something thats never happening with iOS. I think I've already seen similar between WebGL and iOS once in change logs.

With the past rate of IL2CPP changes in logs adding more platforms even with a preview tag might just create useless noise and slow the IL2CPP development a bit on the platforms where production like support is mandatory (like iOS). Desktop has no need for it for example.

 

It was just an example. What matters is that there is new platform specific code that needs to be implemented. This takes time, because it also needs to be tested and it is not that unlikely that they will create unit tests and integration tests for it.

 

Do you understand that this could be a key step in making all scripted code multi-threaded, your scripts no longer being bottlenecked on a single thread!

This could be awesome for performance gains on multi-core systems.

 

I am definitely missing something. From my point of view, our scripts can be multi-threaded, but we can't access the blocked functionality, because it is not thread safe. Il2cpp won't change anything for that. Code that is not thread safe won't become thread safe because of il2cpp. C++ code is not thread safe, it has to be made thread safe.

But as far as I can see it, it is not the topic of this thread. (Bad joke alert: It is just single and not multi threaded)

 

You say that Desktop does not need IL2CPP and I think in most cases you could have a point, but with VR becoming a new platform that needs maximum performance Unity could again be missing out on using their amazing technology on a this new platform to great effect.

Also games are moving to larger open worlds and therefore would need the performance boost IL2CPP to native can give.

I know Unity is the go to platform for mobile games development but mobile games hardware is moving fast and what was a high end PC game a few years ago can now be played on mobile.

And this is my key point developing for today's Standalone PC's and Mac's is time invested in enabling your game engine with the power to drive tomorrow's mobile games hardware.

 

You do understand that the core of Unity is now task based or multi-threaded and the rendering system with DirectX 12 and Vulkan will become multi-threaded. And APC allows one thread to call a function in another thread. So APC lets your single threaded (at the moment) script code call into Unit's multi-threaded core task system.

The point being that if IL2CPP can give users a good performance boost over Mono they will not need Mono for release builds.

This thread is about upgrades to Mono to improve performance but IL2CPP lets us bypass Mono an inherently lower performance platform than compiled native code, especially for games. But with the benefit that we can keep the easier to use languages like C# and Unityscript.

 

This thread is definitely not about new multi-threading techniques. If you want to continue the discussion, please do so, but I don't think this is the correct place to do it.

Nothing prevents Unity from having asynchronous procedure calls at the moment. But that would require a significant amount of changes for Unity. A requirement for it is always that the code is thread safe and this is not guaranteed at the moment. Just introducing asynchronous procedure calls won't make Unity thread safe.
I don't see a reason why the scheduler could not be integrated with Mono. And Unity clearly stated that it is not planned to drop Mono. For the Unity Editor it is without doubt better to use Mono than il2cpp, because of the way faster iteration times. To keep that, Unity could not only introduce the scheduler integration into il2cpp, but it would be needed for Mono as well.

That is my last comment regarding that within this thread. And yes, I still believe it is off-topic.

 

There is also https://github.com/dotnet/llilc (Compiler for IL to LLVM).
WebAssembly will be supported later on. So WebGL via asm.js or whatever looks already like a dead end to me in long term.

Edit: In the issue list are some discussions containing ideas to make xamarin somehow obsolete
The whole project just started but they make good progress.
I fear that they will be ready before Unity

 

Unity uses Emscripten for the C++ to asm.js translation. Emscripten gets or a new flag for the WebAssembly translation. I don't know where exactly that dead end should be.

I don't.

 

Hey guys was googling around and have been away from Unity for awhile. Are they still using the same Unity 4 Mono version where foreach can result in garbage buildup? Just curious if so.

 

Just ran a quick test and it looks like foreach still allocated about 30-40 bytes each time it is used.

There is a Mono update planned for the future, check the roadmap -> https://unity3d.com/unity/roadmap.

Note that with the migration towards IL2CPP providing native builds this may not be an issue on IL2CPP platforms e.g. iOS

So the question is do the foreach and other garbage generation hotpoints cross over via IL2CPP to native?

 

gonna raise this from the dead lol..

it occurs to me that theoretically, there might be a way to allow native .net via some 'proxies' to unity.. something like:

.net (4.5 etc) ---> c++ mixed mode (CLI/unmanaged .net wrapper to handle boundaries etc instead of COM/ATL/IDL) ---> native c++ dll as a native plugin ---> c# wrapper around dll using pinvokes ---> exposed to unity.

yes it'd be a helluva lot of work, and syncing might be a pita, but it does put the control back to unity and can expose true, possibly *full* .net functionality to unity without the need for conversion.

dunno.. just spit-ballin..

 

i think you misunderstand what i meant

i didn't mean just so i can hack around unity to try to get a reasonable semblance of .net, i meant drop mono internally altogether, and go this route instead, as a *replacement* for mono

afaik, there are already ports for .net for MAC and linux etc.. even if it is xamarin, let that be *their* headache

Shrug.

 

I've always been wondering, why don't you use more recent "MonoBleedingEdge" C# compiler since you ship it anyway? It doesn't have that foreach issue.

 

or as i've said previously, a way for us to plug in whatever version of mono we want. that way, if we wanted, we could license it ourselves and use it..

 

yeah, kinda figured ;(

at least for now, that's good news on the upgrade, however i'm hoping it'll be to a version that would allow at least .net 4 functionality. anything less wouldn't really qualify as an upgrade to me. it isn't just the GC stuff, it's additional functionality and fixes to .net

thanks for the touchback man