<div dir="ltr">With this last improvement:<br>Time millisecondsToRun:<br>       [10000 timesRepeat: [1 to: 1600 do: [:e | e isPrimeFast2]] ]  3502 <div><br>Without it:<br>Time millisecondsToRun:<br>        [10000 timesRepeat: [1 to: 1600 do: [:e | e isPrimeFast]] ]  4982 <br></div><div><br></div><div>It is indeed a 30% speed increase for numbers up to 1521.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El jue., 10 oct. 2019 a las 23:35, Andres Valloud via Cuis-dev (<<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hmmm, in here,<br>
<br>
        self < 384 ifTrue: [<br>
                "Approximate sqrtFloor to avoid computational expense"<br>
                3 to: (self bitShift: -3) + 1 by: 2 do:<br>
                        [:each | self \\ each = 0 ifTrue: [ ^false ]].<br>
                ^true<br>
        ].<br>
<br>
<br>
the loop should start at 7 because the factors 3 and 5 have already been <br>
excluded.  This gains noticeable speed for smallish integers (because <br>
384 sqrtFloor is just 19).  Looking into this further led to another 30% <br>
speed increase.  Would you mind checking?<br>
<br>
On 10/10/19 18:40, Agustín Sansone via Cuis-dev wrote:<br>
>     Here's something really important: doing too much micro-optimization<br>
>     detracts from the motivation to implement better things.  I'd say we<br>
>     leave things with the round of 30.<br>
> <br>
> <br>
> Okay. This is the 30*k 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>