[Vm-dev] Re: A trick to speedup #become: (but not becomeForward:)
siguctua at gmail.com
Sun Jul 31 15:55:06 UTC 2011
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?
>>>> | 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
>>> 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
>> 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:
> - Andreas
Igor Stasenko AKA sig.
More information about the Vm-dev