Performance of [ * ] repeat vs [ * . true ] whileTrue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Performance of [ * ] repeat vs [ * . true ] whileTrue

Henrik Nergaard
Hi,
 
Why  is “[ * ] repeat” almost twice as slow as “[ * . true ] whileTrue” ?
 
--------------------------------------------------
 
[
| n |
n := 0.
[
        [
                n := n + 1.
                n > 100000000 ifTrue: [ Error signal ]
        ] repeat
] on: Error do: [ :err | ].
 
] timeToRun "0:00:00:00.874"
 
--------------------------------------------------
 
[
| n |
n := 0.
[
        [
                n := n + 1.
                n > 100000000 ifTrue: [ Error signal ].
                true
        ] whileTrue
] on: Error do: [ :err | ].
 
] timeToRun "0:00:00:00.448"
 
 
 
Best regards,
Henrik
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Performance of [ * ] repeat vs [ * . true ] whileTrue

John Brant-2

> On Aug 14, 2016, at 4:42 PM, Henrik Nergaard <[hidden email]> wrote:
>
> Hi,
>  
> Why  is “[ * ] repeat” almost twice as slow as “[ * . true ] whileTrue” ?

#repeat isn’t optimized by the compiler like #whileTrue is. I don’t know if there is a reason for this, but most every other Smalltalk (Squeak, VW, & Dolphin) optimize the #repeat method.


John Brant
Reply | Threaded
Open this post in threaded view
|

Re: Performance of [ * ] repeat vs [ * . true ] whileTrue

Clément Béra


On Mon, Aug 15, 2016 at 12:54 AM, John Brant <[hidden email]> wrote:

> On Aug 14, 2016, at 4:42 PM, Henrik Nergaard <[hidden email]> wrote:
>
> Hi,
>
> Why  is “[ * ] repeat” almost twice as slow as “[ * . true ] whileTrue” ?

#repeat isn’t optimized by the compiler like #whileTrue is. I don’t know if there is a reason for this, but most every other Smalltalk (Squeak, VW, & Dolphin) optimize the #repeat method.


On Squeak it's optimized by default too.
 
I had an intern adding that as a bytecode compiler option and make the decompiler compliant with this. One needs to check if everything still works fine but it can be enabled. Something like: <compilerOptions: + inlineRepeat> should already work.

I think the idea was to keep limited the number of inlined messages, hence that one is not inlined by default. #timesRepeat: is not inlined either in Pharo. But then where's the limit between what you inline and what you don't... 
 
John Brant

Reply | Threaded
Open this post in threaded view
|

Re: Performance of [ * ] repeat vs [ * . true ] whileTrue

Eliot Miranda-2


On Mon, Aug 15, 2016 at 9:11 AM, Clément Bera <[hidden email]> wrote:


On Mon, Aug 15, 2016 at 12:54 AM, John Brant <[hidden email]> wrote:

> On Aug 14, 2016, at 4:42 PM, Henrik Nergaard <[hidden email]> wrote:
>
> Hi,
>
> Why  is “[ * ] repeat” almost twice as slow as “[ * . true ] whileTrue” ?

#repeat isn’t optimized by the compiler like #whileTrue is. I don’t know if there is a reason for this, but most every other Smalltalk (Squeak, VW, & Dolphin) optimize the #repeat method.


On Squeak it's optimized by default too.
 
I had an intern adding that as a bytecode compiler option and make the decompiler compliant with this. One needs to check if everything still works fine but it can be enabled. Something like: <compilerOptions: + inlineRepeat> should already work.

I think the idea was to keep limited the number of inlined messages, hence that one is not inlined by default. #timesRepeat: is not inlined either in Pharo. But then where's the limit between what you inline and what you don't... 

And arguably when we have Sista/Scorch we can reduce the number of optimized selectors, but only if we don't care about pure interpreter performance.
 
John Brant

_,,,^..^,,,_
best, Eliot