[cudadev] Macro based SoA (followup of #PR211)

[ericcano]

This PR follows up and replaces #211. Its goal is to implement #281.

The current status of SoA (with future plans) is described in SoA.md

[ericcano]

@fwyzard, @makortel, this version does not contain all the intended features, but could be considered for merging into master.

The missing features I intend to cover later are:

• Eigen support. This probably will require templating the way we describe columns in views, and I did not figure it out yet, and will probably require quite from testing, as this is macro-generated code. I also intend to make the inclusion of Eigen headers optional if Eigen columns are not used.
• Convert the dump member function into an operator<<.

I tried merging with the current master and this compiles and runs fine.

[fwyzard]

A silly thing: could you run it all through clang-format ?

[fwyzard]

Why is this "derived" from DeviceView and not from DeviceLayout ?

[ericcano]

The "idea" was that the class has its mutable view internally for initialization, and then down grades it to a const view for usage by the user in member function view(). Both path are possible, but we need to use the type we will pass to the constructor. The "hard work" is in the layout constructor, and in both cases, we're copying pointers (and the compiler will optimize this copying things out).

That makes the name of the SOA_VIEW_LAYOUT_LIST macro too restrictive, maybe. What about SOA_VIEW_DATA_SOURCE_LIST (and accordingly for SOA_VIEW_LAYOUT)?

[ericcano]

@VinInn, you might be interested too, especially in this commit: 87d084a, which adds automatic support to __restrict__ hinting for the compiler.

[fwyzard]

can this be simplified using GENERATE_SOA_LAYOUT_VIEW_AND_CONST_VIEW ?

[ericcano]

Indeed, this code predates the introduction of this utility macro.

[fwyzard]

why out_of_range for an alignment error ?

[ericcano]

I did not find a perfect match in std::exceptions and felt this could be the closest (maybe std::length_error ? ). Otherwise, we could just create our own exceptions, but we mostly rely on std:: ones, don't we?

[fwyzard]

I'd go with a generic std::runtime_error.

[fwyzard]

what happens if byteAlignment is not a multiple of sizeof(CPP_TYPE::Scalar) ?
what happens if byteAlignment is less than sizeof(CPP_TYPE::Scalar) ?

[ericcano]

Indeed, bad things might happen. Usual values are powers of 2 and a typical byte alignment is bigger than a built-in scalar, but this is not guaranteed. I think asserting (compile-time) that both sizeof(CPP_TYPE::Scalar) and byteAlignment are powers of 2 and aligning the columns to the biggest of the two should forbid any unwanted scenario while remaining a reasonable constraint on the parameters.

[fwyzard]

The alignment must always be a power of 2.
The size of a type can be anything, but c++ (almost) mandates that it is a multiple of its own alignment.

But "scalar" in this context does not necessarily mean a primitive type - it could also be an aggregate like class or an array (e.g. char name[1024]).
Then the stride becomes 0, which I don't think is the intended behaviour ? (no it doesn't, it becomes nElements_)
If sizeof(CPP_TYPE::Scalar) is greater that the alignment, the stride should just be nElements_ * sizeof(CPP_TYPE::Scalar) .

[fwyzard]

Actually, shouldn't the stride simply be (((nElements_ * sizeof(CPP_TYPE::Scalar) - 1) / byteAlignment) + 1) * byteAlignment, without the / sizeof(CPP_TYPE::Scalar) part ?

[fwyzard]

Here are some ideas after reading most of the PR and the discussions of the past couple of days.

My understanding is that the basic SoA-based structure would look similar to

// define the SoALayout and SoAView types
GENERATE_SOA_LAYOUT_VIEW_AND_CONST_VIEW(
    SoALayoutTemplate,
    SoAViewTemplate,
    SoAConstViewTemplate,
    ...
);

using SoALayout = SoALayoutTemplate<>;
using SoAView = SoAViewTemplate<>;

class SoA {
public:
  SoA(size_t size) :
    storage_{std::make_unique_ptr<std::byte[]>(SoALayout::computeDataSize(size))},
    layout_{storage_.get(), size)},
    view_{layout_}
  {}

  SoAView view() { return view_; }  // return by value or by reference ?
  SoAConstView view() const { return const_view(); }
  SoAConstView const_view() const { return SoAConstView(layout_); }  // can we create the const view from the view instead ?

private:
  std::unique_ptr<std::byte[]> storage_;  // use a different storage type for GPUs, etc.
  SoALayout layout_;
  SoAView view_;
};

Then, I would have suggestions to simplify the usage.

Make the View and ConstView nested types of the Layout, and always declare them

```c++
// define the SoALayout and SoAView types
GENERATE_SOA_LAYOUT(
    SoALayoutTemplate,
    ...
);

would always generate

• SoALayoutTemplate<...>
• SoALayoutTemplate<...>::View
• SoALayoutTemplate<...>::ConstView

and

using SoALayout = SoALayoutTemplate<>;

would give

• SoALayout
• SoALayout::View
• SoALayout::ConstView

Make the view a data member of the layout

If I understood correctly the content of the Layout and View types, the former is a superset of the latter.
Then we could simplify the Layout type by making it own a View data member, instead of duplicating those fields ?

So the SoALayoutTemplate<...> template would have a SoALayoutTemplate<...>::View view_; data member instead of the individual pointers.
It should also have the view(), view() const and const_view() const methods to return a View and ConstView

---

With these two changes, the example above would become

// define the SoALayout and SoAView types
GENERATE_SOA_LAYOUT(SoALayoutTemplate,
    ...
);

using SoALayout = SoALayoutTemplate<>;

class SoA {
public:
  SoA(size_t size) :
    storage_{std::make_unique_ptr<std::byte[]>(SoALayout::computeDataSize(size))},
    layout_{storage_.get(), size)}
  {}

  // return by value or by reference ?
  SoAView view() { return layout.view(); }
  SoAConstView view() const { return layout.const_view(); }
  SoAConstView const_view() const { return layout.const_view();; }

private:
  std::unique_ptr<std::byte[]> storage_;  // use a different storage type for GPUs, etc.
  SoALayout layout_;
};

[ericcano]

I attempted to achieve this, but failed in the current 2 classes model as the View is defined from the metadata of the Layout (column type are deduced from the metadata of the source layout/views). Instantiating the View early enough to be used inside the Layout

This schema can be achieved nevertheless if we create a third type of generated class (Trivial_view?) where the types of columns are directly generated, like for the Layout. It will be used like the View but generated in a different way.