A naive question about the speed optimization of anthony

Andreas Raab andreas.raab at gmx.de
Wed Apr 2 22:43:33 UTC 2003


John,

Actually I think this should be no problem. If I'm not mistaken then the
only problem you may have is if you use block-local temps which are
syntactically allowed in Squeak but not nil-ed out between evaluations of
that block. E.g., you could theoretically write something like:

	1 to: 3 do:[:i|
		| value |
		value ifNil:[value := 0].
		value := value + 1.
		result := value
	].

Which would result in 3 with the current and 1 with the BC behavior. Besides
that I *think* that there is no semantical change involved. And the above
could be found automatically as it only involves temps which are read before
written.

Can you think about any other situations which would have any change in
semantics?!

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of John M McIntosh
> Sent: Thursday, April 03, 2003 12:03 AM
> To: The general-purpose Squeak developers list
> Subject: Re: A naive question about the speed optimization of anthony
> 
> 
> Hi, actually I'll throw a question back. In some respects a 
> concern I  
> have is how that changes how an application runs. Right now 
> because you  
> lack full blocks with proper closure one can code up some smalltalk  
> that works just fine for your application right now. But after  
> introducing the VM change, why it will behave differently. 
> This is the  
> risk that we face in making the VM change, beyond performance.
> 
> So now I'm wondering if as an re-engineering challenge you 
> folks have a  
> tool that could statically evaluate blocks and decide if a 
> particular  
> block has risky behavior, thus it would need to be reviewed/retested  
> when used with VM that does proper closure.
> 
> On Tuesday, April 1, 2003, at 12:06  PM, Stephane Ducasse wrote:
> 
> > Hi
> (2) what are the problems to introduce them in Squeak (for 
> example with  
> the optimizations is seaside continuation passing style still 
> working),
> >
> > So tell me
> >
> > Stef
> > --
> ==============================================================
> ========== 
> ===
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  
> http://www.smalltalkconsulting.com
> 
> ==============================================================
> ========== 
> ===
> 
> 



More information about the Squeak-dev mailing list