Introduce BlockSize

[schnellerhase]

In performance critical parts some block sizes are optimized for by compiling explicit versions with the block size being provided as a compile time constant. At the same time general runtime block sizes are supported through an argument to these functions.

This causes

1. Code duplication: one path for the runtime and one for the compile time definitions of the block sizes, and
2. duplicate input of the block sizes: once as template argument once as argument (matching of both is only asserted does not raise in release due to performance impact)

Introduces a BlockSize concept that either holds a runtime int or a compile time std::integral_constant<int, bs> which allows to generate code paths explicitly for certain sizes, while maintaining a shared code path in both cases.

• form packing optimizes for block sizes 1,2,3 - vector assembly for 1,3: is this miss match intentional?
• matrix operation routines

[jhale]

Looks very nice. Could we review the basic approach before you spend lots more time on it?

[schnellerhase]

Sure thing. Should be good to go as is and can be extended further when approved. One neat byproduct, that these changes would allow for, are non compile time sized operations on the MatrixCSR which we are currently missing.

[chrisrichardson]

Looking good.

[garth-wells]

Looks really neat.

• Should the name be more generic, it's basically a runtime or templated integer. I can think of applications outside of block size, e.g. geometric dimension, where it could be useful.
• Should it support different integer types?
• Could tests be added to check that when it's a compile time integer that it really is a compiler time integer?

[schnellerhase]

For points 1 and 2 that should be no problem - how about: ConstexprType as name for the general concept?

Regarding 3: the interface to retrieve the value (here block_size) needs to be able to produce both a runtime value and a compile time value. Therefore it can not be marked constexpr. Testing for in lining of the compile time variant is also not straight forward as this remains in all cases a compiler decision. Best way to check for its effect, I assume, would be with a benchmark of those cases.

[garth-wells]

Regarding 3: the interface to retrieve the value (here block_size) needs to be able to produce both a runtime value and a compile time value. Therefore it can not be marked constexpr. Testing for in lining of the compile time variant is also not straight forward as this remains in all cases a compiler decision. Best way to check for its effect, I assume, would be with a benchmark of those cases.

I don't like relying on the compiler to inline things that we know are known at compile time. We have avoided this in the past and preferred being explicit over relying on the compiler and then not knowing what the compiler does.

[schnellerhase]

It would be best if the block_size/value function would be constexpr for the compile time case. I will try if I can recover that behaviour.

[schnellerhase]

It think I have a fix: value(ConxtexprType<T, V>) is now constexpr for is_compile_v<T, V> == True and otherwise not. The test case showcases that we can assert during compile time now. (Block size is not yet adapted).

[jhale]

I have reviewed the PR and the above discussion and all comments have been addressed.

[garth-wells]

I’d like to discuss this one more. Not quite convinced that it’s a simplification.

[garth-wells]

What's the point of passing BlockSize auto _bs if the implementation using int bs?

[schnellerhase]

It allows for inovocations with both a compile time block size, of std::integral_constant type, or a runtime one, of int type. In both cases however we then extract an integral block size bs which gets used for the computations.

[garth-wells]

My point is that int bs; isn't constexpr

[garth-wells]

This isn't constexpr, so we lose the compile-time 'const-ness'.

[schnellerhase]

We loose the constexpr int = ... version. However in the case of a compile time value the block_size callback has signature constexpr int block_size(). Meaning the compiler will see int bs = constexpr int.

[garth-wells]

The block size get assigned to the runtime int - it's not clear or guaranteed that the compiler can exploit that the block size is a compile time known.

[schnellerhase]

Type of the unpacked value is now changed to auto. Therefore the type is inferred from the return type of the block_size function, which is int for the runtime case and constexpr int for a compile time value.