[squeak-dev] Inline compiler optimizations

Hi,

does anyone already know, what the impact the inline compiler
optimizations like avoiding #ifTrue: or #to:do sends has on the VM
performance? Or, where could I disable then in order to measure it myself?

btw. some methods, especially in the exception handling code, use the
knowledge about this implicit optimizations, for example when they use
thisContext in an #ifTrue: or #whileTrue: block, which does not return
the BlockContext in that cases... :)

Hi Martin,

on Wed, 08 Oct 2008 13:55:19 +0200, you wrote:

> Hi,
>
> does anyone already know, what the impact the inline compiler
> optimizations like avoiding #ifTrue: or #to:do sends has on the VM
> performance? Or, where could I disable then in order to measure it  
> myself?

Funny :) in the past 6 months (or so), other Squeakers wanted to know  
about disabling the inlineing, albeit for different reasons.

I have created a patch for them with which inline-optimization can be  
toggled per method (using some pragma), send email if you want that .cs  
file.

When disabling all inlining, the .image only stays usable if special care  
is taken in advance for constructs like [thisContext] and #some/nextObject  
enumerations (especially those during #startUp); besides of that the  
formerly inlined methods perform very well at their message level (and you  
can even see e.g. lines with True>>#ifTrue: in the debugger ;)

> btw. some methods, especially in the exception handling code, use the
> knowledge about this implicit optimizations, for example when they use
> thisContext in an #ifTrue: or #whileTrue: block, which does not return
> the BlockContext in that cases... :)

I've not checked exceptions in particular. Also, I always inline #while*'s  
because one can run out of memory very soon if they would be performed in  
their recursive fashion ;)

>

Am 08.10.2008 um 13:55 schrieb Martin Beck:

> Hi,
>
> does anyone already know, what the impact the inline compiler
> optimizations like avoiding #ifTrue: or #to:do sends has on the VM
> performance? Or, where could I disable then in order to measure it  
> myself?

See MessageNode's code generation methods (emit*).

You can't really disable inlining of #while and #to:do: because there  
is no tail recursion optimization.

- Bert -

Hi Klaus,

Klaus D. Witzel wrote:
> Hi Martin,
>
> on Wed, 08 Oct 2008 13:55:19 +0200, you wrote:
>
> I have created a patch for them with which inline-optimization can be
> toggled per method (using some pragma), send email if you want that .cs
> file.

It'd be great, if you'd do that, please!

> When disabling all inlining, the .image only stays usable if special
> care is taken in advance for constructs like [thisContext] and
> #some/nextObject enumerations (especially those during #startUp);
> besides of that the formerly inlined methods perform very well at their
> message level (and you can even see e.g. lines with True>>#ifTrue: in
> the debugger ;)

The performance is exactly what I want to find out. I suppose the impact
of inlining such often used method should be significant but I am not
sure, whether this is true.

However, I don't think that it is a good way of programming that Squeak
relies on this compiler behavior in the places you mentioned. I'm pretty
sure it could be done without this hidden knowledge.

>> btw. some methods, especially in the exception handling code, use the
>> knowledge about this implicit optimizations, for example when they use
>> thisContext in an #ifTrue: or #whileTrue: block, which does not return
>> the BlockContext in that cases... :)
>
> I've not checked exceptions in particular. Also, I always inline
> #while*'s because one can run out of memory very soon if they would be
> performed in their recursive fashion ;)

AFAIK, that is not a real problem, because BlockContext has the #restart
primitive, which is used by #whileTrue: so that it is not recursive but
simply restarts itself after every loop step.

Regards,
Martin

On Wed, 08 Oct 2008 14:47:26 +0200, Martin Beck wrote:

Is on its way to you. *beware* of the methods listed in this my previous  
posting:

-  
http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-March/126295.html

and keep in mind that compiler changes *what*is*meant*by* [thisContext]  
depending on method-/block-level where this expression is coded.

>> When disabling all inlining, the .image only stays usable if special
>> care is taken in advance for constructs like [thisContext] and
>> #some/nextObject enumerations (especially those during #startUp);
>> besides of that the formerly inlined methods perform very well at their
>> message level (and you can even see e.g. lines with True>>#ifTrue: in
>> the debugger ;)
>
> The performance is exactly what I want to find out.

I compensate by running my notebook's CPU at the higher clock rate, but in  
general Squeak is still responsive (modulo the known CPU hogs like to many  
SystemWindows etc).

> I suppose the impact
> of inlining such often used method should be significant but I am not
> sure, whether this is true.
>
> However, I don't think that it is a good way of programming that Squeak
> relies on this compiler behavior in the places you mentioned. I'm pretty
> sure it could be done without this hidden knowledge.

Yes, I thought about that too. Perhaps in form of a primitive for each of  
the inlineable messages, similiar to the special selectors, which might  
fall through as usual. This way the compiler+decompiler wouldn't need to  
know about "macros" (the term used in the current inlining implementation).

#restart primitive, in Squeak? which .image distro/version, in 3.6-3.10 I  
haven't seen such.

> which is used by #whileTrue: so that it is not recursive but
> simply restarts itself after every loop step.
>
> Regards,
> Martin
>
>

Hi Klaus,

Klaus D. Witzel wrote:
>>> I have created a patch for them with which inline-optimization can be
>>> toggled per method (using some pragma), send email if you want that .cs
>>> file.
>>
>> It'd be great, if you'd do that, please!
Thanks alot.

>>
>> The performance is exactly what I want to find out.
>
> I compensate by running my notebook's CPU at the higher clock rate, but
> in general Squeak is still responsive (modulo the known CPU hogs like to
> many SystemWindows etc).

First tests using your changeset within the tinyBenchmarks resulted in a
80-85 percent perfomance lose. That says something.... :)
You seem to talk about the compiler implementation. That's another
story. I would want that a) the source of those macro-methods would work
without inlining at all, like #ifFalse: and #ifTrue: but not #whileTrue:
(see below) and b) every other code like BlockContext>>#ensure: (look
for thisContext, as you said) would not make usage of these Compiler
internals...
Correct, I intermixed this with some other Smalltalk implementations :).
Although Squeak only has a #restart method for contexts, it does not
have a primitive for that. Nevertheless, #whileTrue: could be
implemented non-recursive this way

BlockContext>>#whileTrue: aBlock
  self value ifFalse: [ ^ nil ].
  aBlock value.
  thisContext restart.

instead of simply defining #whileTrue: through itself by implicitly
using the compiler (as it is in my image).

Best regards,
Martin