runtime: swap im for imbl in StakesCache

[2501babe]

Problem

stakes cache is a bottleneck

Summary of Changes

replace im with imbl. the former has not been updated for years, the latter is a backwards-compat fork that is presently maintained and more optimized

in #10760 i add some very simple benches for epoch rewards and advancing the epoch. if they are to be believed, this speeds rewards up by 10% and epoch advance by 30%

before:

test bench_epoch_rewards_period ... bench: 352,109,145.90 ns/iter (+/- 56,468,574.76)
test bench_epoch_turnover       ... bench:  15,555,461.00 ns/iter (+/- 2,037,170.53

after:

test bench_epoch_rewards_period ... bench: 310,888,743.00 ns/iter (+/- 53,842,063.38)
test bench_epoch_turnover       ... bench:  10,845,295.30 ns/iter (+/- 1,171,299.93)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.1%. Comparing base (82f55d7) to head (1d35234).

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #10762   +/-   ##
=======================================
  Coverage    83.1%    83.1%           
=======================================
  Files         858      858           
  Lines      321771   321771           
=======================================
+ Hits       267642   267643    +1     
+ Misses      54129    54128    -1     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vadorovsky]

I'll try to profile this whenever I have time.

[2501babe]

similar proportional savings using Criterion with 1m stake 1k vote:

bench_epoch_turnover/HANA
                        time:   [70.475 ms 70.904 ms 71.412 ms]
                        change: [−56.279% −55.881% −55.446%] (p = 0.00 < 0.05)
                        Performance has improved.

Benchmarking bench_epoch_rewards_period/HANA: Warming up for 1.0000 s
Warning: Unable to complete 10 samples in 10.0s. You may wish to increase target time to 44.5s.
bench_epoch_rewards_period/HANA
                        time:   [3.6422 s 3.6790 s 3.7185 s]
                        change: [−12.773% −11.459% −10.109%] (p = 0.00 < 0.05)
                        Performance has improved.

[2501babe]

@vadorovsky i landed the necessary solana-sdk work that was blocking this, so we can move forward on this any time we feel happy with it

[kskalski]

Are we going to land this change or did it turn out to not be useful? I'm asking because I want to support wincode serialization of snapshots (which does serialization of structs holding the stakes map) and could focus on adding support for just one of those crates.

[2501babe]

im in favor and think its up to @vadorovsky or @alessandrod

[alessandrod]

@kskalski could you help review?

I think switching is ok. The other crate is unmaintained. I did some profiling a few weeks ago and there was maybe a small regression somewhere but overall perf looks good. I say let's go for it and if we find issues we fix them, can't really depend on unmaintained code forever anyway.

[kskalski]

I will also compare the performance of into and from iterator that is part of serializing snapshots.

[kskalski]

I compared profiles for:

• deserializing snapshot - same perf, though im* isn't really visible there
• serializing snapshot - there is a slight (11% -> 8.5% of cpu), but clear improvement iterating over the im hash map (a lot of the calls into aux code from Iterator::next is gone, so this part was clearly inlined / optimized)

Given benchmark results, other comparison and maintenance status of im I also think it will be good to merge.