Re: forprime in 32bit is 50x slower if p>2^32

[Charles Greathouse <charles.greathouse@case.edu>]

> 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.