[Vm-dev] Object basicNew vs object shallowCopy

Denis Kudriashov dionisiydk at gmail.com
Wed Aug 17 20:32:07 UTC 2016


Hi.
I measure latest VM with shallowCopy support. Copy now is much better:

object := 10 at 20.
3 timesRepeat: [ Smalltalk garbageCollect ].
result1 := [ Point x: 10 y: 20 ] benchFor: 10 seconds.

3 timesRepeat: [ Smalltalk garbageCollect ].
result2 := [ object shallowCopy ] benchFor: 10 seconds.
{result1. result2}.

"a BenchmarkResult(310,321,301 iterations in 10 seconds 2 milliseconds.
31,025,925 per second)
a BenchmarkResult(426,311,468 iterations in 10 seconds 3 milliseconds.
42,618,361 per second)"

But with "Point basicNew" it is almost same:

 "a BenchmarkResult(402,708,088 iterations in 10 seconds 2 milliseconds.
40,262,756 per second)
a BenchmarkResult(405,145,766 iterations in 10 seconds 3 milliseconds.
40,502,426 per second)"

It also improves my veryDeepCopy test which works better on preSpur VM.
(preSpur VM is still better):

m := Morph new.
r2 := [ m veryDeepCopy  ] benchFor: 10 seconds.

"a BenchmarkResult(34,007 iterations in 10 seconds 3 milliseconds. 3,400
per second)" - no shallow copy optimization

"a BenchmarkResult(43,333 iterations in 10 seconds 1 millisecond. 4,333 per
second)" - latest VM with shallow copy.

"a BenchmarkResult(52,985 iterations in 10 seconds 1 millisecond. 5,298 per
second)" - preSpur VM



2016-08-01 19:32 GMT+02:00 tim Rowledge <tim at rowledge.org>:

>
>
> > On 01-08-2016, at 12:58 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> >
> > Hi John,
> >
> >> On Jul 31, 2016, at 7:32 AM, John McIntosh <
> johnmci at smalltalkconsulting.com> wrote:
> >>
> >> So has anyone thought about pre-allocating a few commonly used objects
> during idle time?  Then grabbing that object and filling in the actual
> details when one is needed. The Squeak VM did that for method context (and
> recycled them).
> >
> > Thus only works to the extent that a particular kind if object us
> allocated all the time and to the extent that synthesizing an object is
> relatively expensive relative to filling in its slots.  This works for
> contexts above a complex object representation.  In my experience it
> doesn't work for floats either. But Cog does not allocate contexts often
> because of context-to-stack mapping and because the Spur object
> representation is simple, regular and very quick to synthesize (allocate).
>
> Yeah but with a 64-bit address space we could pre-allocate *millions* of
> objects of every class! And speculatively initialise them!
>
> Oh, wait; what do you mean we don’t have 17,592,186,044,416Mb ram in our
> Raspberry Pi’s yet?
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- A one-bit brain with a parity error.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160817/14f0e472/attachment-0001.htm


More information about the Vm-dev mailing list