[Cuis-dev] Problems in class Number

[Andres Valloud]

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