Consider making mutating Assets<T> more Scheduler friendly

[cart]

Modifying an asset currently requires grabbing a mutable reference to Assets<T>. This makes sense conceptually, but Legion's Scheduler (correctly) synchronizes when a mutable reference is grabbed. This means multiple systems requiring mut access to the same Assets<T> storage cant run in parallel.

It is worth adding some interior mutability / RwLocks to Assets<T> to see if this improves performance for common use cases.

[Moxinilian]

Wouldn’t it encourage making large systems? To me making small systems is good practice because it makes parallelism better and as a result should reduce the cost of mutable asset modification, maybe?

[cart]

Whats your definition of "system size" in this case? Number of Resource dependencies or number entities matching a query?

I agree that keeping the Resource dependency count down is a good idea (for the reasons you state), but that holds true no matter what. I'm not convinced artificially making it harder to use specific resource types is a productive mindset. The change above would also enable inner-system parallelism (query.par_iter) when mutating Assets, which I think by itself justifies the change and offsets the cost of making it easier to take dependencies on more resources.

[Moxinilian]

System size to me is the amount of work it does on a run. In a sense this is somewhat linked to the amount of dependencies but not really.

But come to think of it, if it’s an optional way to optimize some really specific cases that can’t be solved otherwise, it seems okay to me.

[alice-i-cecile]

We encountered this in #6341, where there were a large number of spurious system order ambiguities caused by Assets<Image>.

[cart]

Closing this because I'm not convinced it is worth solving. The odds of multiple systems writing assets at the same time (and that being a bottleneck) is slim, whereas something like RwLock-ing everything would be a constant overhead.

If this ever shows up in benchmarks we can reconsider.