| Ilya Zakharevich on Thu, 25 Jan 2024 23:09:53 +0100 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| 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 <Karim.Belabas@math.u-bordeaux1.fr>
> 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