Support for specifying padding (leading dimersion) as third template argument to array_view

Jan 11, 2015 at 8:38 PM
Edited Jan 11, 2015 at 8:38 PM
Hi!

Thank you for your hard work on this. I saw Łukasz Mendakiewicz talk at CppCon 2014 on
youtube and I am really excited to see where array_view is going.

I am just wondering if you have considered accepting an additional template argument
to array view to describe padding? Something along the lines of:
    template <typename ValueType, int Rank = 1, int Pad = 0>
    class array_view : public details::any_array_view_base<ValueType, Rank, Pad>
this is important for interoperability with e.g. BLAS (cf. dgemm signature for example)
and LAPACK since most functions accept a "leading dimension" argument (which would be nrows+pad for a Column Major matrix for example and ncols+pad for a Row Major matrix respectively).

The possibilty to pad is also a feature even when disregarding Fortran interoperability
due to possible performance gain from cache alignment.

I have written a home grown object like array_view (although not nearly as rich in features
as yours) but there I opt:ed to templatize on both "padding" and memory layout ColMajor/RowMajor.

I just wanted to share my thoughts, I hope it's not disruptive to your work.

Best regards,
/Björn Dahlgren
Coordinator
Jan 18, 2015 at 6:50 PM
Hello Björn,
Thank you for your kind words!

Adding a parameterized padding to array_view is a sound idea which I agree would be useful in some fields. Alas we have intentionally decided to limit the scope of the proposed array_view to the bare minimum in order to get it standardized as frictionless as possible. We tried hard though to make the default functionality and semantics sane and amenable to the majority of programmers, while not limiting future extensions through additional template parameters (which would have default values enabling the behavior of the initial proposal -- exactly like you suggested with "Pad"). If the proposal goes through the standardization in the current form, I would encourage you to consider submitting a follow-up paper with the extensions you have outlined -- especially since you have the practical experience with a similar concept.

Please also note that strided_array_view is a more versatile counterpart to array_view, although with some runtime cost (as the parameterization is runtime as opposed to compile-time). It can however be used as a stopgap measure when interfacing with external components using different data layout as long as such processing does not happen in the "hot loop". It is expressive enough to cover not only padded but also transposed structures. I do not know however how would the cost of the flexibility compare with the benefit of cache alignment in the other scenario you mention.

Thank you again for your feedback!

Cheers,
Łukasz Mendakiewicz