Describe the bug

math.perm(n, k) multiplies the running product by one factor at a time, so its cost grows with the square of the result size. math.perm(615913, 286885), a 5,401,202-bit result, takes 29.6 s on GraalPy master against 1.4 s on CPython 3.13.14. The result is correct.

Operating system

macOS

CPU architecture

ARM64

GraalPy version

master a3009f9 (Python 3.13.14); also reproduced on 25.0.2 (Python 3.12.8)

JDK version

No response

Context configuration

No response

Steps to reproduce

import math, time
t = time.time()
n = math.perm(615913, 286885)
print(n.bit_length(), round(time.time() - t, 1))

GraalPy master a3009f9:

5401202 29.6

Expected behavior

CPython 3.13.14 (same on 3.12.13):

5401202 1.4

Stack trace

Additional context

math.comb uses the same sequential loop: math.comb(615913, 286885) takes 20.0 s on GraalPy master against 1.9 s on CPython 3.13.14.

Root Cause

PermNode.calculatePerm computes P(n, k) with k - 1 multiplications of the growing product by a small factor (MathModuleBuiltins.java#L540-L547), so BigInteger.multiply never gets two large operands and never uses its Karatsuba or Toom-Cook paths. CPython splits the product as P(n, k) = P(n, j) * P(n - j, k - j) with j = k / 2 (mathmodule.c#L3634-L3649, #L3666-L3702), so the large multiplications are between operands of similar size.

Fix Suggestion

Replace the loop with the same recursive split; on JDK 21 it computes this case in 0.33 s with an identical result.