[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