[Cuis-dev] Problems in class Number

[Agustín Sansone]

This ir what I get:

"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

El sáb., 12 oct. 2019 a las 0:02, Andres Valloud via Cuis-dev (<
cuis-dev at lists.cuis.st>) escribió:

> 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
> > (<cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>>) 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
> >      > <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>
> >     <mailto:cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>>>
> 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
> >      > Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> >     <mailto:Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>>
> >      > https://lists.cuis.st/mailman/listinfo/cuis-dev
> >      >
> >     --
> >     Cuis-dev mailing list
> >     Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> >     https://lists.cuis.st/mailman/listinfo/cuis-dev
> >
> >
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191012/71ba8cb0/attachment.htm>