<div dir="ltr"><div>This ir what I get:</div><div> </div>"3970 boundary" Time millisecondsToRun: [10000 timesRepeat: [1 to: 8281 by: 8 do: [:x |x isPrimeFast]]]. 5257 "8281 boundary" Time millisecondsToRun: [10000 timesRepeat: [1 to: 8281 by: 8 do: [:x |x isPrimeFast2]]]. 4104 </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">El sáb., 12 oct. 2019 a las 0:02, Andres Valloud via Cuis-dev (<<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>>) escribió: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think this happened because we are measuring against different number sets so we ended up tuning to our tests. By the way, I'm having some trouble getting reliable times, the figures seem to change by ~10% without any obvious reason. For instance, for the last code you sent, running that through some of the tests here results in times ranging from 2272 to 2510 milliseconds --- and that's starting from a clean system after a GC, so each run starts in the same conditions. That's a lot of difference for a computer that should be roughly stable... Would you mind checking the numbers you get with the attached method? It just takes your latest code and increases the boundary for the small number loop to 8281. Here's why I'd like to see what happens for you: "your latest" Time millisecondsToRun: [10000 timesRepeat: [1 to: 8281 by: 8 do: [:x | x isPrimeFast1c]]] 1647 "attached here" Time millisecondsToRun: [10000 timesRepeat: [1 to: 8281 by: 8 do: [:x | x isPrimeFast1d]]] 1565 Andres. On 10/11/19 10:59, Agustín Sansone via Cuis-dev wrote: > Latest code you sent: > Time millisecondsToRun: > [1 to: 10000000 do: [:e | e isPrimeFast]]. 16025 > > Latest code I sent: > Time millisecondsToRun: > [1 to: 10000000 do: [:e | e isPrimeFast]]. 14435 > > > El vie., 11 oct. 2019 a las 2:09, Andres Valloud via Cuis-dev > (<<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>>>) escribió: > > Euclid's gcd algorithm converges to the answer exponentially with base > phi. Larger small integers help amortize the extra cost. > > On 10/10/19 21:53, Phil B wrote: > > 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. > > > > On Fri, Oct 11, 2019 at 12:40 AM Andres Valloud via Cuis-dev > > <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> > <mailto:<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>>>> wrote: > > > > Fascinating --- the gcd approach was pretty bad in 32 bit land. > > However, in 64 bits, the gcd batches are large enough to > amortize the > > cost, and that detects most composites without sending > sqrtFloor. The > > small integer threshold is now 91 squared. > > > > On 10/10/19 20:37, Agustín Sansone via Cuis-dev wrote: > > > Well, what do you think? Are we done going over this poor > > method? > > > > > > > > > Okay, I'm happy with this version. > > > > > -- > > Cuis-dev mailing list > > <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a>> > <mailto:<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a>>> > > <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> > > > -- > Cuis-dev mailing list > <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a>> > <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> > > -- Cuis-dev mailing list <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div>