#Per-entity stacks

1 messages · Page 1 of 1 (latest)

rich nymph
#

Hello, I have a very quick question regarding DOTS and optimization:

I wish for most of my entities to hold their own individual (multiple) stacks for storing certain data. What'd be the best datastructure in DOTS for this - DynamicBuffer, or is there perhaps a better option? Could it still be easily parallelised with Jobs, if they had to access the top of multiple of these stacks simultaneously?

Also, what's generally the overhead associated with Dynamic buffers (or the other alternatives), especially when it comes to the size the structure uses (in bytes) and the processing power required to perform operations on them - popping or pushing (assume that most of them will be updated nearly every frame).

Thanks to anyone who answers. Please, ping me if you respond.

coral vortex
# rich nymph Hello, I have a very quick question regarding DOTS and optimization: I wish for...

if they had to access the top of multiple of these stacks simultaneously?

They key element is read and write access, as with anything in dots; read access to the same buffer can be parallelized, but write access is by default exclusive and cannot be parallelized (you can disable the safety system, but you should really know what you are doing in that case). There are parallel containers for concurrent access cases that are sometimes useful (NativeStream in particular is good for parallel writing).

Dynamic buffers have very low overhead (I assume similar to regular containers, but I have not directly compared them); however to me their main advantage is not having to do manual cleanup that would come with putting native/unsafe containers in components.

Note that for chunk size it may be important to apply the attribute [InternalBufferCapacity(NumItemsInChunk)] to the buffer component, which defines the fixed size of the buffer in the chunk (most of the time I set this to 0, but there are some exceptions). By default this value is equivalent to 128 bytes (whereas, iirc, the dynamic buffer is 16 only bytes on its own).

rich nymph
# coral vortex > if they had to access the top of multiple of these stacks simultaneously? The...

Thank you very much!

The use-case I have in mind is to Record and Replay data of select Entities, both of which are mutually exclusive (either Recording or Replaying), so there shouldn't be any situation in which a race conditions would appear (unless some aspect of how jobs/dots function doesn't allow it).

So, for the given frame, the job either pops (at maximum) one element from those stacks or pushes one element onto them (again at maximum). So, I just need a Stack data structure that's lightweight (due to pop/push operations happening often) and doesn't have much overhead for storing the elements (for instance, in C/C++ you can implement it using a linked list, but then you're wasting 4+ bytes for the pointers - not that DOTS would use pointers like this, but it can have some helper structures that take extra space).
The reason is for the memory concerns is that I will be storing relatively small data types on the Stacks (Possibly 1-2 bytes in size), so I wouldn't want the overhead of the datastructure out-weight the actual data stored there.

It would be the final system after all others have finished, where a Job is scheduled in parallel on the tracked entities (the data that is Recorded is contained/calculated from their own Component data), so again in theory it seems that each Entity should be isolated and easily parallelized.

coral vortex
#

Push/pop at the end of an array is very cheap, I'm guessing it will be cheaper than a linked list actually. I think linked lists are kind of niche

If you can guarantee you aren't writing to or reading from the lists elsewhere while writing to them, you can disable the safety system for those component lookups

#

Or if the entities only look at themselves you can just use an IJobEntity and there's nothing to do but write your logic

coral vortex