Mono Upgrade Future plans for the Mono runtime upgrade

You wrong

Task and async/await is just a conceptual library to Tasking things. It just the default TaskRunner of dotnet library is threading. But you could always override that to single thread runner. You could even change TaskRunner to work under CoRoutine itself if you would like

You don't understand that Task and CoRoutine is both screwdriver. It is the same and Task is actually more elaborate to the point that is was used in multithread

If I would make analogy I could said that it is a new screwdriver that could drive multiple screws at the same time. And you just only see it drive 4 screws so you scare that it can only drive 4 screws and cannot drive 1 screw. But it actually can drive any number of screw so 1 is never be a problem

 

Nearly 2 months so I wish to ask this again
Will I could be sure that .NET 4.6 will release with the 2017.1 ?
I wish it would at least still being experimental flag in 2017.1. But please don't take it out from the actual release

 

That's great! Now I will go 2017.1 for my project without turning back too

 

Hi, checking in again! I downloaded and tried out the new runtime but I was frustrated to find out that it can only load other full .NET framework libraries. I think a few others have run into this problem but packages built based on .NET Standard are unable to be used with Unity3D because they move the responsibility of the runtime to a separate DLL that is not provided with the full profile (i.e. System.Runtime.dll)

I was able to get things to work by moving all the needed DLLs into the plugins folder of a test project, however (including getting System.Runtime.dll off of Nuget) so if you are facing a similar issue this might help. Has anyone else found a more elegant solution? What I'd really like to do is use Nuget with Unity3D, but that doesn't seem to be easily allowed yet.

 

Thanks for replying so quickly! I'm really looking forward to that. In the meantime I wrote a blog post about what I did to make the library work (i.e. getting stuff manually off of Nuget, taking advantage of multi-framework targeting, moving it into the Unity project and compiling, etc). I can post it here if that's ok, as it might be informative for others, but if not that's fine too (it could be self promoting since it is the product that I work on)

 

Here is the post!

 

I'd like to point out some pain I had with this (not specific to Unity3D, but probably applicable). Once you await something, be aware that when you return you are not necessarily on the same thread anymore. In fact you are probably not. That means that if you depend on being on the Unity main thread you WILL find yourself off of it after the await. This is not a problem with Coroutines. By default, though, SynchronizationContext is completely worthless and this would need to be implemented inside of Unity3D itself using a consumer queue. There is no way to inject yourself back into a running thread without that thread knowing about that situation first.

So don't think that async / await is some magic that will work automatically, it requires orchestration. See this thread for your fate.

 

I have to ask since this is on topic of the Mono Runtime. Is InternalCall open to Unity Game Developers to use to speed up native C++ libraries? Or is that something still exclusive to the Unity Engine?

 

Thanks, fantastic video!

 

@JoshPeterson
Hey, quick questions:
1) Ref returns - since they're in c# language version 7, unity won't support them for now, but I feel like that will change soon, right?
2) What exactly are the performance implications here, specifically I have an scneario in mind:
getting and modifying all particles in a particle system (right now you have to provide a list or array and unity will copy over all data into your array). That should be a lot more performant using ref-returns, right? Or is the native<>managed transition getting in the way here as usual? If so, what are potential places where ref-returns can really make a difference in Unity?
3) What is the approximate time-table for supporting c#7 and higher?
4) Will unity make 100% use of roslyn to compile code, ditching the mono compiler and only using mono for the runtime eventually? (or is that already the case maybe?)

 

Thanks for the really quick answer.
That talk was super awsome btw, I didn't expect that job system stuff to be that cool (auto-rewriting code?, no vtables?, ... wow!)

Sounds like Unity is on a great path when it comes to performance.

I don't suppose you guys have using this for scene load integration on your road map yet?
The integrate step of SceneManager.LoadSceneAsync still produces really bad (20ms+) hickups quite often even when you have no MonoBehaviours and only unity internal stuff (Terrain, SkinnedMeshRenderer).

