Major Performance Improvements

[Frooxius]

Read the announcement here: https://store.steampowered.com/news/app/2519830/view/6168323165072831255

You can discuss and ask questions here!

[ohzee00]

Is there any misconceptions the team wants to dispel about Resonite performance or about the possible performance improvements itself that come to mind?

[Frooxius]

There's multithreading! >:I

That's the most common one. Yes there needs to be a lot more, but multi-threading is not an on/off switch. Resonite is a complex codebase. And multi-threading can be applied to lots of parts of this codebase.

We've already put significant efforts to multithread large chunks of the system. There are more that we need to do that will help more.

Also multi-threading isn't the only thing that can improve performance - applying it to certain parts needs some prep-work too and often you want to make the code much faster even within a single thread first, before spreading the workload out (and not all workloads can be spread out).

In short, I want people to think of multithreading more like a country switching to solar/wind from coal plants - it's not a binary on/off thing - it's something you "deploy" and build gradually.

[TisFoolish]

In short, I want people to think of multithreading more like a country switching to solar/wind from coal plants - it's not a binary on/off thing - it's something you "deploy" and build gradually.

On top of that, too much multithreading can actually be bad, causing performance to get worse.

[BlueCyro]

Not to mention that - once we move to .NET 8 - there'll be oppourtunities to do some serious legwork on certain workloads with vectorizations both automatic by the runtime, and hand-crafted with System.Numerics (my beloved)

[jae1911]

In #2265, it is mentioned that:

This will allow us to better evaluate the impact for .NET on performance and estimate performance improvements for the graphical client from the same switch that would be done through this issue: #706

Does this means that the headless will be generally prioritised to be used as a testbed for performance upgrades before the graphical client gets impacted?

[Frooxius]

Yes. The headless is significantly simpler to move over to .NET, so it makes sense to do it first. Moving the graphical client is much bigger task, so we want to get some data first before we commit to that workload (plus it gets us a bunch of improvements that we can benefit from right away too).

[Geenz]

Not to mention Sauce will also benefit massively from the headless receiving .NET focus first. It enables us to further dive in on some of the lingering issues that come with a .NET 8 switch, and collaborate on some of these problems at Sauce's development proceeds given that we're largely basing things off of the headless for the time being.

[Frooxius]

Yeah! There's a lot of synergy for things.

Generally we'll try to get as much improvements along the way as we can to make as much out of our time as we can.

[ohzee00]

One thing I noticed being really high in the debug menu (which I know isn't the best to base things off of) is that ProtofluxContinousChanges is usually the highest among the other protoflux frametimes.

What exactly is it and why is it in particular so heavy? I know it is caused by drives from protoflux but I'm unsure if that is listing the overhead of driving or the calculations protoflux is doing to drive something.

To be clear I know this is just a aspect of performance, not blaming protoflux itself as being the problem.

[Frooxius]

It's all ProtoFlux that's continuously being updated.

ProtoFlux is just a programming tool, so that means the user code is running and taking a lot of time. How much of that is ProtoFlux and how much the user code - we don't know.

That's where we need to do some bench-marking and get some data on things like this to drill into them.

[TisFoolish]

Will part of the work updating to .NET 8 be ensuring that updating to future versions of .NET is relatively easy?

[ProbablePrime]

I think so.

When we update things it's usually going from .NET Framework 4.7.2 all the way to .NET 8. That's a huge task! Think pushing a big boulder up a hill.

.NET 9(already in preview) is likely to be a much smaller boulder, or a much smaller hill.

Software Projects tend to get harder to upgrade the longer they spend on older versions, that's why there are so many tools for automatically updating your dependencies such as Dependabot.

[Frooxius]

Yes. Right now the main problem for graphical client is that we can't use what runtime we want - it's tied to whatever Unity has.

Majority of the work will be going towards decoupling that and making sure that we can use the runtime we want. Going from .NET Framework to .NET 8 itself is relatively easy part - there's not too many specific dependencies, so must stuff is just compatible.

Once we can use whatever runtime we want, updating .NET versions becomes relatively trivial - they are also largely compatible between versions.

[bredo228]

Will the Headless have a prerelease of the .NET upgrade available before it is pushed to the main headless branch on Steam?

I expect many people running the headless will need to prepare for the transition - updating launch scripts, docker images etc. to run with .NET instead of mono

[Frooxius]

Yes, we'll have pre-release versions.

[bredo228]

Yes, we'll have pre-release versions.

Thanks, good to hear.

[BlueCyro]

Perhaps you're already aware of the steps required to update the headless, but I wanted to point out the road bumps that I came across when making my own patch to get it running on .NET 8 just in case. Maybe it'll be helpful!

1. SSL3 is now deprecated, this is used in FrooxEngine.LibraryInitializer for the SecurityPointManager. I simply removed it and left the others intact as this didn't seem to have a noticeable impact on the state of the headless while running, but you'd probably wanna double check properly for an official implementation.

2. FrooxEngine.Weaver.AssemblyPostProcessor starts on fire when it tries to load plugin assemblies with Mono.Cecil (likely just from it being out of date, I forgot) and so that's gonna be another thing to grab a fire extinguisher for.

3. Thread.Abort() has been deprecated and usages of it cause crashes in ThreadWorker and WorkProcessor.JobWorker. Simply doing a soft interrupt with Thread.Interrupt() instead seems to do the trick here quite successfully from field testing. I'm fairly confident there aren't any issues with just replacing those like that.

4. The typing issue of course, but that's covered by Redesign & rework type serialization & negotiation #2264

Aside from the typing issue, those are really the only 3 major roadblocks I encountered when plugging the headless into .NET 8. No idea if you'll run into more complex issues at compile though.

I'm actually pretty impressed there aren't more nasties hiding about; the headless appears to run normally after fixing those few things and absolutely soars in terms of performance gained just from the runtime upgrade.

[Geenz]

Already aware of SSL3 - we have a build for that already to test for that one.
Thread.Abort() we have a separate PR for internally that removes the single instance of it in the codebase.

[Geenz]

The SSL3 thing - the only way to really properly address that is to remove all deprecated protocols of the sort. Which means SSL3, TLS 1.0, and TLS 1.1. There is an RFC on why not to use any of these as they have been compromised. There is an experimental build available for these.

[Abysmal2134]

Since ingame performance metrics for user content are being considered, does that mean we could get avatar filtering in the graphical settings or world settings, so that individual users or hosts of events such as Creator Jam could set their own rendering or world settings to just render/put users in a performant profile picture plus hands avatar based on a certain adjustable metric?

A build in sytem either in the world session permissions settings, that allows you to adjust and filter how every avatar is rendered, can be a useful built in solution to force better performance either for the whole world or individual user when needed.

Kind of like how mirrors are optionally rendered based on individuial user preferences, or builder permissions restrictions apply for everyone.

[ProbablePrime]

I'd encourage you to ensure you have created and/or linked GH issues for these specific features. They sound tangentially related to performance but as indicated above, we're not really sure what we'll be looking into. So if you want those items make sure they have issues.

[TisFoolish]

What are the current, broad roadblocks to switching over to .NET 8? I know anything that we still make use of from Unity is a blocker, but what else is there?

[ohzee00]

#706 (comment) This post has a fair bit of information about blockers/prerequisites

[ProbablePrime]

For the entirety of the application to be off of .NET 4.7.2 we'll need sauce. Some items/parts such as #706 may allow some parts of the engine to be on .NET 8 earlier.

Oh and also many items from this board: https://github.com/orgs/Yellow-Dog-Man/projects/29