[Vm-dev] Re: A trick to speedup #become: (but not becomeForward:)

[Igor Stasenko]

On 31 July 2011 17:42, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> On 7/31/2011 17:06, Igor Stasenko wrote:
>>
>> On 31 July 2011 10:32, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>>
>>> On 7/31/2011 6:56, Igor Stasenko wrote:
>>>>
>>>> And it works! All become tests are green.
>>>> See attached for VM and image side code.
>>>
>>> Good idea. But your benchmark is a little off:
>>>
>>>> Now most interesting thing. How much speed we gain?
>>>>
>>>> Before:
>>>>
>>>> | x y |
>>>>
>>>> x := 'ab' copy.
>>>> y := 'cd' copy.
>>>>
>>>> [ 100 timesRepeat: [ x become: y ] ] timeToRun
>>>
>>> x and y should be young in the above and the performance of #become
>>> should
>>> be much faster than when they are old. To wit:
>>>
>>> [ 100 timesRepeat: [ 'ab' copy become: 'cd' copy ] ] timeToRun
>>> =>  36
>>>
>>> | x y |
>>> x := 'ab' copy.
>>> y := 'cd' copy.
>>> Smalltalk garbageCollect. "make x and y old"
>>> [ 100 timesRepeat: [ x become: y ] ] timeToRun
>>> =>    1248
>>>
>>> So I'm not sure how valid your benchmark really is.
>>>
>> It is valid, because i comparing performance of using same method
>> (#become:)
>> before and after changes.
>
> It's important to measure these things correctly, otherwise one cannot
> repeat your results. When executing the code as presented, I was entirely
> unable to recreate your results, because the code all but guarantees that x
> and y will be young. I just wanted to point that out to people who like to
> measure such things.
>
>> But of course, a heap-scanning become heavily depends where object(s)
>> located in young space or old one,
>> and performs much faster if it needs to scan only new space.
>>
>> But memory-swapping become apparently having no such dependency. It
>> only depends on object size to be swapped.
>>
>> So, okay.. for cases, when both objects residing in new space, it will
>> be not hundrends of thousands times faster but only tens thousands
>> times. :)
>> Which is still a huge advantage.
>
> Yes. And that's why I said that this is indeed a good idea if it can be made
> to work properly. I would expect that there is a need to ensure that the
> formats of the objects are the same, no?

Currently the primitive checks that object's header types are same (1
, 2, 3 words/header).
Because if their header types are different , you cannot swap memory
contents between them correctly.

An object format is not so important.

> Otherwise #becoming a
> CompiledMethod into an Array could have "interesting" consequences :-)
>

I don't think it will be more interesting than if you try to do it
with usual #become:
:)

> Cheers,
>  - Andreas

-- 
Best regards,
Igor Stasenko AKA sig.