3 ms·
Related to this is the concept of arrays of structures (AoS) vs. structures of arrays (SoA). Do you store all of the data that makes up one "object" in a single
by lispit 11y ago
Related to this is the concept of arrays of structures (AoS) vs. structures of arrays (SoA). Do you store all of the data that makes up one "object" in a single data structure, or do you store all of each "member" of each object in separate flat arrays?
If you need to use all of the "members" of an "object" at once, AoS is more efficient. But if you only need to use 1 or 2 members for a certain task, you will waste lots of memory bandwidth on data that isn't needed for the current operation. In this case, an SoA layout can improve your performance by an order of magnitude, by insuring that only the data that is actually necessary for your task is loaded into cache.
The same principle applies to row vs. column-oriented databases, which obviously are orders of magnitude more sensitive to IO bandwidth usage.
One of the most damning criticisms of OOP, from this perspective, is that it encourages you to wrap up lots of potentially unnecessary data into monolithic "objects" without concern to memory layout or usage patterns, giving you AoS and bloated data structures.
- jofer 11y agoGood points. However, object oriented programming doesn't necessarily mean arrays of objects. I'd disagree that it encourages it in any way. I realize that's a common paradigm in Java and C++, but it's an architectural decision that you make, not a part of a programming paradigm. The array-of-structs prevalence really stems from C, not object-oriented approaches. You can do both in a object-oriented manner. For example: points = Points(xarray, yarray, zarray) vs points = [Point(x0, y0, z0), Point(x1, y1, z1), ...] If you're mostly operating on a series, it makes more sense to structure objects and methods around the former "plural" approach, anyway.
- colanderman 11y agoI've always wished for a language that would just let me describe my data logically as a SQL-esque relation, while specifying separately its physical layout (incl. AoS vs. SoA). Tying logical flow to physical storage layout always seemed kinda clunky to me.