nicolas cellier writes:
 > > The clean solution is to dynamically inline message sends so the
 > > simple unoptimised version of and: is as fast as the optimised
 > > version. A system with dynamicly inlined messages would be much
 > > faster for other things as well.
 > >
 > > Bryce
 > 
 > Waouh. At the VM level ? That one is far above my skills...
 > Isn't it the kind of optimization in VW VM ?
 > My understanding of efficiency problem when not open-bytecoding #and: is the 
 > creation of BlockContext.
 > Inlining send you gain creation of a MethodContext but not of a  BlockContext.
 > But if you also gain speed elsewhere, that's surely better...
 
Yes, sure at the VM level, though I believe that it's better to write
such a compiler in Smalltalk rather than in Slang, C, or C++. I wasn't
suggesting you do that kind of optimisation. Mearly suggesting that
it's better done elsewhere.

Such optimisations are not in the VW VM though it does optimise
contexts by using a context cache stack. I've been planning to use
full method inlining to allow Exupery (a native code compiler for
Squeak) to compete with VW for send performance.

Once you've inlined the and: method you'll end up with something
like:

  (firstBoolean
	ifTrue: [[secondBoolean] value]
	ifFalse: [false]
	ifOther: [firstBoolean and: [secondBoolean]])


At which point converting "[secondBoolean] value" to "secondBoolean is
a very simple optimisation. 

The ifTrue:ifFalse:ifOther is the same type test that needs to be used
for any inlined methods. Making sure that the inlining creates
intermediate that's easy to optimise will be critical, but that's a
detail problem rather than a fundamental problem.

If you can make it to either Brussels or StS, you could hear a talk
about what Exupery does now and what it's designed to eventually do.

Bryce