Re: StepTalk - speed

[Alexander V. Diemand]

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:

 1: [|
 2: main
 3:        | ttt |
 4:        ttt := Transcript.
 5:        1 to: 3 do: [ :counter |
 6:                ttt showLine:('line ',counter stringValue).
 7:        ].
 8: ]


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:

#0000 push extern 0 (<SimpleTranscript: 10055548>)
#0002 dup
#0003 pop and store temp 0

So we have it in temporary 0

In the block, the interpreter follows the bytecode:
#0011 push temporary 0 (<SimpleTranscript: 10055548>)
#0013 push literal 3 (line )
#0015 push temporary 1 (1)
#0017 send selector 4 with 0 args (stringValue)
#001a send selector 5 with 1 args (,)
#001d send selector 6 with 1 args (showLine:)

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.

In contrast, the temporary 1 is used as the counter and at the end of
the block is on the stack and at the beginning of the next one stored
back with:
#0020 return from block
Returning '<SimpleTranscript: 10055548>' from interpreter (entry 2)
Interpreter entry 2
IP f 25
#000f pop and store temp 1

So this is a destructive bytecode (line #000f) with the side effect of
(possibly) storing another object in the temporary 1. In this case we
should remove the cached SEL.


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.

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.

I haven't dig deep enough to find the implementation of the target
object as stored in the temporaries and pushed to the stack. But it
might be easy to add the cached SEL to it.
When this already gives quite a good improvement of speed, there will be
no need to go further and change more of the design of StepTalk.

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

Things like this might already have been solved and implemented in
SmallTalk 80. Does anybody has that book at hands and could look this
up, please?


Greetings

Alex.



On Mon, 2003-11-10 at 15:25, Stefan Urbanek wrote:
> Hi again,
> 
> I was thinking a bit. Would it be OK if i do following temporary solution?
> 
> - save SEL as literal for compiled object (or write it into the bytecodes).
> - skip method lookup, and do right message send
> 
> However, I have no solution for symbolic selectors, except the one with 
> global selector map table. I do not like it much.
> 
> What do you think?
> 
> Stefan
> 
> On 2003-11-09 23:57:34 +0100 Alexander V. Diemand 
> <Alexander.Diemand@etu.unil.ch> wrote:
> 
> > Hi Stefan
> > 
> > I am still working on StepTalk and enjoy scripting with it.
> > But, it seems there is a huge bottleneck causing StepTalk to process at
> > slow speed: the address of the selector is evaluated at time of bytecode
> > interpretation (-sendSelectorAtIndex:withArgCount: in
> > STByteCodeInterpreter.m). Why isn't it possible to have all this done at
> > compile time in STCompiler? Was this a critical design decision in
> > StepTalk?
> > I am working with scripts that do iterate over hundreds of objects and
> > call subroutines in SmallTalk with them and a number of calls to classes
> > in a linked library. StepTalk is far too slow to handle complex scripts,
> > so I am forced to implement them in Objective-C.
> > 
> > I assume that having the evaluation of the selector at compile time,
> > freeze it and then just "believe" it at bytecode interpretation would
> > lead to a dramatic speed-up.
> > Have you (or somebody else) run some test on this? Where do you think is
> > the best way to hook into the system and make the necessary changes?
> > 
> > Greetings
> > 
> > Alex.
> > 
> > 
> > Alexander V. Diemand
> > Swiss Institute of Bioinformatics
> > Chemin des Boveresses 155                fon ++41 (0)79 213 05 71
> > CH-1066 Epalinges s. Lausanne            fax ++41 (0)21 692 59 45
> > Switzerland
> >

signature.asc
Description: This is a digitally signed message part