Re: Big GOTCHAs WITH forprime() (correction to the “new end-encoding scheme”)

[Ilya Zakharevich <nospam-abuse@ilyaz.org>]

Aha: seems that the mail glitch disappeared…  The following message
did not make it out in January: (This is the 2nd of 2 missing
messages…  I also made minor enhancements.)

On Tue, Jan 30, 2024 at 05:50:10PM -0800, Ilya Zakharevich wrote:
> On Tue, Jan 30, 2024 at 05:10:26PM -0800, Ilya Zakharevich wrote:
> > On Sun, Jan 28, 2024 at 04:02:01PM +0100, Bill Allombert wrote:
> > > For maxprime=2^20 (the default in 2.16)
> > > The current prime difference table take 80kB.
> > > Using 32bit per entry would increase that to 320kB.

> 
>   … which does not fit into L2 cache of (e.g. my) CPU.
> 

> > > Storing isprime as a bit vector would take 128kB.

Not if you want to go to 10^8.  (But it would be still “manageable”.
However, if going to ∼10^10 has some advantages, the bitmap would not
be practical.)

> > The default of 2^20 is useless when one wants to check larger primes
> > (last I checked, it was about 30x slowdown when primelimit² is
> > exceeded.)
> > 
> >   (Although — I repeat — with the current unoptimized forprime() it is
> >    not clear whether primelimit above 1e8 can give advantages.)
> 
> If it was not clear before: I’m for (re)introduction of “hiccups” “at
> least until it is clear” how forprime() behaves with “proper”
> optimizations.  (So in the long run it may happen that they “are not
> needed” indeed!  But given that the price is 0, why not?)
> 
> Yours,
> Ilya