[Glass] Particular code that is much slower than Pharo

[Mariano Martinez Peck via Glass]

On Wed, Jan 25, 2017 at 4:06 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Mariano,
>
> In today's staff meeting we discussed the possibility of optimizing #at:
> for temporary Arrays and we came to the conclusion that we should be able
> to improve the performance of simple primitives (like #at:) for small
> objects -- smaller than ~2028 slots.
>
> I've submitted a feature request on your behalf, internal bug #46644
> "Optimize selected simple primitives for small temporary objects (i.e.,
> Array>>#at:)" and any improvements we make will be in 3.4.
>
> If anyone else has seen performance degradation for a simple primitive,
> now would be a good time to nominate the primitive for consideration...
>


Hi Dale,

Thanks for the feature request. I was starting to worry about performance :(
Let me ask: when you sat "temporary objects" you mean that the optimization
will be possible only when all the contents of the array are NOT persistent
objects?  or when the Array object itself is not persistent? I guess the
former, but just to confirm.

BTW, do you have an estimation of the next release 3.4 with such an
improvement?



> Dale
>
> On 01/24/2017 05:18 PM, Mariano Martinez Peck wrote:
>
>
>
> 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
>
>
>


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