this is more curiosity than anything else. Can RewindableAllocator be used for jobs and if so will be as good as tempjob or better?
#RewindableAllocator vs tempjob
gritty canopy
hexed notch
you should nearly always use RewindableAllocator over TempJob imo
gritty canopy
that's what I thought thanks. I wonder how many other new hidden gems there are
carmine folio
you should nearly always use RewindableAllocator over TempJob imo
Even for baking system? 🧐
sand skiff
no, there's nothing to rewind in a baker
hexed notch
Even for baking system? 🧐
i don't schedule many jobs in bakers
pliant anvil
They have different thread-of characteristics. You can check that in the allocator-benchmark.md file.
But in general, you should tend to prefer Temp for small allocation on the main thread (< 1kb). For everything else, Rewindable is faster and pretty much constant time.
gritty canopy
I am curious about the algorithm / strategy implementation and how it is different from tempjob
hexed notch
if you use a steady state of memory, you don't actually have to allocate anything with rewind allocator
it'll just re-use the previous (well 2 frames ago because there are 2) memory
gritty canopy
Ok so quite specialised strategies
hexed notch
there are 2 rewind allocators per world right, and they alternate (so they don't have to force complete jobs when they rewind)
and they re-use frequently requested memory
however if you do a giant rare allocation, it will clean it up in a few frames
gritty canopy
I was under the impression I had to instantiate the allocator somehow, how do I get it from a world ?
hexed notch
just from a user perspective, you don't have to dispose it so that's nice
hexed notch
I was under the impression I had to instantiate the allocator somehow, how do I ...
state.WorldUpdateAllocator
or just WorldUpdateAllocator from SystemBase
gritty canopy
Ah that's rewindable
hexed notch
/// <summary>
/// Retrieve the world update allocator of the World in which this system exists.
/// </summary>
/// <value>The Allocator retrieved.</value>
/// <remarks>Behind the world update allocator are double reewindable allocators, and the two allocators
/// are switched in each world update. Therefore user cannot cache the world update allocator.</remarks>
public Allocator WorldUpdateAllocator => m_WorldUnmanaged.UpdateAllocator.ToAllocator;```
```cs
/// <summary>
/// Rewindable allocator instance for this World.
/// </summary>
/// <remarks>Useful for fast, thread-safe temporary memory allocations which do not need to be explicitly disposed.
/// All allocations from this allocator are automatically disposed en masse after two full World updates. Behind
/// the world update allocator are double rewindable allocators, and the two allocators are switched in each world
/// update. Therefore user should not cache the world update allocator. </remarks>
public ref RewindableAllocator UpdateAllocator => ref GetImpl().DoubleUpdateAllocators->Allocator;```yeah it just provides a shortcut
pliant anvil
The RewindableAllocator is also preferred instead of using TempJob when it comes to Netcode (especially server), since it is cleanup differently and does not have the same issue of TempJob and the 4-frame log spam.
carmine folio
They have different thread-of characteristics. You can check that in the allocat...
I guess just use Rewindable for everything to make the life easier 👀
pliant anvil
There are cases when you want to use others 🙂 But for temp allocation, I would say it is almost a safe choice.
hexed notch
One thing I haven't but really need to do is compare temp with stack alloc
also while temp is fast, it still not free and there are many was to limit allocating it per thread instead of per entity, for example in IJobEntity you can use IJobEntityChunkBeginEnd
[NativeDisableContainerSafetyRestriction]
private NativeList<int> threadList;
public bool OnChunkBegin(in ArchetypeChunk chunk, int unfilteredChunkIndex, bool useEnabledMask, in v128 chunkEnabledMask)
{
if (!this.threadList.IsCreated)
{
this.threadList = new NativeList<int>(Allocator.Temp);
}
return true;```comparing this to allocator per entity it can be an enormous difference if you have large or a lot of entities
if you care about performance objective should still be to limit allocations to as few as possible
gritty canopy
falling in a mini rabbit hole here. If I want to use a custom allocator as Allocator paramater, do I have to register it first in the AllocatorManager?