<div dir="ltr">Was that primarily due to the 64-bit version mostly fitting within SmallInteger?  I find many numeric performance issues just melt away by staying away from Large*Integer (and Fraction)... they're great for maintaining accuracy, lousy for performance.  As in multiples to orders of magnitude worse depending on what you're doing.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 11, 2019 at 12:40 AM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Fascinating --- the gcd approach was pretty bad in 32 bit land. <br>
However, in 64 bits, the gcd batches are large enough to amortize the <br>
cost, and that detects most composites without sending sqrtFloor.  The <br>
small integer threshold is now 91 squared.<br>
<br>
On 10/10/19 20:37, Agustín Sansone via Cuis-dev wrote:<br>
>     Well, what do you think?  Are we done going over this poor method?<br>
> <br>
> <br>
> Okay, I'm happy with this version.<br>
> <br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div>