Unite Austin 2017 - Writing High Performance C# Scripts (C# Job System, new Entity Component System)

I'm just impressed whenever a company decides to make it's stuff run faster or more efficiently. I don't think that should ever stop happening at Unity. It should be normal. The days of worrying about how crap Unity runs should eventually be a distant memory.

In any case it's shortened my dev times because most of my dev times were historically coding around Unity's (previously rubbish) performance. It's still the case but becoming rarer by the version release!

 

I definitely want to see the outcome and numbers. Keep us posted.

 

Until they take an approach where the lowest common denominator in platforms doesn't decide what tech they use, unity is going to basically lag behind modern .net runtimes by a factor of years. The difference between where unity is and where the current MS .net runtime is keeps getting larger. .NET core is making that gap even wider.

Eventually it's going to get to the point where they have no choice, they will have to take a separate path for windows. Because while MS has kicked things into high gear and making good progress on making .NET leaner and faster, the same has not been happening in Mono.

Nobody talks about this, because literally you can't, it's against MS licensing to post comparisons. But if you happen to work with unity and non unity stuff, let's just say it's frustratingly obvious.

 

According to this talk, they're working on it...

EDIT: At around 8:15, he is talking about "getting new runtimes and class libraries".

 

They are talking about language features not the runtime. Related but different things.

 

The runtime is via C++ compiler though. This will also be the case for desktop next year.

 

It's still just a runtime. Whether it's JIT or AOT doesn't really change that. My point was that I don't see how Unity can keep up doing their own thing here. Licensing might be the end hurdle they can't get over though. Not really up to speed on the .NET Core licensing.

I know how bad mono is compared to the current .NET Core. Many places it's several thousand times slower. And it's concurrent stuff has historically sucked. And this gets amplified as we move to a multi core world in game engines. I'd be curious how much they borrowed from mono when implementing, or if they pulled from better implementations. My guess is the former given what is actually visible now if you know where to look.

So I'm fairly convinced that unless Unity can find a way to leverage the work being done by MS, it's going to just get slower and slower by comparison. To the point where they will be forced to do something.

 

Unity is already on the case, you're upset over nothing.

 

Show me proof. I haven't seen it.

 

You know mono is owned by ms now, right, and that Unity's on the board? Just checking. Unity is working toward the very goal you're so insistent they aren't, and this is spread throughout the forum, I just do not want to go and gather those posts for you.

 

I never said they were not working towards improving things and I have read most of those posts. Whether I said it badly or people didn't understand I don't know, but pretty much nothing I was trying to address is what you are talking about.

There's a lot of confusion in this area because first off most people don't actually understand all the parts at play here. Plus a lot are interchangeable plus unity has the ability to customize a lot of them now.

Like a lot of people equate the .NET framework with the runtime. And I doubt most people are aware of trends I was referencing.

Basically, yes I know all that and more, and was making the point that given all of that, if Unity continues it's current approach of basing it's runtime off mono for windows and not leveraging .NET Core, then almost ipso facto it's going to continue to lag.

There is a recent post where they said no plans to use .NET Core. Because they want to have consistent api's over all platforms which is understandable. But as I was trying to say that is a lowest common denominator approach. One that IMO will leave windows lagging far behind in performance as long as they continue it.

 

Seems like you decide what's true so we'll leave it at that.

 

The 2018 roadmap has several C# job system related items:
https://unity3d.com/unity/roadmap

• C# Job System
• C# Job system support for Navmesh navigation
• Physics C# Job system support - async raycasts

It's going to happen in just about a month

 

It's amazing, you have absolutely no clue what you are talking about. It seems you are the only one here who's confused. Have you even taken a look at the threads in the experimental scripting section??

They are in fact working towards supporting the .net standard (somehow I doubt you know what that even means, google it).

Also this doesn't really have anything to do with performance. Performance will likely not be affected much (or at all) just because they switch to a different set of base class libraries.

It will however enable further development (IL2CPP, and eventually in the far future an improved GC).

Anyway, you seriously need to stop and read up on what's actually happening.
Here read the threads here that should get you started: https://forum.unity.com/forums/experimental-scripting-previews.107/

And just in case you don't want to search, here's an official post that directly contradicts what you're saying: https://forum.unity.com/threads/built-in-nuget-package-manager-support.504016/#post-3286060

 

Here's hoping that the worst of the bugs are behind us as I am quite thrilled to be playing with some high performance toys in 2018.1...

 

Wow. But ya proving my point in spades about the confusion.

Go read up here on what .NET Core is:
https://docs.microsoft.com/en-us/dotnet/core/

.NET Standard, I never mentioned it intentionally, it has no relation to what I was talking about.

Here are some older micro benchmarks for the different .NET runtimes.
http://codinggorilla.domemtech.com/?p=1499

More recent .NET Core runtimes are making the gap even wider. That was my entire point. So much work is going into .NET Core in the performance area that mono has almost no chance of catching up.

 

Here is the thread saying they will not be adopting .NET Core.

https://forum.unity.com/threads/unity3d-sripting-net-core-1-2-replacement-of-mono.439826/

 

