|Charles Greathouse on Thu, 25 Oct 2012 21:35:24 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: forprime in 32bit is 50x slower if p>2^32|
> Maybe we could at least replace 210 by something larger. Maybe. Maybe even use a small sieve if the numbers are large enough (not in this case...), say of length 4 log x (98% likely to contain the next prime). > If you had to debug ellheegner in 32bit, you might change your mind. > > Beside ARM users are stuck with 32bit for some years still. Yes, it's bad for Windows and ARM users (as well as legacy users). I do think it would be nice, but I have a hard time seeing how it could be fit in. Even if I had a machine to test with I owe Karim an implementation of forfactored() first. Charles Greathouse Analyst/Programmer Case Western Reserve University On Thu, Oct 25, 2012 at 3:02 PM, Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> wrote: > On Thu, Oct 25, 2012 at 01:13:39PM -0400, Charles Greathouse wrote: >> > Threshold between an efficient sieve and expensive unextprime()... >> >> No, even worse: it has to use nextprime(). This means it loops through >> the good congruence classes mod 210 and runs BPSW_psp until it finds a >> hit... > > Maybe we could at least replace 210 by something larger. > >> I don't have a 32-bit system to test and I expect such systems will be >> less and less popular. Unfortunately without a 64-bit version of >> Cwgwin (?) Windows users are stuck with the 32-bit version. That's a >> pity... > > A 64bit version of cygwin would not necessarily help. Indeed we have a 64bit > version of mingw already. What we need is a build environment such that > sizeof(long)==sizeof(void*)==8. > >> > I would not make it a priority: we have many more projects than we can handle >> > already :-(. >> >> I feel the same way. > > If you had to debug ellheegner in 32bit, you might change your mind. > > Beside ARM users are stuck with 32bit for some years still. > > Cheers, > Bill.