Roadmap Info:
My take on this is that Unity will move from the .NET 3.x framework to the latest .NET 4.6.x framework (or newer), is that right?
But what will be the major benefits to Unity Developers (a question for the C# gurus)?
Does 4.6.x have a real time or improved GC?
What about .NET Core?
Note: I was tempted to post this in Scripting but I think this could go way beyond just scripting, we could get major new language features?
Garbage collection enhancements were part of .NET 4.5.
A) Assuming it stays mono instead of the newer opensourcery microsoft things, adds the ability to use the mono SGEN gc, which is much quicker / consistent than the current one.
B) Various language features, imo all relatively minor and/or purely syntactic sugar. Except possible the aggressive inlining attributes.
C) Ability to use more recent libraries from the internet without refactoring, searching for 3.5 libs can be a pain.
C) may even be the biggest benefit for the average user.
Also, there may be a big difference here. The roadmap is talking about ânewer .NET profilesâ; this is NOT equal to the newer .NET frameworks. So the garbage collection improvements mentioned by @Ryiah probably arenât applicable, though the SGEN gc improvement is there.
Having easy access to things like the tasks framework would be nice. Sure itâs mostly sugar, but a little sugar is nice.
But GC is the most important piece.
What about the async/wait system introduced in 4.5?
What kind of benefit it gives over, say, coroutines (which if my understanding is correct serves similar purpose)?
The async/await system is multithreading, coroutines is timeslicing within the main thread. Async/await will execute even if the main thread is busy doing things; coroutines will be done during the frame time (and therefore canât really improve fps, but can reduce stuttering).
The async/wait system is syntactic sugar over the current System.Task/Func/Predicate etc. All of it can be done now but the async/wait syntax is nicer, so it takes (significantly?) less overhead to write multithreaded code.
Ah, I see. So itâs multithreading, eh? I wonder how much of Unity is thread-safe, otherwise no sense of doing multithreading with it if the thing you need to use isnât thread safe and you canât change it without source access.
Multi threading is great. In Unity its mostly about decoupling long running calculations from the frame rate. You can do some of the same things with coroutines, but not all. Coroutines still run on the main thread, so there is a maximum number of calcs you can do on a single core. But my favorite part about corooutines is that the operating system manages the time slicing and sharing. Managing time slicing manually with coroutines is a pain.
OK moved but to Editor and General Support, we are talking about a future feature, maybe we need a roadmap topic or future of Unity topic. It would seriously save me from âspammingâ the General topic!
I like the sound of easy multi-threading.
Isnât there a version of foreach that works in parallel?
Now if only MS could upgrade C# .Net so it can work on the GPU and CPU, all that processing power!
âŚPlease, no. GPU programming is something different from CPU programming, and only works for a specific set of mathy things. And you wouldnât be using c# code anyway if you were that desperate for performance.
CUDAfy .NET allows easy development of high performance GPGPU applications completely from the Microsoft .NET framework. Itâs developed in C#.
Ah, right - I forgot that quite some GPGPU processes donât require a lot of cpu pre-processing (or the pre-processing is trivial compared to the gpu time). Still, for games thereâs already the compute shaders, though the setup is different.