Implementing panel-based matrix class

[Mikhail Katliar]

I am working on a proof-of-concept implementation of panel-based matrices using Blaze (see https://bitbucket.org/blaze-lib/blaze/issues/181/making-blaze-even-faster#comment-54174699). As suggested by @Klaus Iglberger , I create new matrix classesStaticPanelMatrixand DynamicPanelMatrix, which both derive from a common base PanelMatrix.

As I am not fully familiar with the implementation details of Blaze, I created this issue to ask questions. Here are my questions so far:

1. I am not sure whether PanelMatrix should derive from Matrix or from DenseMatrix. On the one hand, PanelMatrix is a matrix with dense storage, and all functions that are implemented for DenseMatrix in terms of element access operators should work the same way on a PanelMatrix. Re-implementing them for PanelMatrix would be too much work. On the other hand, DenseMatrix exposes the pointer to its data via the data() function, and the data layout of PanelMatrix is different from the one of StaticMatrix and DynamicMatrix. Functions that directly access matrix data will not work on PanelMatrix. For example, the BLAS functions accept DenseMatrix arguments, but obviously they will not work as intended on panel matrices. I wonder if similar problems can occur in other places (i.e. with iterators, with the use of SIMD operations likeload() and store() in the expression classes, with vectorized kernels etc.).

‌

[Klaus Iglberger]

Hi Misha!

The fact that you want to implement two different matrix classes (StaticPanelMatrix and DynamicPanelMatrix) suggest that you don’t want to implement a matrix type, but an adaptor. Please take a look at LowerMatrix to get an impression on the implementation of adaptors.

You are correct, you’ll have to overload all operations, that require data access (via data() or SIMD functions) since the behavior of the interface is different. Note that this includes all expressions (addition, subtraction, multiplication, reduction, inversion, …).

Best regards,

Klaus!

[Mikhail Katliar]

Q2. As a start, I copied the relevant parts of the StaticMatrix implementation to the new StaticPanelMatrix class. There are specializations of trait classes s.a. AddTraitEval2, SubTraitEval2 etc. in math/dense/StaticMatrix.h. As I understand, they define the resulting type of different matrix operations depending on the type of arguments. It looks somewhat like the following:

template< typename T1, typename T2 >
struct AddTraitEval2< T1, T2
                    , EnableIf_t< IsMatrix_v<T1> &&
                                  IsMatrix_v<T2> &&
                                  ( Size_v<T1,0UL> != DefaultSize_v ||
                                    Size_v<T2,0UL> != DefaultSize_v ) &&
                                  ( Size_v<T1,1UL> != DefaultSize_v ||
                                    Size_v<T2,1UL> != DefaultSize_v ) > >
{
   // ...
   using Type = StaticMatrix< AddTrait_t<ET1,ET2>, M, N, SO >;
};

As far as I understand, I need to define the same kind of specializations for StaticPanelMatrix. However, if StaticPanelMatrix is derived from Matrix and a specialization of Size<> for StaticPanelMatrix is defined properly, the AddTraitEval2` above will be enabled for both StaticMatrix and StaticPanelMatrix, leading to compiler error. I don’t see how I can specialize AddTraitEval2 for StaticPanelMatrix without changing the code above. I also don’t fully understand why the part of the EnableIf_t<…> expression looks like

( Size_v<T1,0UL> != DefaultSize_v ||
                                    Size_v<T2,0UL> != DefaultSize_v ) &&
                                  ( Size_v<T1,1UL> != DefaultSize_v ||
                                    Size_v<T2,1UL> != DefaultSize_v )

and not

IsStatic_v<T1> && IsStatic_v<T2>

?

[Mikhail Katliar]

Hello Klaus,

Regarding your comments on Q1. I have looked at the LowerMatrix code. Do I understand you correctly, that you suggest implementing a PanelMatrix adapter, which would adapt either StaticMatrix or DynamicMatrix? Would such adaptor inherit from DenseMatrix or something else?

As far as I can see, I will need to re-implement pretty much the same set of operations for an adaptor as for a matrix class. What is the advantage of the adaptor approach?

Best regards,

Misha

[Klaus Iglberger]

Hi Misha!

Q1) As you can see in <blaze/math/adaptors/lowermatrix/Dense.h> and <blaze/math/adaptors/lowermatrix/Sparse.h> it would be possible that a panel matrix is dense or sparse. For your purposes you should use DenseMatrix. The adaptor approach would build on the already existing data containers. From my current point of view a panel matrix would primarily store the elements in a different order than a regular matrix, but would require the same underlying memory (an array). Thus it appears like the adaptor approach can save you time an effort as you can build on the already existing matrix classes. An adaptor would allow you to focus on the special requirements.

Q2) Initially you would not have to worry about any trait specialization. The existing specializations will also work for any new matrix type. Thus I would recommend to focus on the more general problems first before dealing with the smaller details.

I expect that this endeavour will create a large amount of code and changes. For that reason I recommend that you consider to set up a Blaze project (see the list of projects on the main page). This would give you a lot of benefits, most importantly a bigger visibility. In this setting you would stay in control of the development and could try many different ways of implementation. You would be free to implement anything you want and you could introduce any changes.

Best regards,

Klaus!

[Mikhail Katliar]

Hello Klaus!

Thank you for your suggestions. It indeed looks more like a separate project. I am not sure how far it will go, but at the moment the idea of combining the performance advantages given by the panel format with template-based implementation looks promising to me.