[Vm-dev] [Pharo-dev] shallowCopy problem on 64 bit Pharo ?

Ciprian Teodorov ciprian.teodorov at gmail.com
Tue Feb 7 02:15:41 UTC 2017


Thanks Ben,

the <primitive: 148> seems to fail something like 4-5 % with my bench (osx
10.11.6, the latest Pharo/Cog)

    # of copy calls        Failing primitive 148      Failing rate
1710 77 4,50%
3049 133 4,36%
51562 2947 5,72%
and it does not seem to fail at all with something like:

1 to: 1000 do: [:i |
    (1 to: 100000) asArray copy.
]

cheers

On Tue, Feb 7, 2017 at 12:42 AM, Ben Coman <btc at openinworld.com> wrote:

>
>
>
> On Tue, Feb 7, 2017 at 3:05 AM, Ciprian Teodorov <
> ciprian.teodorov at gmail.com> wrote:
>
>>
>> It is strange, to me it seems like the <primitive: 148> fails back to the
>> smalltalk implementation (http://bit.ly/2kjYdHv).
>> However when trying to copy a small array like #(1 2 3 4) copy I cannot
>> step-into the #shallowCopy
>> nor when I try to copy a big array like   (1 to: 100000) asArray copy
>>
>> However, when I do cmd+. while running my bench the debugger stops in the
>> shallowCopy
>>
>> is this a debugger thing ?
>>
>
> To check, can you add a transcript output next line after the primitive
> pragma?
> cheers -ben
>
>
>
>> or the primitive really fails ? -- which can explain the > 2.6 slowdown
>>
>> best regards,
>> cip
>>
>> On Mon, Feb 6, 2017 at 7:36 PM, Ciprian Teodorov <
>> ciprian.teodorov at gmail.com> wrote:
>>
>>> Thanks guys I'll will try with the latest version and I'll come back
>>> with updates.
>>>
>>>
>>> On Sun, Feb 5, 2017 at 8:25 PM, tim Rowledge <tim at rowledge.org> wrote:
>>>
>>>>
>>>>
>>>> > On 05-02-2017, at 5:08 AM, Clément Bera <bera.clement at gmail.com>
>>>> wrote:
>>>> >
>>>> > I remember there was a discussion about that somewhere but I can't
>>>> find it. I cc vm-dev they may have a clue.
>>>> >
>>>> > When copying a pointer object in 64 bits instead of 32 bits, you need
>>>> to copy twice many data, so it is going to be slower in any case.
>>>>
>>>> Err, not really. Probably. Assuming you have a 64 bit cpu etc, of
>>>> course. And dependent on details of the memory architecture outside the cpu
>>>> too - after all many systems do not need the memory chip organisation to
>>>> match the cpu word size, having multiple lanes, burst read cache loading,
>>>> even heterogenous regions (I suspect mostly in embedded systems for that,
>>>> but y’never know).
>>>>
>>>> Yes, you’re moving twice as much stuff but it will still be a single
>>>> read & write per word. After that you’re at the mercy of cache lines, write
>>>> buffers, chip specs and not to mention the Hamsters.
>>>>
>>>> tim
>>>> --
>>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>> We can rescue a hostage or bankrupt a system. Now, what would you like
>>>> us to do?
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Dr. Ciprian TEODOROV
>>> Enseignant-chercheur
>>> ENSTA Bretagne
>>>
>>> tél : 06 08 54 73 48
>>> mail : ciprian.teodorov at gmail.com
>>> www.teodorov.ro
>>>
>>
>>
>>
>> --
>> Dr. Ciprian TEODOROV
>> Enseignant-chercheur
>> ENSTA Bretagne
>>
>> tél : 06 08 54 73 48
>> mail : ciprian.teodorov at gmail.com
>> www.teodorov.ro
>>
>>
>
>


-- 
Dr. Ciprian TEODOROV
Enseignant-chercheur
ENSTA Bretagne

tél : 06 08 54 73 48
mail : ciprian.teodorov at gmail.com
www.teodorov.ro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170207/87589f64/attachment-0001.html>


More information about the Vm-dev mailing list