array of structures (AoS), structure of arrays (SoA) or array of structures of arrays (AoSoA) are contrasting ways to arrange a sequence of records in memory, with regard to interleaving, and are of interest in SIMD and SIMT programming.
I found this article to be strangely interesting. Coming from object oriented programming, I tend to think about objects as independent, self-contained instances, even if they are ultimately stored in a container. However, once we take padding into account, the overhead of storing objects in an array can potentially become something worth to keep in mind.
I have worked with and build a SoA system. I quite like it.
I worked with one written in C++ where your objects were represented by small reference structs and you access all of the real members via static methods. It was done to improve cache access times as often you iterate over a large number of objects but read only a single property (say only the position) of each object. I don’t know how big a performance improvement this actually is, as we don’t have a feature-parity version of AoS lying around. But taken by itself the SoA does not feel less comfortable to work with. Though we make heavy use of a code-generator to not write getter/setter boilerplate.
GPU-programmers are the expert in AoS vs SoA formats. And when you look at how RGB values are stored, its… incredibly complex. Sometimes you’ve got RRRRGGGGBBBB, sometimes its RGBARGBARGBA, sometimes its YYYYUUVV. What’s best for performance changes dramatically on system-to-system, requiring lots of benchmarking and ultimately… a massive slew of processor-specific / ARM NEON instructions that convert between every format imaginable.
On right, GPUs don’t need that processor-specific instruction because permute and bpermute instructions exist (32-way crossbar any data-to-any-lane movement, and vice versa any lane pulling from any data, permute and bpermute respectively). CPUs do need it though.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
I found this article to be strangely interesting. Coming from object oriented programming, I tend to think about objects as independent, self-contained instances, even if they are ultimately stored in a container. However, once we take padding into account, the overhead of storing objects in an array can potentially become something worth to keep in mind.
I have worked with and build a SoA system. I quite like it. I worked with one written in C++ where your objects were represented by small reference structs and you access all of the real members via static methods. It was done to improve cache access times as often you iterate over a large number of objects but read only a single property (say only the position) of each object. I don’t know how big a performance improvement this actually is, as we don’t have a feature-parity version of AoS lying around. But taken by itself the SoA does not feel less comfortable to work with. Though we make heavy use of a code-generator to not write getter/setter boilerplate.
Its not so easy.
GPU-programmers are the expert in AoS vs SoA formats. And when you look at how RGB values are stored, its… incredibly complex. Sometimes you’ve got RRRRGGGGBBBB, sometimes its RGBARGBARGBA, sometimes its YYYYUUVV. What’s best for performance changes dramatically on system-to-system, requiring lots of benchmarking and ultimately… a massive slew of processor-specific / ARM NEON instructions that convert between every format imaginable.
On right, GPUs don’t need that processor-specific instruction because permute and bpermute instructions exist (32-way crossbar any data-to-any-lane movement, and vice versa any lane pulling from any data, permute and bpermute respectively). CPUs do need it though.