Skip to content

Use intops-powered Stint and bncurve, introduce intops a new dependency#3956

Merged
tersec merged 8 commits intomasterfrom
feature/stint_bncurve_with_intops
Feb 10, 2026
Merged

Use intops-powered Stint and bncurve, introduce intops a new dependency#3956
tersec merged 8 commits intomasterfrom
feature/stint_bncurve_with_intops

Conversation

@moigagoo
Copy link
Copy Markdown
Contributor

@moigagoo moigagoo commented Feb 2, 2026

Stint and bncurve are migrating to the new intops library:

The tests pass, the benchmarks are good (some even got better).

However, we need to validate that no projects depending in Stint or bncurve break with this change.

This PR introduces the new versions of Stint and bncurve that use intops as well as adds intops itself as a dependency.

@moigagoo moigagoo requested a review from arnetheduck February 2, 2026 12:28
Comment thread .gitmodules Outdated
@moigagoo moigagoo marked this pull request as draft February 3, 2026 09:27
@moigagoo
Copy link
Copy Markdown
Contributor Author

moigagoo commented Feb 3, 2026

I did local benchmarks (thanks to @advaita-saha) on ≈2kk blocks, compared master vs feature/stint_bncurve_with_intops:

master.csv vs intops.csv
                      bps_x    bps_y     tps_x     tps_y time_x time_y   bpsd   tpsd  timed
block_number
(499713, 700872]   6,736.07 6,578.16 10,318.32 10,103.54    32s    32s -1.97% -1.97%  2.16%
(700872, 902031]   3,317.78 3,289.77  7,967.83  7,874.66   1m7s   1m8s  0.31%  0.31%  2.26%
(902031, 1103190]  3,166.52 3,096.29 11,227.49 10,999.39   1m4s   1m5s -1.96% -1.96%  2.22%
(1103190, 1304349] 2,410.27 2,358.49 12,899.62 12,619.72  1m26s  1m28s -2.08% -2.08%  2.45%
(1304349, 1505508] 2,297.93 2,246.56 13,683.43 13,377.98  1m26s  1m28s -2.21% -2.21%  2.35%
(1505508, 1706667] 1,856.57 1,838.45 13,314.56 13,186.56  1m52s  1m54s -1.00% -1.00%  1.40%
(1706667, 1907826] 1,589.74 1,558.68 11,080.58 10,847.80  2m54s  2m59s -2.13% -2.13%  2.31%
(1907826, 2108985] 1,726.67 1,747.86 13,128.01 13,300.68   2m4s   2m2s  1.62%  1.62% -1.43%
(2108985, 2310144] 1,643.15 1,607.62 12,840.02 12,569.54  2m27s  2m32s -2.29% -2.29%  3.25%

blocks: 1802239, baseline: 14m56s, contender: 15m12s
Time (total): 16s, 1.85%

bpsd = blocks per sec diff (+), tpsd = txs per sec diff, timed = time to process diff (-)
+ = more is better, - = less is better