@snacktime, you're talking about the runtimes not the API specification, correct? i.e. Mono and .Net Core are separate in that they both support the same APIs (.NET Standard 2.0, etc), but the implementations are completely different. Sound right?

 

Correct. I was originally trying to address the finer point that there are substantial performance gains in .NET Core, specifically around concurrency. But it's starting to just drag the thread off topic.

 

Do you think those concurrency improvements in Core still matter as much considering the Unity's job system?

Furthermore, Unity is maintaining their own fork of Mono. It's not inconceivable that they'll port over some of the other improvements in in Core if possible, or even make their own improvements. I have to think they're doing everything they can to improvement performance as much as possible - it is being embedded in a game engine after all!

 

Whether they will port over some of the good stuff, which is entirely possible although I really have no idea how likely.

I doubt anything in .NET Core would have a significant impact on the concurrency specific bits of the job system itself. Because it appears they are just using low level api's to handle it, like spinlocks and memory barriers. It's more overall performance and general async stuff we might want to do outside the context of the job system or in parallel with it.

 

Ah I see, when you wrote concurrency I thought you literally meant parallel execution on multiple cores. Meaning Unity wouldn't necessarily need those improvements since we have the job system.
Yeah, all we can do at this point is hope that Unity keeps up with performance on their fork. Or if .NET Core somehow gets ported to more platforms.
I wonder if there any benchmarks of Unity's mono anywhere since their fork is on GitHub...
Anyway, yeah this is slightly off-topic.

 

I imagine the features they add to 2018 are quite complex. Which, from past experience, often caused things to fall apart and they had to repair things via patch releases.

However, they run this C# Job System early preview program, perhaps they caught a lot of issues during this time already. Otherwise I imagine 2018 could be one of the lesser robust versions.

 

On the topic of jobified physics, will this system include non-cast physics functions such as Physics.ComputePenetration ()?

Or will that be a "later date" thing?

 

It looks like they are looking at what physics system elements they need to support in the job system...

They already have Asyn Raycasts on the roadmap for 2018.1

• Physics C# Job system support - async raycasts

 

I would LOVE optimisations if any to ComputePenetration and closest point. Because I use it for practically everything that moves in my game world, all my characters, creatures etc!

@yant any plans to share? ;-)

 

I just watched a talk how Naughty Dog parallelized their engine for The Last of Us Remastered, by implementing a Job System among other things. Very interesting talk.

http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine

PS: Their game ran way below 10fps just two months before release (mentioned around 29min)

 

Fibers can be difficult to work with. Unless you put a good abstraction around them like say Erlang does with actors, you end up with having to work with primitives a lot more at your game logic level like these guys did. Which is probably the right choice for just optimizing a game at the last minute, but given more time there are ways to wrap these in good higher level abstractions.

 

They also prioritised ease of use over max perf with the design goals of their jobs system.

 

According to the talk at around 22min, he says using system primitives (mutex, semaphore, etc) can no longer be used with fibers, because the OS tight those to the executing thread. Fibers, which are just a callstack, can be switched over and continue execution on any of the worker threads.

He says they have an abstraction for system primitives and prevent the job system from ever calling those. He continues with synchronization is implemented on the hardware level using atomic counters.

Did I miss something in the video? Where did you get the information from, that they use primitives a lot at the game logic level?

 

Thread synchronization primitives is specific to threads. I was talking generally. Spin locks also block threads it's just much more efficient and more flexible in some ways.

I was referring to abstractions where you wouldn't have to deal with concurrency at all at the business logic level. In that context just dealing with fibers directly would be low level.

FYI fibers have some of the same drawbacks as event based io systems, they tend to create a form of callback hell. Fibers and event based io both actually grew out of a time where the internet was scaling up fast but linux threads sucked. So fibers got a lot of attention at the time, then kind of died down. And eventually batching kind of took over as the go to solution for context switching on PC. Now consoles might completely favor fibers over batching for reasons I have no clue, I don't really know consoles at all.

 

With 2018.1 beta right around the corner and hopefully the C# Job System as well, do you already have some ideas what you're going to use it for?

 

Yeah! 1000 player PUBG asset flipping clone!

 

please...

 

Mostly I'm happy that the unity internals are making use of it where it make sense (or they're working on it).
Loading files and decompression, particle systems, navmesh related things, ...

The systems where it makes sense for me to use it myself are updating some complex geometry from time to time, and for some effects/physics things (simulating a pressure wave that finds its way around level geometry, some AI that behaves similar to the boids simulation from the early example video from UT)

 

I'll be using it to solve things that benefit from parallelism. This includes AI, but it might not be as direct as controlling the AI itself, it may be that several AI request heavier tasks and this thing picks those jobs up. Automata including particles with decision making.

We will see when I get my filthy hands on it.

 

Right now I'd just like to hear when it's going to hit. 2018 beta has some basic job stuff but no support for any api's and no ECS that I can see. So has it been postponed and for how long?

 

I'm actually doing that for AI right now with the Task system. Basically my entire Ai behavior tree logic is there. It makes decisions that it pushes to a concurrent queue for access in Update.

Since Unity has a very specific flow you can safely read a lot of data from the main thread. My ai tick starts when LateUpdate hits, so I know nothing is changing any of the values that I mess with in Update/FixedUpdate.