[Bug]: GraalPy math.isqrt is slow

[skirpichev]

Describe the bug

I tried to enable GraalPy in Github Actions to run the mpmath test suite, but tests runs enormously slow (more 6 hours, and CI job timeouts):
https://github.com/mpmath/mpmath/actions/runs/29463728468/job/87512994527

c.f. ~6-7min for PyPy/CPython. Mpmath heavily uses integer arithmetic, though in CI tests most operands are machine-sized (~99% of <= 53bits). That's why tests on PyPy are slightly faster, when using builtin integers.

I didn't run tests on GMP-based backends (using python-gmp or gmpy2 packages for integer arithmetics), but I expect that situation here will be only worse.

Operating system

Linux

CPU architecture

x86_64

GraalPy version

25.1.3

JDK version

No response

Context configuration

No response

Steps to reproduce

Install mpmath:
https://mpmath.readthedocs.io/en/latest/setup.html#download-and-installation
Run test suite:
https://mpmath.readthedocs.io/en/latest/setup.html#running-tests

Expected behavior

This depends on hardware, but in Github Actions full test suite using builtin integers as integer math backend - takes ~8min on CPython 3.14 and ~6min on PyPy.

It would expect, that GraalPy might be slower. But not for several orders of magnitude...

Stack trace

Additional context

No response

[skirpichev]

Sorry for a mistake. Referenced build log was with an older version of GraalPy.

With the latest stable (v25.1.3) and few tests filtered out (I doubt this does matter), CI finishes in ~2h33m:
https://github.com/mpmath/mpmath/actions/runs/29551924365/job/87796835668
(8 timeouts, 3 failures)

Still, this is more than by order of magnitude worse than CPython/PyPy.

Edit: It was only ~80% of tests. To my surprise, with the python-gmp extension, instead of builtin integers - things are much better: https://github.com/mpmath/mpmath/actions/runs/29564136460/job/87833669766
Whole test suite pass in ~57min with one test timeout.

[msimacek]

Thanks for the report. It's not integer artithmetics as a whole, I narrowed it down to a naive math.isqrt implementation that was so bad it was responsible for nearly all of the slowdown. I'll submit a fix soon. With that fixed, locally I get about 13 min for GraalPy. I'll investigate that further, there might be still be some suboptimal builtin or a deopt loop somewhere.

In general:

• GraalPy should be faster than CPython on basic 32bit integer arithmetics even without the JIT due to bytecode quickening for Java int. On 64bit integers and float, there is no quickening, but there are still fast specializations for Java long/double. This doesn't always extend to every builtin in math, some of them have fast-paths and some only have generic paths for large integers.
• Larger than 64bit integers don't perform so great. They are implemented using Java BigIntegers, which are opaque to the JIT and tend to put allocation pressure on the GC.
• GraalPy tends to be slower on executing tests because tests keep executing new cold code all the time, so the time spent profiling and compiling often doesn't pay off.