Then I guess the reason of the slowdown comes from the change in
the integer types in Python 3 and the way we handle the conversion
from Python integers to Sage integers.
Namely we have low level mpz_set_pylong (for "long" integers) and
mpz_set_si (for machine integers, which is a GMP function). But in
Python3 there is no more distinction and every integer is a "long"
integer. Hence on Sagemath Python3, the conversion always go
through mpz_set_pylong which seems 25% slower than mpz_set_si.
Le 23/11/2019 à 13:06, John H Palmieri a écrit :
On Saturday, November 23, 2019 at 12:38:35 PM UTC-8, vdelecroix wrote:
Le 23/11/2019 à 11:34, John H Palmieri a écrit :
By the way, Integer(1r) is also faster with Python 2 than with Python 3.
By how much? Does it explain the 25% slowdown of the original post?
Python 2:
sage: %timeit Integer(1r)
The slowest run took 41.65 times longer than the fastest. This could mean
that an intermediate result is being cached.
10000000 loops, best of 3: 45.8 ns per loop
sage: %time Integer(2r)
CPU times: user 3 µs, sys: 2 µs, total: 5 µs
Wall time: 5.01 µs
2
Python 3:
sage: %timeit Integer(1r)
The slowest run took 25.70 times longer than the fastest. This could mean
that an intermediate result is being cached.
10000000 loops, best of 5: 71.2 ns per loop
sage: %time Integer(2r)
CPU times: user 3 µs, sys: 1 µs, total: 4 µs
Wall time: 6.91 µs
2
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/62023b03-8459-deb7-831a-5134576830ca%40gmail.com.
