[Glass] Particular code that is much slower than Pharo
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Tue Jan 24 13:00:23 PST 2017
On 01/24/2017 12:43 PM, Mariano Martinez Peck wrote:
>
>
> On Tue, Jan 24, 2017 at 5:28 PM, Dale Henrichs via Glass
> <glass at lists.gemtalksystems.com
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
> I ran this test using GemStone 3.4.0 and Pharo6.0 on the same
> hardware and came out as only 2x slower: 79ms (G/S) vs 36ms
> (pharo) .... Allen (our vm guy) thought that 3.3 might be a bit
> faster than 3.2 and sure enough, a run on 3.2 came up with 111ms
> (3x slower). No code gen changes have been made in 3.4.0 so the
> timings are similar.
>
>
> mmmm I am getting between 22ms and 24ms in Pharo, and around 85 on
> GemStone 3.2.9.
>
> GemStone is going to be doing a bit more work for #at: than Pharo,
> since we have to worry about faulting in objects and that costs a
> bit more ...
>
>
> mmmm but in this case the contents of the Array are not persistent
> objects (not even objects as they are smallintegers)
>
> Isn't there a particular Array subclass with an override of #at: which
> uses a different primitive that does not takes care of faulting
> objects (it assumes the objects are not persistent)?
No we don't:)
>
> I plan look at a few other things when I get a chance ...
>
>
> Thanks! My process is taking hours on GemStone :(
>
Have you thought of parallelizing the algorithm? If you can, you could
load up all of the cpus on your machine and shorten the elapsed time ...
Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170124/1927ceb0/attachment.html>
More information about the Glass
mailing list