Any plans using that new system to improve that?
Since you seem to be working on compiler stuff mostly, you might be the wrong guy to ask for that; In that case, would you happen to know who should I talk to in regards to that?

 

That seems far more useful than the 'Assembly Definition' stuff put in 2017.2/3.. far more useful and easier than trying to manually tidy up a project filled with third party stuff. It's just a mess to trying to work with assembly definitions imo... and looks like it will be in the future completely useless?.. the first time I tried it, the biggest problem is zero automation/helper tools in the editor to assist users see where things could tidied up without breaking the project.

So that looks far more useful and what is needed for an automatic boost to things like iteratative script changes with zero dev effort or thought to messing with doing assembly def's just to try improve recompile times.

 

They said they'll cover doing the assembly definition stuff with an UI / Editor 100%. No manual fiddling around with json files. I think I even saw a screenshot somewhere already.

Keeping a project clean is one thing. Sure it's important, but what's even more important is that you keep understanding your own project If your project organization is messed up, then sooner or later that'll bite you in the ass. And then faster compile times won't help you either.
So the feature will not be useless in any case.

However I agree, faster compile and reload times are really needed.
I don't know how much faster the whole process will get though! Serialization and restarting (deserializing and instantiating the old stuff again) the CLR stuff take quite a bit of time as well I think, in addition to the raw compilation time.

Anyone know what's the factor of that? Like how much % of the time is spent actually recompiling and how much is spent on serialization and instancing objects again?

 

Are you going to support some Portable Class Library profiles alongside with .net Standard?

 

.NET Standard is the replacement for PCL...

 

Why both? To ease an eventual transition away from 4.6?

Also, supposedly .Net Core 2.0 has dramatically improved the performance of many APIs. I know Unity won't be built on Core, but given that Core is open source, is it being referenced to bring similar gains to Unity's .Net Standard 2.0 implementation?

Thank you for the work that you're doing, and for maintaining good communication and transparency with the community!

 

for the same reason that now we have full 2.0 and subset, except .net standard apis are not chosen arbitrarily by unity

namely, subset/standard have less API but has a smaller build size and should be aot friendlier

full profile is if you have something that don't support standard

 

Technically the Standard profile is meant to separate .NET from Windows-specific features, whereas the full (Framework) profile retails all those dependencies (GDI, certain approaches to crypto, etc)

 

Wow nice to listen about news!

How did you write embedded mono runtime into application. I already read history of mono website. They say team made unity3d with mono. Wow awesome idea. I am really sad because I already tried mkbundle with cygwin and Visual Studio 2017 Community because i want try application like Unity3D program or WaveEditor ( it is ready released but it is very unsafe because WaveEditor forgets protection with mkbundle. ) Why does after compiler for me with stupid openning console window. But i already check my application is target for winexe and after compiler via gcc from cygwin than result looks like crazy why does it need openning console window or did I create simple project c++/+ ( empty project or win32 project ) with embedded packed object ( mkbundle -oo embed.o but Visual Studio doesn't know gcc's embedded packed object.) Thanks i search google. But google doesn't help me.

Sorry for my bad English!

//Edit

Why not use Gtk# 2.xx? Gtk# 2.xx is really stable because it works fine with opengl viewport like DirectWidget or ViewportWidget with libgtk-win32-2-0.dll ( it's like embedded opengl container ) and OpenTK 3.0 / 2.0.
WaveEngine uses Gtk# 2.xx and OpenTK 2.0 and SharpDX ( for DirectX , Windows Users only )

 

Hi Josh,

was wondering if you could give any updates on the new GC integration progress, ideally something like a tentative release date / version?
Think this has been talked about for something like two years now and it's still in the "In Development" category on the roadmap while IMHO a very important improvement to come.

Thanks for all the updates on the runtime update progress

Regards,
Chris

 

Will a new GC (if we even get one in the next 5-10 years) even bring that much improvement to the table?
A thing that does a partial collection, so it can be split over multiple frames, would be a real improvement.
But I don't know if that is even (easily) possible.

 

Could you perhaps make a concerted effort to specifically hunt for allocating APIs?

