Search Unity

Is AOSOA 'better' than SoA?

Discussion in 'Entity Component System' started by maikklein, Apr 2, 2018.

  1. maikklein

    maikklein

    Joined:
    Jun 16, 2015
    Posts:
    33


    Is AOSOA really efficient for iteration? For example let us say that we only are interested in the X component which is a float.

    Then we would have 4 floats which is 16 bytes, which is only 1/4 of a 64 byte cache line. Also now prefetching would actually also load components into memory that are never accessed.

    Of course if we now access X, Y and Z, and Y and Z are also floats, then we would load 48 bytes which is 3/4 of the cache line and we would only waste the H component.

    Compared to the "normal SoA" layout [XXXX XXXX XXXX.. YYYY YYYY YYYY.. ZZZZ ZZZZ ZZZ..], where this would be an optimal memory layout if the number of components would be low, otherwise, I assume, we could run into some prefetch issues.

    AOSOA seems useful if we iterate almost always over every component in an archetype. And SoA seems better if we have a high number of components per entity but only iterate over a few at a given time.

    Did I get something wrong?

    Is AOSOA the only supported layout?
     
    maikklein, Apr 2, 2018
    #1

  2. deplinenoise

    deplinenoise

    Unity Technologies

    Joined:
    Dec 20, 2017
    Posts:
    33
    Hi -

    Components are currently laid out in parallel arrays of ComponentData types. We don't move around the components inside your structs currently.

    What I was talking about was a research direction to start doing so, and also allowing your code to do so manually.

    You're right that there are different trade offs when doing so:

    * AOS is better when you're looking at a single, random element and you need all its attributes.
    * Pure SOA is great when you're reading only some streams, but is limited by the number of hardware prefetching streams on the hardware (something like 4-8 per core on most commodity hardware)
    * AOSOA is great when you have many attributes and you need most of them

    In practice we want to allow all these forms, and let users easily transition between them as much as possible.
     
    deplinenoise, Apr 2, 2018
    #2
    Cynicat and maikklein like this.

  3. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,338
    How are you planning on having that look in practice? Would this be different types (NativeSOA vs. NativeAOS), or would this be a setting on the container (new NativeArray<T>(size, StructLayout.AOSOA))?

    Or are we somehow specifying layout in code?
     
    Baste, Apr 3, 2018
    #3

  4. GabrieleUnity

    GabrieleUnity

    Unity Technologies

    Joined:
    Sep 4, 2012
    Posts:
    116
    @Baste We don't know yet what the final incarnation will be, but at the moment we are experimenting with NativeArraySoA. Basically, we want developers to just change from NativeArray to NativeArraySoA in their job code, and get everything else automatically transformed behind the scenes.
     
    GabrieleUnity, Apr 6, 2018
    #4