3 ms·

Interest in SOA is bringing to mind the “art of the meta object protocol” which argues for a stage between class definition and implementation that would allow

Interest in SOA is bringing to mind the “art of the meta object protocol” which argues for a stage between class definition and implementation that would allow you to choose the layout and access method for instances of a class.

deleted 1y ago
[deleted]
corysama 1y ago
Yep. We’re in a situation where C-like languages couple layout and access interface very tightly. But, now cache is such an overriding issue in optimization, you really want to rapidly experiment with different layouts without rewriting your whole algorithm every time. AOS, SOA, AOSOA, hot/cold data for different stages, etc… Jon Blow’s Jai language famously added a feature to references that allowed you to easily experiment with moving data members between hot/cold arrays of structs. https://halide-lang.org/ https://halide-lang.org/ tackles a related problem. It decouples the math to be done from the access order so as to allow you to rapidly test looping over data in complicated ways to achieve cache-friendly access patterns for your specific hardware target without rewriting your whole core loop every time. Halide is primarily an about image processing convolution kernels. I’m not sure how general purpose it can get.
- tialaramex 1y ago
  AIUI Jai no longer has that SOA versus AOS functionality which Jon was very proud of when he invented it, I expect it's one of those "hot idea" things where for one week it seems as though this is a breakthrough with applications everywhere and then a week later you realise it was not as fundamental and you were just seeing applications everywhere due to recency illusion. The week after I first saw a Bloom Filter I imagined lots of places this would surely be great, in the decades since I probably have one bona fide use for a Bloom Filter per year, maybe less.
  - monkeyelite 1y ago
    Exactly. The SOA thing makes sense in so few cases - usually the one big data type your program operates on.
- jayd16 1y ago
  I suppose something like this would be considered a violation of OOO... That said Java might be able to naturally decompose record types into SoA collections without a big lift. Same for C# struct. You might even be able to access views types that still code like objects but point to the backing fields in the SoA collection.
mpweiher 1y ago
Yep. Objective-S[1] takes the ideas of "the art of the metaobject protocol" and expands on them...using software architectural principles [2]. One early result was the idea of storage combinators[3], and with those, AoS/SoA pretty much just falls out. Storage Combinators are basically an interface for data. Any kind of data, so generalized a bit from the variations of "instances of a class" that you get in CLOS's MOP. If you code against that interface, it doesn't matter how your data is actually stored: objects, dictionaries, computed on-demand, environment variables, files, http servers, whatever. And the "combinator" part means that these can be stacked/combined. While you can do this using a library, and a lot is in fact just implemented in libraries, you need the language support so that things like objects/structs/variables can be accessed quickly using this mechanism. SoA storage for tables has been on the list of things to do for a long time. I just started to work on some table ideas, so might actually get around to it Real Soon Now™. Currently I am working on other aspects of the table abstraction, so for example just integrated query, so I ca write the following: invoices[{Amount>30}] And have that query work the same against an array of objects (also a kind of table) and a SQL database. [1] https://objective.st/ https://objective.st/ [2] https://dl.acm.org/doi/10.1145/3689492.3690052 https://dl.acm.org/doi/10.1145/3689492.3690052 [3] https://2019.splashcon.org/details/splash-2019-Onward-papers/7/Storage-Combinators https://2019.splashcon.org/details/splash-2019-Onward-papers...

deleted 1y ago

[deleted]

corysama 1y ago

Yep. We’re in a situation where C-like languages couple layout and access interface very tightly. But, now cache is such an overriding issue in optimization, you really want to rapidly experiment with different layouts without rewriting your whole algorithm every time. AOS, SOA, AOSOA, hot/cold data for different stages, etc… Jon Blow’s Jai language famously added a feature to references that allowed you to easily experiment with moving data members between hot/cold arrays of structs. https://halide-lang.org/ https://halide-lang.org/ tackles a related problem. It decouples the math to be done from the access order so as to allow you to rapidly test looping over data in complicated ways to achieve cache-friendly access patterns for your specific hardware target without rewriting your whole core loop every time. Halide is primarily an about image processing convolution kernels. I’m not sure how general purpose it can get.

tialaramex 1y ago
AIUI Jai no longer has that SOA versus AOS functionality which Jon was very proud of when he invented it, I expect it's one of those "hot idea" things where for one week it seems as though this is a breakthrough with applications everywhere and then a week later you realise it was not as fundamental and you were just seeing applications everywhere due to recency illusion. The week after I first saw a Bloom Filter I imagined lots of places this would surely be great, in the decades since I probably have one bona fide use for a Bloom Filter per year, maybe less.
- monkeyelite 1y ago
  Exactly. The SOA thing makes sense in so few cases - usually the one big data type your program operates on.
jayd16 1y ago
I suppose something like this would be considered a violation of OOO... That said Java might be able to naturally decompose record types into SoA collections without a big lift. Same for C# struct. You might even be able to access views types that still code like objects but point to the backing fields in the SoA collection.

mpweiher 1y ago

Yep. Objective-S[1] takes the ideas of "the art of the metaobject protocol" and expands on them...using software architectural principles [2]. One early result was the idea of storage combinators[3], and with those, AoS/SoA pretty much just falls out. Storage Combinators are basically an interface for data. Any kind of data, so generalized a bit from the variations of "instances of a class" that you get in CLOS's MOP. If you code against that interface, it doesn't matter how your data is actually stored: objects, dictionaries, computed on-demand, environment variables, files, http servers, whatever. And the "combinator" part means that these can be stacked/combined. While you can do this using a library, and a lot is in fact just implemented in libraries, you need the language support so that things like objects/structs/variables can be accessed quickly using this mechanism. SoA storage for tables has been on the list of things to do for a long time. I just started to work on some table ideas, so might actually get around to it Real Soon Now™. Currently I am working on other aspects of the table abstraction, so for example just integrated query, so I ca write the following: invoices[{Amount>30}] And have that query work the same against an array of objects (also a kind of table) and a SQL database. [1] https://objective.st/ https://objective.st/ [2] https://dl.acm.org/doi/10.1145/3689492.3690052 https://dl.acm.org/doi/10.1145/3689492.3690052 [3] https://2019.splashcon.org/details/splash-2019-Onward-papers/7/Storage-Combinators https://2019.splashcon.org/details/splash-2019-Onward-papers...