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

[Juan Vuletich]

Hi,

(inline)

On 11/7/2019 7:54 PM, Andres Valloud via Cuis-dev wrote:
> No, I had not looked at #bench.  I did some experiments here, and it 
> looks like it could be improved too, for really fast blocks like [2+3] 
> the measured speed difference is on the order of 30%.
>
> Moreover, I think it would be nicer if bench did a GC before starting 
> the measurement.  In some other worlds, I also saw that such 
> measurement methods would go to the trouble of ensuring as far as 
> possible that the code under consideration was already jitted before 
> the measurement begins.  I suppose that helps in very large blocks of 
> code or that perhaps do not run many iteration.  See attached and let 
> me know what you think.

Agreed on all three points. Your version is a nice improvement.

> The benchmarks I was running were trying to evaluate variations on 
> code that uses smallintegers a lot.  So either I would have to 
> increase the repetitions of the code under consideration inside the 
> timesRepeat: to minimize the overhead (that makes workspaces rather 
> verbose and repetitive), or I would have to consider the overhead 
> explicitly and start the subtraction game.  Part of what motivated the 
> improvement in timesRepeat: was to lower the relative overhead so 
> repeating code in workspaces or manually accounting for the 
> timesRepeat: overhead would become less necessary for the sake of 
> measurement precision.
>
> I was a bit surprised I could get it to run 50% faster, I wasn't 
> expecting that.  For contrast, in other worlds, timesRepeat: is also 
> optimized by the Smalltalk compiler.  This introduces some kinks.
>
> 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...

> Second, timesRepeat: is only optimized when it's followed by an 
> explicit, literal block, e.g.:
>
>     10 timesRepeat: [self blah]
>
> rather than
>
>     10 timesRepeat: aBlock
>
> So, in those contexts, sometimes it's necessary to write code like 
> this instead to enable the compiler optimization:
>
>     10 timesRepeat: [aBlock value]
>
> If the overhead of timesRepeat: is minimized, perhaps the Smalltalk 
> compiler optimization is unnecessary.
>
> Andres.

Interesting. Not the case in Cuis, where there is no Compiler 
optimization of #timesRepeat:

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

>
> On 11/7/19 14:08, Juan Vuletich via Cuis-dev wrote:
>> Hi, Andrés, Folks,
>>
>> I was thinking about the need you see for a faster implementation of 
>> #timesRepeat:. I guess you are using it for benchmarking, right? I 
>> also guess you are benchmarking some code that takes very little time 
>> to run, to make the overhead of #timesRepeat: noticeable.
>>
>> If that is the case, have you looked at #bench? It was brought from 
>> Squeak, and it is the 'standard' way of benchmarking small pieces of 
>> code.
>>
>> Cheers,
>>

Thanks,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich