NativeHashMap

Hi!
I've seen some mentions of this collection, is it available already or will it come later? Cause I can use NativeArray but I can't seem to find NativeHashMap and I could use it for my job code (which btw works really great so far, I love IJobParallelFor).

 

Great, thanks for the quick reply. I have one other kind of related problem I am trying to wrap my head around. I have a struct that has an array as a member. And I'd like to use it inside of the job code, but I get an error that the struct must be blittable. Do you know any smart way to make a struct with an array blittable? I know I won't have more than 100 elements in it, so I'd be happy with making it fixed 100 element array or something like this. The only way I've found so far is pretty ugly (making a struct with 100 element and overriding indexer operator to fake being an array).

 

In case anyone needs something similar: here's my hundred element struct that pretends to be an array

 

Out curiosity Martin, if we wanted to use a NativeArray of a struct, but the struct requires an array within it, would we need to wait for other Native container types coming with the ECS? The largest issue is that NativeArray<T> isn't blittable even if the 'T' type is blittable.

Example:

Code (CSharp):

1. public struct TestingStruct {
2.     public NativeArray<byte> Bytes; //Alternatively byte[] failed as well
3. }
4.  
5. private struct JTest : IJob {
6.         public NativeArray<TestingStruct> Data;
7.         public void Execute() {}
8. }

 

You are basically asking what I've already asked in the same topic ;p

 

It was more in case it wasn't exactly what you needed. My reading has been greatly impaired via playing around with Job Systems keeping me up every night. Also to be fair Martin did say "tomorrow" about a week ago

 

You are right, I was talking about a different thing, I've just misunderstood your post.

 

@MartingGram - any update about an array inside a struct?

 

I did not, thanks! I'll try it tomorrow and I'll see if it helps.

 

I would vote for new containers to be somewhat as elegant in design as Span<T> if possible. I realize it's very early, but really NativeArray needs to die in a fire at some point.

 

What's confusing is how the underlying data is managed in relation to NativeArray itself. The allocation options make things even fuzzier. Does it really behave like a value type should? The strong implication is that it doesn't just by looking at the api.

Span<T> on the other hand is very clear and works as you would expect.

Naming is I think unfortunate but more of a minor issue. Is it a buffer or an array? doesn't look like either to me really. If it's really a value type then 'Native' just adds to the confusion.

Slicing a minor thing also, but why a separate type for that?

 

Span<T> is a value type

 

To elaborate, what makes Span<T> much simpler to reason about is that like NativeArray it's an abstraction over memory, but it has a clear scope, it's a value type and acts like one. I don't have to think about the scope of the struct and the memory of the data it contains separately, nor reason about tmp vs non temp allocations or job vs non job scope. Or have to call dispose.

 

Reading the Span<T> documentation and this blog post:

• Span is an abstraction of memory (could be multiple partial blocks in mixed allocations).
  • NativeArray is a HANDLE to memory. Copying the struct copies the handle.
  • Calling Dispose releases the handle, and the memory pointed to is no longer valid.
  • This is more like C/C++ manual allocations than anything else, which is sometimes just what you need.
• Span isn't necessarily contingous, or allocated as such (it can treat different allocations as one single mapping).
  • For performance reasons, NativeArray is a straitforward allocated block of memory meant to play nice with CPU Caches.
  • It's likely the other Native* structures will have all of their allocations nearby or in allocated in contiguous arenas.
• Span doesn't seem threading safe, and is intended to operate on a single thread, and has no builtin protection against struct slicing. Span has a different implementation for readonly data.
  • NativeArray is read safe if marked as such in the job system.
  • NativeArray is write safe if marked as such on the job system.
• Span will have "fast" and "slow" implementations on different platforms.
  • NativeArray<T> probably isn't going to change much on the Managed level between any platforms, outside of the C++ generated around it's usage by the burst compiler (different platforms may have different SIMD/specialized intrinsics).
• Since Span is stack only, you cannot store it in a field and maintain the memory block, it also has no control over the lifecycle of the memory it represents.
  • NativeArray gives me all the control over the memory it represents.
  • I can even avoid the cost of setting the block allocation to zero if I'm just going to overwrite it immediately using the NativeArrayOptions enum.
  • There is a type that can do this proposed for .NET and intended to work with Span<T>. It's called Memory<T>, and it looks like it behaves more like NativeArray<T>, and less like Span<T>.

TLDR;
Span<T> is the wrong abstraction to be comparing to NativeArray<T> (which is optimized for it's intended purpose, being hyper-cache friendly and can be optimized/protected to work cleanly across threads via dependency checks), but Memory<T> is an API that solves a similar problem to NativeArray<T>, and lo-and-behold has similar behaviour (also a struct with pointers in it that can be manually disposed).

One more thing:
All of the above types are basically brand-new/in-preview (including the Native* from Unity), and Span<T>/Memory<T> in particular require C# 7.2 (even if we can get C# 7 with Unity soon-ish, there will always be some lag time, and NativeArray implementations can be controlled by Unity, platform implementations of Span<T> and Memory<T> may have issues that require someone else to fix since they're also new types themselves).