Re: concurrent computation of a function

[Charles Greathouse <crgreathouse@gmail.com>]

If you're calculating long-running factorizations, PARI is the wrong tool.

For example, on a random semiprime C77, yafu takes 65 seconds (or 20 seconds on 4 cores, 5 seconds on which is on a single core) vs. 180 seconds for PARI.

Generally PARI is fast -- sometimes even world-class -- at ranges up to 50 digits, but beyond 60 digits it gets increasingly slow, to the point that it's hardly usable beyond 85 digits. And I haven't been following the drag races lately but I've seen NFS tuned for use at 90-110 digits and it's much faster than it used to be. (I think there was a project on mersenneforum to tune GGNFS for these ranges, but I could be misremembering.)

I would, however, find a "take this stack of numbers and end as soon as you find a factor to one of them" function very useful, especially if it came with a parxxx version to compute them literally in parallel (rather than running rho on each one, then SQUFOF on each one, then a low ECM on each, etc.). It could even be useful with a single number.

On Thu, Sep 19, 2024 at 3:42 PM Max Alekseyev <maxale@gmail.com> wrote:

Hi Bill,

Would compiling GP with debugging info and checking the crash backtrace help here?

If so, I'd be interested to step in debugging the issue.

Regards,

Max

On Thu, Sep 19, 2024 at 3:34 PM Bill Allombert <Bill.Allombert@math.u-bordeaux.fr> wrote:

On Thu, Sep 19, 2024 at 03:21:19PM -0400, Max Alekseyev wrote:
> I've tried to use the error() approach extensively in my code and
> immediately got a "real" error:
>
> free(): double free detected in tcache 2
> Aborted (core dumped)

This is exactly the kind of problems I warned you about.
To fix this we would need to know exactly what line of C
code was executed when the process was interrupted.
This is very hard to come by.

Cheers,
Bill.