#has NativeParallelMultiHashMap been
wispy relic
The key change was *Unsafe/NativeHashMap/Set suitable for single-threaded use cases. from the changelog
The original naming of the containers made our parallel ready container the common case. This meant single-threaded use cases had an unnecessary overhead.
To fix this we've renamed the parallel containers to be NativeParallelxxxxx to better signal this.
limpid glade
ok thanks for clearing that up
wispy relic
no problemo
rocky prism
ah i did wonder about using parallel containers in single threaded jobs
so it's now separate, parallel or not
limpid glade
but does that mean there's no multi version suitable for parallel anymore?
rocky prism
depending on use case
limpid glade
beause i'm only seeing
NativeHashMap
NativeParallelHashMap
NativeMultiHashMap
errant timber
i'm confused even after the explanation 🙂
ripe goblet
So tldr is that there are separate types for single-threaded and parallel use cases?
limpid glade
i'm confused even after the explanation 🙂
if take a look at source the Parallel versions always had this giant
internal fixed int firstFreeTLS[JobsUtility.MaxJobThreadCount * IntsPerCacheLine];```allocation you had to do
to provide support for threads
so you'd have to do a 2KB allocation for a 1 capacity map
errant timber
what i mean is, where's NativeParallelMultiHashMap
is it not needed anymore?
NativeMultiHashMap has a parallel writer
but why is this different to NativeHashMap and NativeParallelHashMap
limpid glade
hmm looking at implementation atm, HashMapHelper is quite different
limpid glade
is it not needed anymore?
looking at source
NativeMultiHashMap
still uses
UnsafeMultiHashMap
which still uses
UnsafeParallelHashMapData
so it doesn't seem updated yet
so NativeMultiHashMap still behaves like NativeParallelMultiHashMap
only NativeHashMap has been updated to new api so far