[Vm-dev] [Pharo-dev] shallowCopy problem on 64 bit Pharo ?
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
> 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
> is this a debugger thing ?
To check, can you add a transcript output next line after the primitive
> or the primitive really fails ? -- which can explain the > 2.6 slowdown
> best regards,
> 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
>> 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>
>>> > 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 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
>> ENSTA Bretagne
>> tél : 06 08 54 73 48
>> mail : ciprian.teodorov at gmail.com
> Dr. Ciprian TEODOROV
> ENSTA Bretagne
> tél : 06 08 54 73 48
> mail : ciprian.teodorov at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev