When I understand this correctly, this method requires three rows: previous, current and next. Is that correct?

@Philipp yes, exactly. That's the main point of the problem.

Then why not pass those as three separate NativeArray<float2>?

@Philipp problem is, I have a normal List<List<Vector2>> current, next that everything take information from. So the general process looks like: Copy info from current to NativeArray<> -> Get all JobHandle into a list of some sort and call CompleteAll -> Copy back info from NativeArray<> to next. So since nested NativeArray aren't allow, I don't know how to dispose of the NativeArray<> created in step 1.

@Philipp I mean I (think I) could create global NativeArray<> (s) and do everything with just NativeArray<> that is declared with Allocator.Persistent, but I'd have to rewrite a lot of the code 'cause I have to flatten the matrixes etc... and IMO I just don't like the general idea.

Have you considered to use two separate persistent matrices "current" and "next" and then after each iteration simply switch their meanings, so the next becomes the current and the current becomes the next without actually copying anything? That way you could avoid copying and reallocation.

I did did that, but as stated I still have to copy the info from current to NativeArray<> for those jobs to use, no?

This type of simulation is ripe for doing on the GPU,, where we could do it with 5 texture taps, taking advantage of hardware texture filtering to do some of the kernel function's work. Is that a suitable approach for your needs?

@silverfox Is it really necessary to keep the data in a List<List<Vector2>> and convert it each time you run the job on it? It might be more efficient to keep it as a persistent native array within the job system and then read that native array from the MonoBehaviour layer.

You can also get a slice of a native array using array.GetSubArray. This doesn't create a copy but a reference to the data of the original array. So it should be a constant time operation, regardless of the length of the slice.

@Philipp Yeah, I mentioned that above too, but doing it mean I'll have to rewrite almost everything, so I'm trying to avoid it. But if it's the way, then that's that.

ooh, that GetSubArray() function looks helpful, I'll look into it.

@DMGregory Yeah, I've heard about that too, but it probably mean I'll have to learn some HLSL, won't it?

Like... maybe 12 lines of it? It would not be a large undertaking.

The more annoying thing is uploading the data to the GPU and reading it back if you need it CPU-side. May I ask what this reaction-diffusion system is being used for in your game?

@DMGregory here, this one: karlsims.com/rd.html

followed a tutorial by the coding train youtube.com/watch?v=BV9ny785UNc

That answers "what reaction-diffusion system are you using", but it does not answer the question I asked: "what are you using it for?" - ie. what gameplay experience outcome does it accomplish?

@DMGregory Uh, to be exact, nothing. I just do simulations with unity in my spare time.

probably shouldn't use unity, but oh well

Nah, I do the same. It makes a very flexible environment for trying out ideas and visualizing the work of algorithms.

That's potentially a good thing. If you don't care about reading the results of the R-D sim back to the CPU for doing gameplay interactions with them, then we can keep the whole sim GPU-side and it's easier/more efficient. 😉

But to get GPU answers, you'd need to edit your question from "Speed up... with Unity Job System" to just "Speed up..." and then answers using other speed-up strategies will be on-topic too.

@DMGregory Yeah, since I'm still in high school, I used to do CP. Got kicked out of the CP group after a while, got into unity but still found algorithms, especially graphical ones and simulations very interesting, so this is now my spare time hobby.

Yeah, good idea, i'll change the title later. Anyway thanks for the help!