Re: segfaults — and optimizations — in forprime() (the summary)

On Thu, Jan 25, 2024 at 03:12:37PM +0100, Bill Allombert wrote:
> > I repeat the 4th time:
> >      This is not the code mentioned above, in 2520#10.
> 
> Ah sorry! For some reason, I kept pasting the wrong line.

No problem at all — as far as feedback loop is alive!  (I was quite
worried initially, with the quality/interactivity of whatever feedback
then visible being “as it was”…)

> So it seems the first bad commit is
> 
> commit a286058de199e0477bb51d82a3f092ca71a47ad9
> Author: Karim Belabas <[email protected]>
> Date:   Mon May 26 11:56:00 2014 +0200
> 
>     25- (gp -p N) or (primelimit=N in gprc_ for N >= 436273290 resulted in an
>        incorrect primetable. N.B. Such commands are now useless: needed primes
>        are produced dynamically anyway.

A couple of observations (all of them were spelled out already
recently, but to have them “in one place”):

  • With the dubious results of timing on some machines (like
    mine — recall that this segfault was found bisecting a strange
    timing issue), and the sieving code being “not quite optimized”
    (to put it mildly):

       I’m not sure that removal of support of prime lists above 436e6
       is 100% beneficial.  And until this is cleared out
       (benchmarked), it would seem to be best to keep this
       possibility in.

       (Recall that my initial code — which was in PARI for a
        decade — supported arbitrarily long lists.  This bug is a
        result of removing this code.)

          This has been already mentioned in (look for “1/10000th of a
          workaround”):
	   
       http://megrez.math.u-bordeaux.fr/archives/pari-dev-2401/msg00015.html   

  • My initial implementation of “arbitrary long lists” was quite
    optimized “on low level” (could have been the-best-one-could-get
    from C code at that time), but missed one “higher level”
    optimization!  (See my message of yesterday:

       http://megrez.math.u-bordeaux.fr/archives/pari-dev-2401/msg00070.html
       
    .)  Without this optimization, the support of “arbitrary long
    prime lists” has a price (tiny, but measurable with old
    processors — which had bad branch prediction).  With this new
    optimization, such support should be “completely free”.

Thanks,
Ilya