feat(benches): add binaries to bench scaling of non-conflicting transactions

[imrn99]

Description

Scope: benches

Type of change: new feature

Content description:

add two binaries, shift and shift-nc. both programs generate a grid and iterate on inner vertices, computing the average of their neighbors and taking it as new value. this is repeated for N rounds.

the main loop is parallelized using rayon, the easiest way to control execution resource is to use taskset.

shift-nc differs from shift by splitting the vertices into to independent batches before processing those. the intended effect is to decouple iterations that could conflict with each other, resulting in no transaction falures and retries.

Additional information

• New dependency: rayon

Possible follow-up

• larger scale tests
• add parallelism to predefined kernels

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.97%. Comparing base (a924645) to head (cb24350).
Report is 4 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #240      +/-   ##
==========================================
- Coverage   79.21%   78.97%   -0.25%     
==========================================
  Files          52       52              
  Lines        6953     6834     -119     
==========================================
- Hits         5508     5397     -111     
+ Misses       1445     1437       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cedricchevalier19]

The two new programs are benchmarks, but what is the performance metric?

[imrn99]

The two new programs are benchmarks, but what is the performance metric?

The main metric of interest is execution time, to evaluate how well our implementation scales. Both weak and strong scaling can be estimated by controlling grid size and # of thread used.

We don't necessarily care about flat exec time since we don't have anything to compare against, and I'm not even sure the algorithm makes too much sense meshing-wise.

[imrn99]

As an indication, I'm reaching quasi ideal speedup for 1000 rounds on a 512*512 map, from 1 to 12 threads (from 92s down to 12s, given that map creation is not parallelized)