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