Decouple RegisterMatrix from Blaze #49
Conversation
…StorageOrder and fixed benchmarks
| @@ -12,17 +12,16 @@ | |||
|
|
|||
| namespace blast :: benchmark | |||
| { | |||
| template <typename T, size_t M, size_t N, bool SO> | |||
| template <typename T, size_t M, size_t N, StorageOrder SO> | |||
| static void BM_RegisterMatrix_ger_nt(State& state) | |||
| { | |||
| using Kernel = RegisterMatrix<T, M, N, SO>; | |||
There was a problem hiding this comment.
I only see this now, but technically a 'kernel' is the operation, i.e. dgemm, not the data you're operating on.
There was a problem hiding this comment.
True. This wording remains for histerical reasons.
|
|
||
| #pragma once | ||
|
|
||
| #include <blaze/math/StorageOrder.h> | ||
|
|
||
|
|
||
| namespace blast | ||
| { | ||
| enum StorageOrder : bool |
There was a problem hiding this comment.
bool? will there never be more StorageOrders than two?
There was a problem hiding this comment.
Good point. The StorageOrder term was borrowed from Blaze, where it meant only row-major or column-major. Now I think that it could be a more complex thing, that would include panel-based and possible other storages. It could be a class that defines how to calculate memory offset given row and column indices, similar to LayoutPolicy in std::mdspan. Then we would not need special classes for panel matrices, because the StorageOrder parameter of the matrix class would handle accessing the elements. Implementing it would also solve #6 . Doing it in one step though would be a too big change, so I just decoupled StorageOrder from Blaze for now.
Fixes #15