3 ms·

Since the article talks a bit about this part of DoD - plugging my C++ library for automatic conversion of AoS layout to SoA: https://github.com/celtera/ahsohto

Since the article talks a bit about this part of DoD - plugging my C++ library for automatic conversion of AoS layout to SoA: https://github.com/celtera/ahsohtoa https://github.com/celtera/ahsohtoa if it can be useful to anyone ; the entire code is pretty short and fully documented to explain the techniques used: https://github.com/celtera/ahsohtoa/blob/main/include/ahsohtoa/ahsohtoa.hpp https://github.com/celtera/ahsohtoa/blob/main/include/ahsoht...

tyleo 4y ago
Why not just write it as SoA to begin with? I think the library is cool. It’s cool that this can be done with C++ and it’s cool that someone did it. However, when considering something like this for production I always think, “folks will understand things better if they have to type it themselves and can _see_ the structure in the source code.” Are there real production uses for this or do you consider it a toy?
- klik99 4y ago
  I’ve been doing a lot of stuff in the UE4/5 Slate framework lately which uses a declarative construction syntax - the amount of boilerplate to enable the required declarative syntax is frustrating and would love to have it automatically done. But truthfully I’m not a fan of doing this kind of declarative DSL within c++, it’s just not a pleasant experience and would rather use yaml/toml or embedded lua for the data driven interface
- dgb23 4y ago
  I think that’s generally a good point. I guess the utility here is to have a clearer model of “this stuff belongs to this object”. Reminds me a bit of relational projections and views. But at the same time it goes against a principle in this paradigm, to program closer to the machine and the data layout.
- jcelerier 4y ago
  > Why not just write it as SoA to begin with? To give my personal reason: I have absolutely never managed to find SoA style code readable at all aha > folks will understand things better if they have to type it themselves I guess it comes down to if you work in a top-down or bottom-up way to create an understanding of a codebase. Generally, I start by looking at the class names to get a general idea of the architecture and make some mental diagrams of it, and then I zoom in to the level of detail needed. I know other people work better by reading individual functions and working upward from there but it's definitely not my case.
chrsig 4y ago
This definitely has my attention...I like that you parameterized the underlying storage. Dislike the dependency on boost :( Not having to have an extra code generation step is definitely nice though. The SoA -> AoS difficulty has driven me to julia for my personal projects, there's a library called StructArrays.jl[0] that is quite similar to your project here. [0] https://github.com/JuliaArrays/StructArrays.jl https://github.com/JuliaArrays/StructArrays.jl
- jcelerier 4y ago
  The dependency on boost is not mandatory: - Either you can use standalone PFR (it does not really change anything as it's almost exactly the same code, just outside of namespace boost) but apparently that is an issue ahah - Or you can lobby the committee to accept P1061 ; there's already a compiler implementation based on clang-12: https://github.com/ricejasonf/llvm-project/tree/ricejasonf/p1061 https://github.com/ricejasonf/llvm-project/tree/ricejasonf/p... With it, the code becomes even simpler and would not need PFR at all ; a function such as std::size_t create() { [&]<std::size_t... N>(std::index_sequence<N...>) { (std::get<N>(vec).push_back({}), ...); } (indices{}); return size() - 1; } just becomes std::size_t create() { auto& [... v] = vec; ((v.push_back({}), ...); return size() - 1; }

tyleo 4y ago

Why not just write it as SoA to begin with? I think the library is cool. It’s cool that this can be done with C++ and it’s cool that someone did it. However, when considering something like this for production I always think, “folks will understand things better if they have to type it themselves and can _see_ the structure in the source code.” Are there real production uses for this or do you consider it a toy?

klik99 4y ago
I’ve been doing a lot of stuff in the UE4/5 Slate framework lately which uses a declarative construction syntax - the amount of boilerplate to enable the required declarative syntax is frustrating and would love to have it automatically done. But truthfully I’m not a fan of doing this kind of declarative DSL within c++, it’s just not a pleasant experience and would rather use yaml/toml or embedded lua for the data driven interface
dgb23 4y ago
I think that’s generally a good point. I guess the utility here is to have a clearer model of “this stuff belongs to this object”. Reminds me a bit of relational projections and views. But at the same time it goes against a principle in this paradigm, to program closer to the machine and the data layout.
jcelerier 4y ago
> Why not just write it as SoA to begin with? To give my personal reason: I have absolutely never managed to find SoA style code readable at all aha > folks will understand things better if they have to type it themselves I guess it comes down to if you work in a top-down or bottom-up way to create an understanding of a codebase. Generally, I start by looking at the class names to get a general idea of the architecture and make some mental diagrams of it, and then I zoom in to the level of detail needed. I know other people work better by reading individual functions and working upward from there but it's definitely not my case.

chrsig 4y ago

This definitely has my attention...I like that you parameterized the underlying storage. Dislike the dependency on boost :( Not having to have an extra code generation step is definitely nice though. The SoA -> AoS difficulty has driven me to julia for my personal projects, there's a library called StructArrays.jl[0] that is quite similar to your project here. [0] https://github.com/JuliaArrays/StructArrays.jl https://github.com/JuliaArrays/StructArrays.jl

jcelerier 4y ago
The dependency on boost is not mandatory: - Either you can use standalone PFR (it does not really change anything as it's almost exactly the same code, just outside of namespace boost) but apparently that is an issue ahah - Or you can lobby the committee to accept P1061 ; there's already a compiler implementation based on clang-12: https://github.com/ricejasonf/llvm-project/tree/ricejasonf/p1061 https://github.com/ricejasonf/llvm-project/tree/ricejasonf/p... With it, the code becomes even simpler and would not need PFR at all ; a function such as std::size_t create() { [&]<std::size_t... N>(std::index_sequence<N...>) { (std::get<N>(vec).push_back({}), ...); } (indices{}); return size() - 1; } just becomes std::size_t create() { auto& [... v] = vec; ((v.push_back({}), ...); return size() - 1; }