[Vm-dev] Integration of the BlockClolsure>>value primitive

[Andreas Raab]

Yes, I did. A few questions:

1) Why didn't you recycle prims 186 and 187? They are marked as "old 
closure primitives" but I don't think they have ever being used. Seems a 
bit more to the point than adding two new prim indexes.

2) Why indexed prims to begin with? I'd rather have named ones to start 
out with because it seems that there is quite some possibility that 
these prims might be changed again and then we get into troubles with 
the prim indexes. I would recommend to use named prims until there is a 
mainstream version of closures and then (if necessary) decide on which 
prim indexes to use.

3) Is there a reason why these prims aren't shortcut from 
bytecodePrimValue? If speed is the main point I'd expect that a quick 
type check for BlockClosure+primClosureValue outperforms the current 
implementation by far. It would also take the pressure of requiring an 
indexed primitive for speed.

Cheers,
   - Andreas

Mathieu Suen wrote:
> 
> Hi
> 
> Did someone have time to look at my changes?
> Thanks
> 
>     Mth
> 
> 
> 
> On Aug 5, 2007, at 8:35 PM, Marcus Denker wrote:
> 
>>
>> On 27.07.2007, at 20:24, tim Rowledge wrote:
>>
>>>
>>> On 27-Jul-07, at 11:20 AM, Andreas Raab wrote:
>>>
>>>> Could you please post your changes for review first?
>>>
>>> And didn't we already provide some closure handling prims a couple 
>>> (at least) of years ago as a result of Anthony Hannan's work? Wasn't 
>>> the new compiler supposed to use them?
>>
>> Yes, the Anthony added 189, this was added to the 3.6 vmmaker, if I 
>> remember correctly.
>> This is for Object>>#executeMethod, the speedup is substancial... but 
>> then, the #value
>> of BlockClosure remained a normal method:
>>
>> value
>>     "Evaluate the block with no args. Fail if the block expects other 
>> than 0 arguments."
>>
>>     ^ environment executeMethod: method
>>
>> vs. the one on BlockContext:
>>
>> value
>>     "Primitive. Evaluate the block represented by the receiver. Fail 
>> if the
>>     block expects any arguments or if the block is already being 
>> executed.
>>     Optional. No Lookup. See Object documentation whatIsAPrimitive."
>>
>>     <primitive: 81>
>>     ^self valueWithArguments: #()
>>
>> So for Closures, a #value requires right now a method invocation, a 
>> lookup
>> and then prim 189. Math implemented a primitive for BlockContext>>#value,
>> and the speedup is noticable (we should habe benchmarks somewhere).
>>
>> We are looking into other things to speedup. e.g, BlockClosures contains
>> a method, on #value this method is evaluated, which means that a context
>> is created. BlockContexts are pre-allocated at compiletime instead. So 
>> for
>> BlockClosures beeing comparabel to BlockContexts, it is very important
>> to make sure that the context-cache is not flushed. The cache is right 
>> now
>> flushed far too often, e.g. on blockCopy:, which is send to 
>> thisContext, and
>> especially for the NewCompiler code on accessing the closure environment
>> (which is done with message sends to thisContext).
>>
>> With some care (and the right bytecodes) this can be improved 
>> dramatically it seems.
>>
>> Another thing that makes Closures slow are accesses of outer temp 
>> variables.
>> They are done with message sends right now. Having bytecodes for these 
>> would
>> make sense, too.
>>
>> Just avoiding context cache flushes + the #value primitive seem to get 
>> some
>> impressive performance improvement already.... we need to do some more
>> extensive benchmarking, but is lools quite good already.
>>
>>
>>     Marcus
>> -- 
>> Marcus Denker  --  denker at iam.unibe.ch
>> http://www.iam.unibe.ch/~denker
>>
>>
>>
>