[Glass] Particular code that is much slower than Pharo

[Dale Henrichs via Glass]

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...

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 
> <mailto: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
>>     <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:)
>
>
>
> 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/20170125/907f4c4a/attachment-0001.html>