[squeak-dev] Re: Inline compiler optimizations

Klaus D. Witzel klaus.witzel at cobss.com
Wed Oct 8 16:14:27 UTC 2008


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

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

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





More information about the Squeak-dev mailing list