Particular code that is much slower than Pharo

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.

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

I plan look at a few other things when I get a chance  ...

Dale

On 01/24/2017 11:42 AM, Mariano Martinez Peck via Glass wrote:

| array1 another |

array1 := #( 1 2 3 4 5 6 7 8 9).

another := #(8 9 10 11 12 115 9 116 117 16 118).

10000 timesRepeat: [ 

| answer  i j selfSize anotherSize skipTestsTable |

answer := OrderedCollection new.

skipTestsTable := array1 collect: [ :each | Array new: another size ]. "all nils"

selfSize := array1 size.

anotherSize := another size.

array1 doWithIndex: [:each :selfStart |

| skipTableAtStart |

skipTableAtStart := skipTestsTable at: selfStart.

1 to: anotherSize do: [ :anotherStart|

(false or: [ (skipTableAtStart at: anotherStart) isNil]) ifTrue: [

each = (another at: anotherStart)

ifTrue: [

i := selfStart + 1.

j := anotherStart + 1.

[ (i <= selfSize and: [ j <= anotherSize ]) and: [ (array1 at: i) = (another at: j)]]

whileTrue: [

(skipTestsTable at: i) at: j put: true.

i := i + 1. 

j := j + 1. ].

answer add: { selfStart. anotherStart. (i - selfStart). i - 1 }

]  ]

]

].

answer asArray

]

] timeToRun

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Tue, Jan 24, 2017 at 5:28 PM, Dale Henrichs via Glass <[hidden email]> 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)?

 

I plan look at a few other things when I get a chance  ...

Thanks! My process is taking hours on GemStone :(

Thanks for your answer.

 

Dale

On 01/24/2017 11:42 AM, Mariano Martinez Peck via Glass wrote:

| array1 another |

array1 := #( 1 2 3 4 5 6 7 8 9).

another := #(8 9 10 11 12 115 9 116 117 16 118).

10000 timesRepeat: [ 

| answer  i j selfSize anotherSize skipTestsTable |

answer := OrderedCollection new.

skipTestsTable := array1 collect: [ :each | Array new: another size ]. "all nils"

selfSize := array1 size.

anotherSize := another size.

array1 doWithIndex: [:each :selfStart |

| skipTableAtStart |

skipTableAtStart := skipTestsTable at: selfStart.

1 to: anotherSize do: [ :anotherStart|

(false or: [ (skipTableAtStart at: anotherStart) isNil]) ifTrue: [

each = (another at: anotherStart)

ifTrue: [

i := selfStart + 1.

j := anotherStart + 1.

[ (i <= selfSize and: [ j <= anotherSize ]) and: [ (array1 at: i) = (another at: j)]]

whileTrue: [

(skipTestsTable at: i) at: j put: true.

i := i + 1. 

j := j + 1. ].

answer add: { selfStart. anotherStart. (i - selfStart). i - 1 }

]  ]

]

].

answer asArray

]

] timeToRun

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

On 01/24/2017 12:43 PM, Mariano Martinez Peck wrote:

On Tue, Jan 24, 2017 at 5:28 PM, Dale Henrichs via Glass <[hidden email]> 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 ...

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 <[hidden email]> 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 <[hidden email]> 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