[Glass] Particular code that is much slower than Pharo

[Mariano Martinez Peck via Glass]

On Tue, Jan 24, 2017 at 6:00 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> 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> 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:)
>


Uhhhh :(

And do you know how hard would be to have those set of basic primitives
with this flavor ? Because at image side a subclass of Array may not be
that hard.


>
>
>> 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 ...
>
>
Well, as I said, I was trying to get a generic speed up and not a per
algorithm one, as we will have more and more.
And yeah, I can do what you say, but that requires modifying my code to
launch multiple gems and then the synchronization etc etc. It's not always
that easy to make an algorithm paralel.  In addition, I would have to go
with the 4 CPUs license.

There is no way to avoid the slowdown of the #at: related to persistent
objects faulting? I mean, even with "immediate objects" ?


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170124/c5fd8399/attachment.html>