On Sunday, 27 March 2016 at 00:42:07 UTC, maik klein wrote:
I think SoA can be faster if you are commonly iterating over a
section of a dataset, but I don't think that's a common
occurrence.
This happens in games very often when you use inheritance, your
objects just will grow really big the more functionality you
add.
Like for example you just want to move all objects based on
velocity, so you just care about Position, Velocity. You don't
have to load anything else into memory.
An entity component system really is just SoA at its core.
You can't have a struct-of-arrays with polymorphic data like game
objects; the individual objects would have different properties
and methods.
If you use a Unity-esque component system, you could potentially
pool each object's component into an array... but then whatever
component updates you're running likely touch most of the object
state anyway (ex. the hypothetical PositionComponent would be
updating both its position and velocity).
Also I forgot to mention: Your "Isn’t SoA premature
optimization?" section is a textbook YAGNI violation. I might
have to refactor my web app to support running across multiple
servers and internationalization when it becomes the Next Big
Thing, but it more than likely will not become the Next Big
Thing, so it's not productive for me to add additional complexity
to "make sure my code scales" (and yes, SoA does add complexity,
even if you hide it with templates and methods).
Since AoS vs SoA is highly dependent on usage, I'd like to see
some performance metrics with real-world access patterns instead
of benchmarks that unrealistically only look at part of the data
at a time, or use structs that are too small to matter. Of
course, actually getting those metrics is the hard part...
