optimize the simple addition and substraction of small integers

[arvidn]

where we don't have to involve bignum

This improves performance slightly for small integer arithmetic. Specifically for + and -.

$ critcmp baseline optimization
group                          baseline                               optimization
-----                          --------                               ------------
run_program/block-2000         1.00     56.3±0.02ns        ? ?/sec    1.00     56.3±0.02ns        ? ?/sec
run_program/compressed-2000    1.00    379.6±0.42ms        ? ?/sec    1.01    385.3±8.80ms        ? ?/sec
run_program/concat             1.01    192.0±2.53ms        ? ?/sec    1.00    190.7±1.38ms        ? ?/sec
run_program/count-even         1.11      6.1±0.00ms        ? ?/sec    1.00      5.5±0.02ms        ? ?/sec
run_program/factorial          1.02     80.8±1.33ms        ? ?/sec    1.00     79.3±0.06ms        ? ?/sec
run_program/hash-string        1.00    315.4±0.13ns        ? ?/sec    1.00    315.7±0.13ns        ? ?/sec
run_program/hash-tree          1.00     25.1±0.01ms        ? ?/sec    1.00     25.1±0.04ms        ? ?/sec
run_program/large-block        1.00    118.6±0.03ms        ? ?/sec    1.00    118.7±0.07ms        ? ?/sec
run_program/loop_add           1.17  1526.3±20.18ms        ? ?/sec    1.00   1300.3±0.67ms        ? ?/sec
run_program/loop_ior           1.18  1405.5±20.94ms        ? ?/sec    1.00  1187.1±17.40ms        ? ?/sec
run_program/loop_not           1.19   1428.8±5.47ms        ? ?/sec    1.00   1201.2±0.42ms        ? ?/sec
run_program/loop_sub           1.14   1555.2±2.15ms        ? ?/sec    1.00  1359.7±32.20ms        ? ?/sec
run_program/loop_xor           1.16   1569.5±0.50ms        ? ?/sec    1.00  1352.6±11.54ms        ? ?/sec
run_program/matrix-multiply    1.05    105.1±3.99ms        ? ?/sec    1.00    100.1±0.09ms        ? ?/sec
run_program/point-pow          1.00    146.1±0.02ms        ? ?/sec    1.00    146.0±0.06ms        ? ?/sec
run_program/pubkey-tree        1.00     80.6±0.03ms        ? ?/sec    1.02     82.0±2.45ms        ? ?/sec
run_program/shift-left         1.09   784.5±47.13ms        ? ?/sec    1.00    719.3±8.67ms        ? ?/sec
run_program/substr             1.01      3.1±0.00ms        ? ?/sec    1.00      3.1±0.00ms        ? ?/sec
run_program/substr-tree        1.00     66.9±0.08ms        ? ?/sec    1.00     66.9±0.09ms        ? ?/sec
run_program/sum-tree           1.00    155.4±0.53ms        ? ?/sec    1.01    156.2±0.43ms        ? ?/sec

---

Note

^{Cursor Bugbot is generating a summary for commit 6f0a9bb. Configure here.}

[coveralls-official]

Pull Request Test Coverage Report for Build 22676204120

Details

• 89 of 93 (95.7%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.09%) to 88.261%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/more_ops.rs	43	47	91.49%

Totals
Change from base Build 22670399406:	0.09%
Covered Lines:	6977
Relevant Lines:	7905

---

💛 - Coveralls

[Copilot]

Pull request overview

This PR adds fast paths to op_add and op_subtract in the CLVM interpreter to skip bignum arithmetic when all operands are small non-negative integers (stored as SmallAtom/NodeVisitor::U32). It also introduces two new helper methods new_u64 and new_i64 on the Allocator to create atoms from primitive Rust integer types directly.

Changes:

• Adds Allocator::new_u64 and Allocator::new_i64 methods with minimal two's-complement big-endian byte encoding
• Adds fast-path logic in op_add and op_subtract that detects all-SmallAtom inputs and avoids bignum allocation
• Adds comprehensive unit tests for new_u64 and new_i64 covering boundary values

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/allocator.rs	Adds new_u64/new_i64 helper methods for direct integer-to-atom conversion, plus corresponding unit tests
src/more_ops.rs	Adds IIFE-based fast paths in op_add and op_subtract that accumulate in native integer types for all-SmallAtom inputs, falling back to the existing bignum slow path otherwise

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Rigidity]

Are the savings worth the complexity here?

[wjblanke]

aok

[wjblanke]

Are the savings worth the complexity here?

We probably should upstream this to num_bigint

[arvidn]

Are the savings worth the complexity here?

I think it might be. As long as we're confident in the tests ensuring the behavior is unaffected. The common cases of small numbers are disproportionally expensive as it is. I think it might even make sense to do this to multiply, div, divmod, mod and gr, and possibly some other arithmetic operators.

We probably should upstream this to num_bigint

I don't think this would fall in the scope of any bignum library, it would probably slow down the common case.

[wjblanke]

aok