problem in porting from smalltalk

> Yup, I sure did. Mostly because I was concerned about the IP aspects.
> But keep in mind that my rant was a meta rant and (in this case) pointed
> at using the name Pragma where one only has to look at
> http://www.google.com/search?q=define:+pragma to see that pragma
> describes not what these annotations are being used for and that
> therefore the "consistency" argument is really a "compatibility"
> argument, e.g., VW uses that bad name so we have to use the same bad
> name. And there is really no point in that unless you want to write a VW
> clone.

Ok.

No I don't want a VW clone (e.g., we are doing fine without
namespaces), but I want my Seaside, Magritte, Pier, etc. to be easily
portable to VW.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli wrote:
> No I don't want a VW clone (e.g., we are doing fine without
> namespaces), but I want my Seaside, Magritte, Pier, etc. to be easily
> portable to VW.

Yes, and that's exactly what I said in my meta rant: "people copying
really screwed up stuff ... just because they can't change it there and
don't want to work around the differences". In other words, you confirm
my meta rant ;-)

Cheers,
   - Andreas

> Yes, and that's exactly what I said in my meta rant: "people copying
> really screwed up stuff ... just because they can't change it there and
> don't want to work around the differences". In other words, you confirm
> my meta rant ;-)

If the name is the only thing you worry about, we can easily rename it
to something else and then put an empty subclass called Pragma into a
compatibility package. As long as the name is the only trouble causer
I see no troubles ;-)

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli wrote:
>> Yes, and that's exactly what I said in my meta rant: "people copying
>> really screwed up stuff ... just because they can't change it there and
>> don't want to work around the differences". In other words, you confirm
>> my meta rant ;-)
>
> If the name is the only thing you worry about, we can easily rename it
> to something else and then put an empty subclass called Pragma into a
> compatibility package. As long as the name is the only trouble causer
> I see no troubles ;-)

And I wrote: "Not that I personally care that much about this particular
name ..." and I meant it. After all this was a *meta* rant (that's what
these tags are good for).

Cheers,
   - Andreas

Louis LaBrunda wrote:
That does not work because in the optimized case, the block object which
is the argument to the message does not really get created at all.
Instead, there are bytecodes which conditionally jump around the code in
the block.
It would be possible (with some trickery) to extract those bytecodes
from the offending method and create a normal block with the same
functionality, but given the observation that most cases where and: or
or: are sent to a non-Boolean in error, it's probably not worth the effort.
Removing the optimization from the compiler if the argument is not a
block is quite easy, though.
Currently, the boolean messages accept either a block or a variable as
their argument, but not arbitrary expressions, which seems rather
illogical to me.
You can change the method in MessageNode which does this to read:
checkBlock: node as: nodeName from: encoder

    ^(node isKindOf: BlockNode)
        ifTrue: [(node numberOfArguments > 0)
            ifTrue:    [encoder notify: '<- ', nodeName , ' of ' ,
                    (MacroSelectors at: special) , ' must be a
0-argument block']
            ifFalse: [true]]
        ifFalse: [false]

Then the optimization only happens if the argument is a 0-argument block.

Cheers,
Hans-Martin

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

On 24.02.2006, at 22:42, Bryce Kampjes wrote:
There is a nice talk by Eliot Miranda about a system (where
the dynamic optimization is done bytecode-to-bytecode in
Smalltalk, leveraging the existing JIT as the backend for code
generation):

Bytecode-to-bytecode adaptive optimization for Smalltalk
http://video.google.com/videoplay?docid=-8988857822906068209

     Marcus