Re: StepTalk - speed

[Stefan Urbanek]

Hi,

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

On 2003-11-10 17:28:40 +0100 Alexander V. Diemand 
<Alexander.Diemand@etu.unil.ch> 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
> interpreter.
> A simple code example:
<snip>
> 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 '/'

<snip>
> 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.

<snip>

> 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
> time.

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.

Here:

http://stefan.agentfarms.net/Download/GNUstep/StepTalk-20031113.tar.gz

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.

Stefan
--
http://stefan.agentfarms.net

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