[Cuis-dev] Problems in class Number

[Agustín Sansone]

Okay :)

El sáb., 12 oct. 2019 1:47 a. m., Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> escribió:

> Ok, how about we ship off the 8281 boundary code then?
>
> On 10/11/19 20:36, Agustín Sansone via Cuis-dev wrote:
> > 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 <mailto: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>
> >     <mailto: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>>
> >      >     <mailto: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>>
> >      >     <mailto: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>
> >     <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/9d98f49e/attachment-0001.htm>