headers
Martin Beck | 8 Oct 13:52
Favicon

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... :)
Permalink | Reply |
headers
Klaus D. Witzel | 8 Oct 14:33

Re: Inline compiler optimizations

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
(Continue reading)

Permalink | Reply |
headers
Martin Beck | 8 Oct 14:47
Favicon

Re: Re: Inline compiler optimizations

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
(Continue reading)

Permalink | Reply |
headers
Klaus D. Witzel | 8 Oct 18:14

Re: Inline compiler optimizations

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

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

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 ;)
(Continue reading)

Permalink | Reply |
headers
Martin Beck | 8 Oct 19:15
Favicon

Re: Re: Inline compiler optimizations

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

>> 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
(Continue reading)

Permalink | Reply |
headers
Bert Freudenberg | 8 Oct 14:42

Re: Inline compiler optimizations


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 -
Permalink | Reply |

Gmane