Integration of the BlockClolsure>>value primitive

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Integration of the BlockClolsure>>value primitive

Mathieu SUEN

Hi,

The last week I have made a primitive for BlockClosure>>#value and  
#value:with:….
BlockClosure is the object that behave like the BlockCoontext except  
it provide full closure.
So I would like to integrate my changes inside VMMake.
For the time being I use primitive 576 and 577.

Can you add my changes into the main stream of VMMaker?

Thanks

        Mth



Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

Andreas.Raab
 
Could you please post your changes for review first?

Cheers,
   - Andreas

Mathieu Suen wrote:

>
> Hi,
>
> The last week I have made a primitive for BlockClosure>>#value and
> #value:with:….
> BlockClosure is the object that behave like the BlockCoontext except it
> provide full closure.
> So I would like to integrate my changes inside VMMake.
> For the time being I use primitive 576 and 577.
>
> Can you add my changes into the main stream of VMMaker?
>
> Thanks
>
>     Mth
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

timrowledge
 

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?

(And no, I'm not being sarcastic this time, I actually can't remember  
for certain and I don't have time to scan mail/code to research this)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Wibble" said Pooh the stress beginning to show.


Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

johnmci
In reply to this post by Andreas.Raab

I've always thought that part of the process of providing full  
closure should be some smalltalk code to run
on existing images where it looks for code that could be affected by  
moving to full closure. The problem with
providing the primitives is that you don't know within your close  
base if you are abusing non-full closure
in interesting ways which will now break your application subtle ways.

On Jul 27, 2007, at 11:20 AM, Andreas Raab wrote:

> Could you please post your changes for review first?
>
> Cheers,
>   - Andreas
>
> Mathieu Suen wrote:
>> Hi,
>> The last week I have made a primitive for BlockClosure>>#value and  
>> #value:with:….
>> BlockClosure is the object that behave like the BlockCoontext  
>> except it provide full closure.
>> So I would like to integrate my changes inside VMMake.
>> For the time being I use primitive 576 and 577.
>> Can you add my changes into the main stream of VMMaker?
>> Thanks
>>     Mth

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

Mathieu SUEN
In reply to this post by Andreas.Raab
 
yes

        Mth



On Jul 27, 2007, at 8:20 PM, Andreas Raab wrote:

> Could you please post your changes for review first?
>
> Cheers,
>   - Andreas
>
> Mathieu Suen wrote:
>> Hi,
>> The last week I have made a primitive for BlockClosure>>#value and  
>> #value:with:….
>> BlockClosure is the object that behave like the BlockCoontext  
>> except it provide full closure.
>> So I would like to integrate my changes inside VMMake.
>> For the time being I use primitive 576 and 577.
>> Can you add my changes into the main stream of VMMaker?
>> Thanks
>>     Mth


ValuePrimitive.5.cs (13K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

Andreas.Raab
In reply to this post by johnmci
 
While I agree with both of your comments neither should stop us from
looking at the code to see if it looks reasonable.

Cheers,
   - Andreas

John M McIntosh wrote:

>
> I've always thought that part of the process of providing full closure
> should be some smalltalk code to run
> on existing images where it looks for code that could be affected by
> moving to full closure. The problem with
> providing the primitives is that you don't know within your close base
> if you are abusing non-full closure
> in interesting ways which will now break your application subtle ways.
>
> On Jul 27, 2007, at 11:20 AM, Andreas Raab wrote:
>
>> Could you please post your changes for review first?
>>
>> Cheers,
>>   - Andreas
>>
>> Mathieu Suen wrote:
>>> Hi,
>>> The last week I have made a primitive for BlockClosure>>#value and
>>> #value:with:….
>>> BlockClosure is the object that behave like the BlockCoontext except
>>> it provide full closure.
>>> So I would like to integrate my changes inside VMMake.
>>> For the time being I use primitive 576 and 577.
>>> Can you add my changes into the main stream of VMMaker?
>>> Thanks
>>>     Mth
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

Mathieu SUEN

Thanks
        Mth



On Jul 27, 2007, at 8:45 PM, Andreas Raab wrote:

> While I agree with both of your comments neither should stop us  
> from looking at the code to see if it looks reasonable.
>
> Cheers,
>   - Andreas
>
> John M McIntosh wrote:
>> I've always thought that part of the process of providing full  
>> closure should be some smalltalk code to run
>> on existing images where it looks for code that could be affected  
>> by moving to full closure. The problem with
>> providing the primitives is that you don't know within your close  
>> base if you are abusing non-full closure
>> in interesting ways which will now break your application subtle  
>> ways.
>> On Jul 27, 2007, at 11:20 AM, Andreas Raab wrote:
>>> Could you please post your changes for review first?
>>>
>>> Cheers,
>>>   - Andreas
>>>
>>> Mathieu Suen wrote:
>>>> Hi,
>>>> The last week I have made a primitive for BlockClosure>>#value  
>>>> and #value:with:….
>>>> BlockClosure is the object that behave like the BlockCoontext  
>>>> except it provide full closure.
>>>> So I would like to integrate my changes inside VMMake.
>>>> For the time being I use primitive 576 and 577.
>>>> Can you add my changes into the main stream of VMMaker?
>>>> Thanks
>>>>     Mth
>> --
>> =====================================================================
>> ======
>> John M. McIntosh <[hidden email]>
>> Corporate Smalltalk Consulting Ltd.  http://
>> www.smalltalkconsulting.com
>> =====================================================================
>> ======

Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

Marcus Denker
In reply to this post by timrowledge
 

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  --  [hidden email]
http://www.iam.unibe.ch/~denker



Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

Mathieu SUEN
 
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  --  [hidden email]
> http://www.iam.unibe.ch/~denker
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

Bryce Kampjes
 
Mathieu Suen writes:
 >  
 > Hi
 >
 > Did someone have time to look at my changes?
 > Thanks

Mathieu, I can always go through them with you at ESUG if
they don't get reviewed here before then.

Bryce
Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

Andreas.Raab
In reply to this post by Mathieu SUEN
 
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  --  [hidden email]
>> http://www.iam.unibe.ch/~denker
>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Integration of the BlockClolsure>>value primitive

Mathieu SUEN
 
Hi Andreas,

Thanks for your review.

On Aug 13, 2007, at 10:23 AM, Andreas Raab wrote:

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

Yes I could do this.

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

Ok I didn't know how to do it so I will make a named primitive

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

Yes, I didn't  know that they were a bytecode for the send of #value  
and #value: . This imply that I should add the BlockClosure in the  
special object.
For me it will be useful but it will be an other things to push in  
the image.

> It would also take the pressure of requiring an indexed primitive  
> for speed.

Ok I don't know how to make named primitive. If you have time could  
you briefly explain it.

Thanks

        Mth