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

Ben Coman btc at openinworld.com
Mon Feb 6 23:42:34 UTC 2017


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170207/8fcda4cf/attachment-0001.html>


More information about the Vm-dev mailing list