Benchmark work estimate

[upsj]

This PR adds work estimates to the executor Operations, implements them for a few Dense kernels and outputs them in benchmark loggers.

[sonarqubecloud[bot]]

SonarCloud Quality Gate failed.

2 Bugs
0 Vulnerabilities
0 Security Hotspots
31 Code Smells

2.3% Coverage
6.5% Duplication

[codecov[bot]]

Codecov Report

Merging #802 (2e1aa39) into develop (621f991) will increase coverage by 3.68%. The diff coverage is 21.05%.

:exclamation: Current head 2e1aa39 differs from pull request most recent head dea9c36. Consider uploading reports for the commit dea9c36 to get more accurate results

@@             Coverage Diff             @@
##           develop     #802      +/-   ##
===========================================
+ Coverage    90.50%   94.19%   +3.68%     
===========================================
  Files          505      401     -104     
  Lines        43856    32156   -11700     
===========================================
- Hits         39693    30289    -9404     
+ Misses        4163     1867    -2296     

Impacted Files	Coverage Δ
core/matrix/dense_kernels.hpp	0.00% <0.00%> (ø)
include/ginkgo/core/base/executor.hpp	78.64% <0.00%> (+5.96%)	:arrow_up:
core/matrix/dense.cpp	99.51% <100.00%> (+6.16%)	:arrow_up:
core/factorization/ilu.cpp	0.00% <0.00%> (-100.00%)	:arrow_down:
reference/factorization/ic_kernels.cpp	0.00% <0.00%> (-100.00%)	:arrow_down:
reference/factorization/ilu_kernels.cpp	0.00% <0.00%> (-100.00%)	:arrow_down:
include/ginkgo/core/factorization/ilu.hpp	0.00% <0.00%> (-100.00%)	:arrow_down:
core/factorization/ic.cpp	0.00% <0.00%> (-96.88%)	:arrow_down:
include/ginkgo/core/factorization/ic.hpp	0.00% <0.00%> (-93.34%)	:arrow_down:
omp/matrix/fbcsr_kernels.cpp	0.00% <0.00%> (-57.54%)	:arrow_down:
... and 404 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[tcojean]

I think one limit with this technic if I understand properly is that it requires two consistencies:

1. All executors will have a similar implementation so that they have the same work estimates
2. Every operation is tied to only one kernel.

I'm not sure about 1. for now, I think most of our algorithms have roughly the same order of magnitude of work between executors, but that means a design like the CSR SpMV (classical, imbalance, ...) with strategies would be a no go, and instead we would need an operation for each strategy and switch strategy at the core/algorithm level (which is maybe the best thing to do anyway).

I don't think it's a downside, I thought I should just mention it.

[ginkgo-bot]

Note: This PR changes the Ginkgo ABI:

Functions changes summary: 0 Removed, 0 Changed, 253 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

For details check the full ABI diff under Artifacts here