[Cuis-dev] usefulness of a faster #timesRepeat?
juan at jvuletich.org
Fri Nov 8 08:40:14 PST 2019
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
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.
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
More information about the Cuis-dev