perf: use new PyLong* API for num-bigint feature#6144
Conversation
Merging this PR will improve performance by 81.39%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ⚡ | into_bigint_huge_negative |
23.5 µs | 6.6 µs | ×3.6 |
| ⚡ | extract_biguint_negative_fail |
7.3 µs | 2.3 µs | ×3.2 |
| ⚡ | extract_biguint_zero |
2.7 µs | 1 µs | ×2.6 |
| ⚡ | into_bigint_huge_positive |
17.3 µs | 6.6 µs | ×2.6 |
| ⚡ | into_biguint_huge |
16.9 µs | 6.7 µs | ×2.5 |
| ⚡ | into_bigint_big_negative |
5.1 µs | 2.1 µs | ×2.4 |
| ⚡ | into_bigint_small |
3.1 µs | 1.5 µs | ×2.1 |
| ⚡ | into_bigint_big_positive |
4.4 µs | 2.2 µs | ×2 |
| ⚡ | into_biguint_big |
4.2 µs | 2.2 µs | +89.7% |
| ⚡ | into_biguint_small |
3.2 µs | 2 µs | +64% |
| ⚡ | extract_bigint_huge_negative |
13 µs | 8.4 µs | +54.31% |
| ⚡ | extract_bigint_small |
2.7 µs | 1.9 µs | +47.31% |
| ⚡ | extract_biguint_small |
2.5 µs | 1.8 µs | +44.19% |
| ⚡ | extract_biguint_huge |
11 µs | 7.7 µs | +41.79% |
| ⚡ | extract_bigint_huge_positive |
11.7 µs | 8.4 µs | +39.54% |
| ⚡ | into_biguint_zero |
2.8 µs | 2.1 µs | +35.17% |
| ⚡ | extract_bigint_big_negative |
3.9 µs | 3.3 µs | +18.39% |
| ⚡ | extract_bigint_big_positive |
3.7 µs | 3.3 µs | +11.7% |
| ⚡ | extract_biguint_big |
3.6 µs | 3.3 µs | +10.06% |
Tip
Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.
Comparing chirizxc:PyLongForBigInt (103e6fd) with main (7550783)
davidhewitt
left a comment
There was a problem hiding this comment.
Thanks, generally looks good on the from-python implementation; I think possible gains yet to be had in the to-python implementation.
|
|
||
| #[cfg(all(not(Py_LIMITED_API), Py_3_14))] | ||
| { | ||
| if is_30bit_layout() { |
There was a problem hiding this comment.
Some observations on this path:
- I would prefer to have this logic extracted into a generic function; I think it's easier to maintain than when it's deeply nested inside a macro.
- I think we can avoid the intermediate
Vecallocation from the digits and instead wrap the iterator coming out of the big-integer.pylong_from_digitsneeds anExactSizeIterator, so it'll be a touch fiddly but I think still possible. - I think we lack benchmarks for the bigint to-python pathway, so possibly worth landing some of those before we think too hard about this.
There was a problem hiding this comment.
- I think we lack benchmarks for the bigint to-python pathway, so possibly worth landing some of those before we think too hard about this.
|
Also, I think worth giving this a |
PyLong API for num-bigint featurePyLong* API for num-bigint feature
Related: #6040
See codspeed comment for benchmark improvements.