[Vm-dev] Re: [squeak-dev] Short-circuiting comparisons (booleanCheat) via special selectors [Was Using #= for integer comparison instead of #==]

[Igor Stasenko]

On 20 November 2010 01:43, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Igor,
>
> On Fri, Nov 19, 2010 at 2:50 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> i think that with agressive optimization, this loop can be turned into no-op.
>> or more presisely to an instruction which sets i to 100000001 :)
>
>
> Are you missing the point, which is to try and generate efficient loop code, not to optimize empty loops?  I stripped the example down to the smallest possible code (an empty loop) just to show how much better VW code is and how limited the effect of merely doing the booleanCheat:.  But loops that /can't/ be optimized away are very common in the system, and right now Cog isn't doing a great job at making these go fast.
>
>> But i wonder what kind of analysis should be applied to determine that
>> loop is bound
>> to 100000000, and there is no other side effects than just incrementing counter.
>> Btw, i think it is much easier to optimize original
>> 1 to: 100000 do:
>> since you know beforehead the loop bounds, and need only to analyze if
>> loop body has any side effects.
>
> Imagine the loop had something meaningful in it such as Set>>do:.
>>
>> In that way, it is better to analyze the code at AST level, than on
>> bytecode level, since once you turn it into bytecode,
>> you losing a precious information that loop has bounds and have no
>> choice but to strictly follow bytecode semantics.
>> While of course, Cog have not much choice, since it can't operate with
>> AST, just a bytecode.
>
> Yes, but you're missing the point.  One can still generate faster jitted code than Cog is producing now.  My message was trying to show how much more there is to be gained by a better jit code generator, not about higher-level optimization.

Yes, there is a space for improvement.
My point was, that you have even more potential for optimizations when
dealing at AST level, not bytecode level.
And one of my intents is to create a compiler which could transform
AST directly to native code.

For example, a loop bounds , since they are smallint constants, could
be turned into machine integers, so code like following:

32 <76> pushConstant: 1
a1ee2: movl $0x00000003, %eax : B8 03 00 00 00
a1ee7: pushl %eax : 50
33 <B0> send: +
a1ee8: movl %ss:0x4(%esp), %edx : 8B 54 24 04
a1eec: movl $0x0045ae64=#+, %ecx : B9 64 AE 45 00
a1ef1: call .+0xfff5e59a (0x00000490=ceSend1Args) : E8 9A E5 F5 FF
IsSendCall:
a1ef6: pushl %edx : 52
34 <68> popIntoTemp: 0
a1ef7: popl %eax : 58

could be replaced just by

inc %eax

and if loop counter passed somewhere, where it can't use optimized
value, then it can be turned back to smallint, like:

shl %eax,1
inc %eax


> best
> Eliot



-- 
Best regards,
Igor Stasenko AKA sig.