Asking for a GC-free version of a single method is not near sexy enough to climb the suggestions rankings. At the same time, there's very many APIs that currently allocate and return arrays.

It feels like allocating APIs are getting fixed in a very slow, ad hoc way; a while ago most of the GetComponent's got a nonalloc version, but a lot of similar methods (Like the FindObjectsOfType and such) didn't get the same love.

My favourite is CalculateFrustumPlanes:

Code (csharp):

1. public static Plane[] CalculateFrustumPlanes(Matrix4x4 worldToProjectionMatrix) <= public API
2. {
3.   Plane[] planes = new Plane[6]; <= cry
4.   GeometryUtility.Internal_ExtractPlanes(planes, worldToProjectionMatrix); <= private API
5.   return planes; <= cry more
6. }

A large push to fix those things would be a large help in reducing allocations. Often these are also not APIs that will be helped by ref returns - you'd not return a reference to the result of FindObjectsOfType.

 

@josh thanks GTK# 2 is really stable because WaveEditor uses native with GTK# 2 with Gtk Runtime 2.x

But I know that. Gtk Runtime 3 and Gtk# 3 are really unstable because they haven't any methods like onExposedHandler from OpenGL Viewport ( it is like magic of eventhandler ) or any features of Gtk#2 2 and Gtk Runtime 2. Of course support platforms like Windows, Mac, Linux and FreeBSD.

FreeBSD has same Mono Runtime ( But somebody need compile and install )

Wait I see "GC" Oh no you won't support and how does it happen with Mono Sgen 2.0 dll

 

@Joachim_Ante Have you considered implementing Awaitable-Awaiter Pattern over job system? Async/await in C# does not rely on predefined `Task<T>` or `ValueTask<T>` types only.

 

@JoshPeterson ...Or maybe I've mentioned wrong username @Joachim_Ante for the speaker from video above, so he didn't receive notification from this thread?

 

You know Joachim Ante is one of Unity's co-founders and CTO right? (like executive level/boss/big tamale, you know?). Doubt he'll be replying very often in the forums. He's most likely very busy with other stuff...

 

Let me go a little bit off topic. This summer I visited CERN in Geneva, took a guided tour. And you know what is interesting: tours are free, and they don't have dedicated guides for tours. It's every professional physicist's responsibility to become a guide at some point, when it's his turn. It does not matter if he or she is PhD boss in some lab. It's big Nuclear Research Center, but they don't think that popularization, explaining, answering are below their level. They are not too busy for stuff like this.

 

Invalid conclusion. I ran a very successful business. Various government-mandated activities put demands on my time regardless of whether more important things needed my attention.

 

I don't think you can compare that kind of externally funded research facility (paid by multiple groups and even countries) with a business (where the objective is keeping your company afloat and profitable). Plus, I doubt the director of the facility was the one giving you that tour... I humbly doubt a place like CERN, which mostly consumes resources, has the extra money to hire staff just for that (it already spends tons in equipment, maintenance, researcher's payrolls and what not).

And, well, I also doubt having the "boss" from some lab busy somewhere else is going to affect the "company" in any way, since their aim is different...

 

No I don't.

I do not know him as CTO or co-founder of something. I only know him as “that guy from Unite Europe 2017 video, that Josh has referenced above”. That's all. In the end of that session he asked for questions, and people asked, and there was nothing like “I'm too busy being a Big Boss to answer your technical questions”.

 

Settle down. Perhaps @JoshPeterson can mediate.
On the other hand, @Qbit86 that session was part of a conference that most of the important people in the company attend since it promotes the engine. It's not the same. I doubt he's obligated to be in the forums nor does he have to answer questions in the forums. Perhaps he will though, perhaps he won't. At any rate, it's ok not to know what his capacity is so let's just end this here. No reason to further sidetrack this thread.

 

I just watched this.
Any plans in incorporating this as well? Or will you favor your own NativeArray over this due to it being compatible with the JobSystem?

 

Any plans on supporting the ThreadStatic attribute?

 

Doesn't it just work?