[Cython] Fused Types

[mark florisson]

On 2 May 2011 12:32, Stefan Behnel <stefan_ml at behnel.de> wrote:
> mark florisson, 02.05.2011 11:22:
>>
>> On 2 May 2011 11:08, Stefan Behnel wrote:
>>>
>>> Robert Bradshaw, 30.04.2011 08:16:
>>>>
>>>> On Fri, Apr 29, 2011 at 8:04 AM, mark florisson
>>>>>
>>>>> With the type matching it matches on exactly 'if src_type is
>>>>> dst_type:' so you can't use 'and' and such... perhaps I should turn
>>>>> these expression into a node with the constant value first and then
>>>>> see if the result of the entire expression is known at compile time?
>>>>
>>>> Yes, that's exactly what I was thinking you should do.
>>>
>>> For now, you could simply (try to) re-run the ConstantFolding transform
>>> after the type splitting. It will evaluate constant expressions and also
>>> drop unreachable branches from conditionals.
>>
>> Right thanks! I actually ran it on the condition only, as I overlooked
>> its branch pruning capability (sometimes I see 'if (1)' generated
>> code, so that's probably because that happens after ConstantFolding).
>
> ... or because something generates that explicitly (e.g. to simplify some
> specific code generation), but I couldn't find this with a quick grep right
> now. I once put a C for-loop into straight sequential argument unpacking
> code, so that I could "break" out of it at any point, rather than using
> gotos and labels for that. But that was only half-way hackish because that
> particular code mimics an unrolled loop anyway.
>
> In the future, Vitja's dead code removal branch will handle branch pruning
> anyway. I just put it into the ConstantFolding transform at the time as it
> fit in there quite well, and because I thought it would help also during the
> constant calculation to get rid of dead code while we're at it, e.g. in
> conditional expressions (x if c else y) or later on in combination with
> things like the FlattenInList/SwitchTransform.
>
>
>> So wouldn't it be a good idea to just insert another ConstantFolding
>> transform at the end of the pipeline also, and have it recalculate
>> constants in case it was previously determined not_a_constant?
>
> An additional run would also make sense before the optimisation steps that
> run after type analysis. Some of them can take advantage of constants,
> including those created before and during type analysis. Maybe even a third
> run right before the code generation, i.e. after the optimisations.
>
> Not sure if "not_a_constant" values can become a problem. They'll be ignored
> in the next run, only "constant_value_not_set" values will be recalculated.
> While newly created expressions will usually be virgins, new
> values/expressions that are being added to existing "not_a_constant"
> expressions may end up being ignored, even if the whole expression could
> then be condensed into a constant.

Right, in my branch I introduced a new instance variable, and if
that's true it ignores "not_a_constant" and tries to compute it
anyway, as the pruning is mandatory and at the expression was
determined "not_a_constant".

> OTOH, these cases may be rare enough to not deserve the additional
> performance penalty of looking at all expression nodes again. It may be
> better to call back into ConstantFolding explicitly when generating
> expressions at a later point, or to just calculate and set the constant
> values properly while creating the nodes.

So far (from what I've seen, I haven't actually done any benchmarks) I
think the C compiler is still like 5 times as slow as Cython.

> While you're at it, you can test if it works to reuse the same transform
> instance for all runs. That should be a tiny bit quicker, because it only
> needs to build the node dispatch table once (not that I expect it to make
> any difference, but anyway...).

Ok, sure.

> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>