PARI discriminant speed depends on stack size

[jdemeyer]

This is weird and bad:

sage: x = polygen(ZpFM(3,10))
sage: p = ((x-1)^50 + x)._pari_init_()
sage: %time pari(p).poldisc()
CPU times: user 52.73 s, sys: 0.00 s, total: 52.73 s
Wall time: 52.82 s
2*3 + 3^4 + 2*3^6 + 3^7 + 2*3^8 + 2*3^9 + O(3^10)
sage: pari.allocatemem(2<<20)
PARI stack size set to 2097152 bytes
sage: %time pari(p).poldisc()
CPU times: user 0.08 s, sys: 0.00 s, total: 0.08 s
Wall time: 0.08 s
2*3 + 3^4 + 2*3^6 + 3^7 + 2*3^8 + 2*3^9 + O(3^10)

Upstream: http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1507

Depends on #15653

Upstream: Reported upstream. Developers deny it's a bug.

CC: @pjbruin

Component: performance

Author: Jeroen Demeyer

Branch/Commit: u/jdemeyer/ticket/15654 @ a955e45

Reviewer: David Roe

Issue created by migration from https://trac.sagemath.org/ticket/15654

[jdemeyer]

Upstream: Reported upstream. No feedback yet.

[jdemeyer]

Dependencies: #15653

[jdemeyer]

Author: Jeroen Demeyer

[jdemeyer]

Changed upstream from Reported upstream. No feedback yet. to Reported upstream. Developers deny it's a bug.

[jdemeyer]

Branch: u/jdemeyer/ticket/15654

[jdemeyer]

Commit: a955e45

[jdemeyer]

New commits:

7537427	Fix conversion of zero p-adics to PARI
a955e45	Speed up PARI determinants when stacksize is small

[jdemeyer]

comment:8

This solution works well for Sage, maybe not for PARI/GP upstream.

[roed314]

comment:9

I'm fine with this change. I'm not yet familiar with reviewing SPKG changes using the new directory layout. Why is SPKG.txt deleted in this commit?

More generally, are there other places in Sage where we should be more aggressive about increasing the Pari stack size? If someone is using Pari nontrivially, our current stack size seems too small. Should we increase the stack whenever a user does certain operations signaling that they're going to be using Pari extensively (e.g. create a number field of degree larger than 4, take the discriminant of a polynomial of large degree...)?

[jdemeyer]

comment:10

Replying to @roed314:

I'm fine with this change. I'm not yet familiar with reviewing SPKG changes using the new directory layout. Why is SPKG.txt deleted in this commit?

Not all of SPKG.txt, just the changelog.

[jdemeyer]

comment:11

Replying to @roed314:

More generally, are there other places in Sage where we should be more aggressive about increasing the Pari stack size? If someone is using Pari nontrivially, our current stack size seems too small. Should we increase the stack whenever a user does certain operations signaling that they're going to be using Pari extensively (e.g. create a number field of degree larger than 4, take the discriminant of a polynomial of large degree...)?

We could detect the problem by adding some code to gerepile...() to count the number of garbage collections. We could for example give a warning if more than N happen per second (for a suitable value of N).

[jdemeyer]

comment:12

See #15659.

[jdemeyer]

comment:13

Replying to @roed314:

More generally, are there other places in Sage where we should be more aggressive about increasing the Pari stack size?

Yes, see #15660.

[roed314]

comment:14

Cool. I'm doctesting this ticket and will then give it a positive review.

[roed314]

Reviewer: David Roe

[roed314]

comment:15

Looks good.

[vbraun]

comment:16

Ok, this is not "critical"