[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: StepTalk - speed

From: Stefan Urbanek
Subject: Re: StepTalk - speed
Date: Thu, 13 Nov 2003 20:50:12 +0100


I have changed Smalltalk niterpreter a bit... se below...

On 2003-11-10 17:28:40 +0100 Alexander V. Diemand <address@hidden> wrote:

Hi Stefan,

Saving the SEL directly in the bytecode seems to me the good way to go.
I have playing with the --GNU-Debug=STSending and
--GNU-Debug=STBytecodeInterpreter to see what happens within the
A simple code example:


The interpreter could "remember" the SEL "showLine:" for object ttt once
it has been resolved, probably storing it directly in the bytecode of
the temporary.
Bytecode for line 4:

A small problem with this is, that:

1. SEL is not portable between processes
2. in objective-c you should not have selectors like '+' or '/'


The interpreter does not touch temporary 0 anymore, meaning it remains
intact and could host the resolved SEL of showLine: to be reused on the
next iteration.

True, the temporary is not changed. It was done that to follow Smalltalk-80 
like way of compiled code creation.


In summary:

- bytecode "send selector" could just store the resolved SEL in the
target object on the stack. If there is already a cached SEL it simply
uses this one.
- the only bytecode, which could cause the problem of having the wrong
SEL of a new object is the "store" one. So this one should simply remove
the cached SEL, it will be re-evaluated by "send selector" the next

I have made experimental changes, so SEL is a part of the bytecode, so no 
literals are used. However, this will break ALL symbolic selectors (= ~= + - * 
/ etc.). See below.

With this your precautions of security are still valid, I hope. The
selector is evaluated at time of interpretation but is cached if the
target object does not change.

What do you think about this? Is this a feasible first solution?

Not a bad idea.



Is a modified StepTalk. Changes are experimental and they are:

- removed lookup of selector in the STEnvironment - this should be reverted 
back and made optional according to the 'full scripting' flag
- added SEL directly into bytecodes - this needs to be rewritten, because this 
solution does not allow to create portable compiled methods (for script 
objects, for example)
- because of the previous change, symbolic selectors do not work at all

There really was a speed gain >15% with this solution.

Because I do not have much time, this was just a quick hack. If someone would 
like to dig deeper into it, i can give more pointers.

Bacisally, involved parts are:

- STBytecodeInterpreter interpretBytecode:
- STCompiledCode/STCompiledMethod instance variables
- involved STCompiler methods

Let me know what do you think about that and how can it be improved/fixed. The 
source package referenced here should be considered very unstable, just to show 
new way of smalltalk interpretation.


First they ignore you, then they laugh at you, then they fight you, then you 
- Mahatma Gandhi

reply via email to

[Prev in Thread] Current Thread [Next in Thread]