Re: pari: add config options

[tornaria <tornaria@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]

New comment by tornaria on void-packages repository

https://github.com/void-linux/void-packages/pull/29635#issuecomment-808811231

Comment:
> This is such that pari is usable when building sagemath, which requires pthread.
As a matter of fact, I don't think sagemath requires pari built with pthread, or does it? (maybe it does need TLS at least? I don't know)

Anyway, sagemath won't work with pari-2.13 (for now, see https://trac.sagemath.org/ticket/30801) but that's for a different reason.

I run check as a "benchmark" to have hard data, but so far it seems to support what I thought:
 - using `pthreads` has a 25-45 % performance hit (25% for `gp-sta`, 45% for `gp-dyn`)
 - using `CFLAGS=-flto` doesn't change anything (even make `gp-dyn` slower).

A very stupid (non-)benchmark is to run
```
$ echo "sum(i=1,100 000 000, i);" | time gp -q
```
This doesn't substitute a proper benchmark, but at least it takes less than 5s to show a significant slowdown: it takes ~ 4.25s for me with the current binary from `pari-2.13.1_1`, but ~ 8.5s with `--mt=pthread` and more than 9s with `-flto` (less if using gp-sta, but we are shipping gp-dyn).

Note that all this "benchmark" is using a single-thread, because most (all?) of pari code which is written in C is single-thread. If you actually USE multiple threads you'll pay another 50% penalty. For instance:
```
echo "parsum(j=0,99,sum(i=j*1 000 000 + 1, (j+1)*1 000 000, i));" | time gp -q
```
Takes:
 - with single-thread gp-dyn: still 4.25s (no different than above)
 - with single-thread gp-sta: ~ 4s
 - with pthread gp-dyn: 12.87s user = 2.40s wall (8 core)
 - with pthread gp-sta: 7.28s user = 1.37s wall (8 core)

I'm not willing to pay a 3x penalty for using multi-thread. I can parallelize my programs in a different way, but of course not all tasks are suitable for that.

Here's a proposal (RFC):
 - start building and shipping gp-sta instead of gp-dyn (it's not clear what's the advantage of gp-dyn other than disk space).
 - add a build option to pari so that it's easy to compile pari with pthread support. It's even more important that the pthread version compiles gp-sta as the penalty is higher here.
 - start shipping the static library so external programs can static link with pari.
 - consider actually compiling both single-thread and multi-thread pari. The libraries have different SONAMES so that would not be a problem. As for the gp binary, we could ship them in separate packages, either conflicting or with different names and alternatives.

What do you think?

I'm willing to do all of the above and take over the package if the plan above sounds reasonable.