[Cuis-dev] usefulness of a faster #timesRepeat?

[Hernan Wilkinson]

Hi,
 as we all know software development is about making tradeoffs all the
time. The change in #timesRepeat: is interesting and definitely shows a lot
of knowledge behind it, but it also adds some complexity that makes it
difficult to understand and explain.
 The original #timesRepeat: implementation is very nice and simple which
makes it an interesting example to show as I do when teaching at the
university. It's a great example of Smalltalk's simplicity and ability to
create "control flow messages" using the same language and without having
to change the syntax and compiler.
 I made a simple performance test to see the impact of the change:

Smalltalk garbageCollect.
Time millisecondsToRun: [ 100000000 timesRepeat: []].

 With the original implementation the average in my machine gives 462 and
with the other implementation gives 367, so a 100 milliseconds improvement
in one hundred millions iterations.

 So, for me it is so little that we gain compared with the complexity it
adds that I would not put that in the base image. I would put it in a
package that anybody could load if that improvement was necessary and leave
the original implementation in the base as an example of Smalltalk
simplicity and beauty.

Best,
Hernan.

On Sat, Nov 9, 2019 at 1:19 AM Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Hi,
>
> >> First, especially in 32 bit systems, it's very important never to send
> >> timesRepeat: to a large integer --- this is why the large integer
> >> method splits the process in rounds of timesRepeat: sent to small
> >> integers.
> >
> > I guess you mean 'never run the iteration on LargeInteger arithmetic',
> > so with the splitting in LargePositiveInteger, sending timesRepeat: to a
> > large integer is ok...
>
> Yeah, that's what I meant.  If you only had the simple implementation in
> Integer, then the to:do: will create large integers for every iteration.
>   That is a) slow in itself, and b) creates garbage that later has to be
> collected.
>
> > Interesting. Not the case in Cuis, where there is no Compiler
> > optimization of #timesRepeat:
>
> Right --- if that did happen though, then we'd be looking at writing
> timesRepeat: [aBlock value].
>
> > Still, I wasn't explicit on what I really wanted to ask... My question
> > is: Is #bench (or bench: seconds) a good replacement for #timesRepeat:?
> > If so, does still make sense to have an optimized version of
> #timesRepeat:?
>
> If there was bench: seconds, and if that accepted a float argument so
> one could say things like bench: 1.5 and things like that, then the
> timesRepeat: improvement would be less important for this use case.
>
> The timesRepeat: improvements might still matter, but we'd have to find
> another justification for them first.
>
> Andres.
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191109/d480c832/attachment-0001.htm>