Not sure how to interpret those results. 1.85 % slowdown may well be a random fluctuation (I'm running the import on a regular laptop, with other tasks running concurrently, which could affect the results).

@tersec should I run a larger import?

@advaita-saha
Copy link
Copy Markdown
Contributor

Run till 3.5M blocks I would suggest

@tersec
Copy link
Copy Markdown
Contributor

tersec commented Feb 3, 2026

Run till 3.5M blocks I would suggest

Agree. The earlier blocks qualitatively differ because people hadn't been using the network as much. But also yes, laptops require significant effort to transform into stable benchmarking platforms. 1.85% is enough to at least investigate the extent to which it might (or might not) represent random noise/fluctuations, because while it's not enormous, running 1.85% slower due to an integer library change isn't necessarily worthwhile.

Furthermore, those benchmarks involve the entire block processing pipeline, which involves many tasks which don't run through nim-stint in any involved way, which implies that a purely nim-stint-driven change to performance of that magnitude is likely larger than its diluted effect on overall performance and even more worth investigating.

@moigagoo
Copy link
Copy Markdown
Contributor Author

moigagoo commented Feb 4, 2026

@tersec @advaita-saha

OK I did the 1-hour, 3.5kk block benchmark. It's still local, still run on a regular laptop but I tried my best to minimize foreign influences , almost didn't touch the keyboard the entire time.

The results:

master.csv vs intops.csv
                      bps_x    bps_y     tps_x     tps_y time_x time_y   bpsd   tpsd  timed
block_number
(499713, 833078]   5,781.92 6,140.45 10,166.06 10,744.35   1m9s   1m6s  5.75%  5.75% -5.02%
(833078, 1166443]  3,817.09 3,805.82 13,175.04 13,182.90  1m31s  1m32s -0.23% -0.23%  0.95%
(1166443, 1499809] 2,654.27 2,573.17 15,314.59 14,880.89   2m8s  2m12s -2.89% -2.89%  3.30%
(1499809, 1833174] 1,950.20 1,971.41 14,029.17 14,207.63  3m38s  3m35s  1.30%  1.30% -1.10%
(1833174, 2166539] 1,996.92 2,003.68 14,718.23 14,760.31  2m55s  2m54s  0.69%  0.69% -0.24%
(2166539, 2499905] 1,033.83 1,034.42  7,931.42  7,926.87 24m17s 24m38s -0.13% -0.13%  0.58%
(2499905, 2833270] 1,604.82 1,573.21 11,160.26 10,929.39  14m4s  14m7s -1.78% -1.78%  2.40%
(2833270, 3166635] 1,754.61 1,713.28 13,004.55 12,691.00  3m19s  3m22s -1.86% -1.86%  2.58%
(3166635, 3500001] 1,235.26 1,222.35 14,017.43 13,831.16  4m44s  4m49s -1.24% -1.24%  1.84%

blocks: 2992096, baseline: 57m50s, contender: 58m19s
Time (total): 29s, 0.86%

bpsd = blocks per sec diff (+), tpsd = txs per sec diff, timed = time to process diff (-)
+ = more is better, - = less is better

As before, I'm not sure how to interpret that. To me, smaller diff on a longer bench and the fact that the diff is <1% indicate that the two solutions converge performance-wise, i.e. we're not observing a true performance drop and the diff could be attributed to randomness associated with local environment.

However, I may be entirely wrong and a 0.86% drop would be considered unacceptable for Nimbus. Would love to know your thoughts on that.

@moigagoo
Copy link
Copy Markdown
Contributor Author

moigagoo commented Feb 4, 2026

Furthermore, those benchmarks involve the entire block processing pipeline, which involves many tasks which don't run through nim-stint in any involved way, which implies that a purely nim-stint-driven change to performance of that magnitude is likely larger than its diluted effect on overall performance and even more worth investigating.

@tersec Could you please suggest ways to benchmark the parts that do involve stint in isolation? I agree that if the measurements are accurate, a small drop in overall performance could indicate a larger drop in the arithmetic-heavy part. If there's a way to check that, I'd definitely do it.

@moigagoo
Copy link
Copy Markdown
Contributor Author

moigagoo commented Feb 4, 2026

I did another run of the benchmarks and this time the new version is actually 1.31% better:

master.csv vs intops.csv
                      bps_x    bps_y     tps_x     tps_y time_x time_y   bpsd   tpsd  timed
block_number
(499713, 833078]   5,802.75 6,126.59 10,215.05 10,725.15   1m9s   1m6s  5.37%  5.37% -4.36%
(833078, 1166443]  3,722.98 3,781.27 12,822.87 13,080.76  1m34s  1m33s  1.68%  1.68% -0.82%
(1166443, 1499809] 2,613.05 2,638.48 15,087.22 15,230.87  2m11s  2m10s  1.04%  1.04% -0.93%
(1499809, 1833174] 1,949.85 1,957.00 14,042.41 14,096.06  3m38s  3m39s  0.23%  0.23% -0.14%
(1833174, 2166539] 1,992.52 2,016.45 14,671.83 14,843.53  2m55s  2m53s  1.19%  1.19% -1.09%
(2166539, 2499905] 1,028.07 1,054.44  7,879.15  8,071.32  24m5s 23m19s  2.64%  2.64% -2.34%
(2499905, 2833270] 1,632.69 1,625.79 11,361.07 11,307.18 12m41s 12m56s -0.98% -0.98%  1.45%
(2833270, 3166635] 1,808.43 1,821.02 13,392.86 13,479.84  3m10s  3m10s  0.68%  0.68% -0.51%
(3166635, 3500001] 1,269.35 1,295.17 14,358.39 14,692.98  4m39s  4m31s  2.59%  2.59% -2.29%

blocks: 2992096, baseline: 56m7s, contender: 55m23s
Time (total): -44s, -1.31%

bpsd = blocks per sec diff (+), tpsd = txs per sec diff, timed = time to process diff (-)
+ = more is better, - = less is better

IMO that's a strong indication that the performance was not affected by the switch to intops.

I'll mark the PR as ready for review. If I get the approvals, I'll merge the stint and bncurve PRs, update this one to point to the main version and not my forks, and merge this one as well.

@tersec tersec merged commit c2f98dd into master Feb 10, 2026
22 of 35 checks passed
@tersec tersec deleted the feature/stint_bncurve_with_intops branch February 10, 2026 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants