Mailing List Archive

> Many operations involving two literals are optimized (to a certain level). So it sort of surprises me that literal comparisons are not optimized and literal contains only convert the right operand to a constant if possible. I'd like to implement optimizations for these especially for the literal contains. There is a TODO in the ast optimizer for literal comparisons as well, and that's another reason I would like to have these added.

Though not having paid much attention to this over the years, I'm
pretty sure I've seen the topic float past from time-to-time. As I
recall, optimizing expressions involving two constants isn't a big win
in Python because that sort of expression occurs rarely in anything
other than test code. In C/C++ and its cousins, preprocessors
routinely expand names to constants, so

2 == 2

might well be seen by the compiler even though the author actually wrote

MUMBLE == FRAZZLE

If a Python programmer wrote such an expression, MUMBLE and FRAZZLE
would be names bound to a particular object, and could — theoretically
— be rebound at runtime, so such an expression couldn't safely be
optimized.

So, while you could optimize expressions involving just constants, the
benefit would be exceedingly small compared to the effort to write and
maintain the optimization code.

Skip
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4TFW3Q2X42XKP4IK263ZXOGAZ3XXYUH4/
Code of Conduct: http://python.org/psf/codeofconduct/

For the benefit of the audience on python-dev, you should also mention that this proposal and associated PR has been twice discussed and rejected on the tracker:

https://bugs.python.org/issue45907
https://bugs.python.org/issue45843

The response just given by Skip pretty much matches the comments already given by Batuhan, Pablo, and Serhiy. So far, no one who has looked at this thinks this should be done.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QQ7TBTIQSCXZ66E3WLLT77EUKIQOO3FN/
Code of Conduct: http://python.org/psf/codeofconduct/

On 28/11/2021 6:28 am, raymond.hettinger@gmail.com wrote:
> For the benefit of the audience on python-dev, you should also mention that this proposal and associated PR has been twice discussed and rejected on the tracker:
>
> https://bugs.python.org/issue45907
> https://bugs.python.org/issue45843
>
> The response just given by Skip pretty much matches the comments already given by Batuhan, Pablo, and Serhiy. So far, no one who has looked at this thinks this should be done.

That is not entirely true: https://github.com/python/cpython/pull/29639#issuecomment-974146979
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YDNHIZQOW2IWPGKLFQ6Y5LLXD42TBQMN/
Code of Conduct: http://python.org/psf/codeofconduct/

> That is not entirely true: https://github.com/python/cpython/pull/29639#issuecomment-974146979

The only places I've seen "if 0:" or "if False:" in live code was for
debugging. Optimizing that hardly seems necessary. In any case, the
original comment was about comparisons of two constants. I suppose
sweeping up all of that into a constant expression folding/elimination
step performed on the AST and/or during peephole optimization would
cover both cases.

Skip
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HW3WJUPENKNZ2NNJ52LRRM7HLFWB44XH/
Code of Conduct: http://python.org/psf/codeofconduct/

28.11.21 17:13, Skip Montanaro ????:
>> That is not entirely true: https://github.com/python/cpython/pull/29639#issuecomment-974146979
>
> The only places I've seen "if 0:" or "if False:" in live code was for
> debugging. Optimizing that hardly seems necessary. In any case, the
> original comment was about comparisons of two constants. I suppose
> sweeping up all of that into a constant expression folding/elimination
> step performed on the AST and/or during peephole optimization would
> cover both cases.

"if 0:" and "if False:" is already optimized by the compiler. The OP
proposes to optimize "2 < 1", and I cannot imagine any use case for this.

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZJPTMHWPTPWC6Q4ZKWJB5CY6LURQ75PM/
Code of Conduct: http://python.org/psf/codeofconduct/

27.11.21 15:47, Jeremiah Vivian ????:
> Many operations involving two literals are optimized (to a certain level). So it sort of surprises me that literal comparisons are not optimized and literal contains only convert the right operand to a constant if possible. I'd like to implement optimizations for these especially for the literal contains. There is a TODO in the ast optimizer for literal comparisons as well, and that's another reason I would like to have these added.

Only these operations were optimized which were necessary or very
useful. The Python parser produces only sign-less numbers, so it was
necessary to optimize unary minus to make -5 as fast as 5. Binary plus
and minus are necessary to make complex constants. "**" and "<<" are
often used in expressions for limits, masks and flags (5*10**6, 2**32-1,
1<<12). There is a benefit of computing such constants at compile time.
"*" and "/" can be used to create self-documenting constats too
(24*60*60, 1/3). And finally, indexing of bytes objects gets an ASCII
code of the character (b'a'[0]), it is useful too.

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/73G2WZDTKG57JKKUVOCFOIDEL3D75W4O/
Code of Conduct: http://python.org/psf/codeofconduct/

> On Nov 28, 2021, at 3:03 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
>
> ?28.11.21 17:13, Skip Montanaro ????:
>>> That is not entirely true: https://github.com/python/cpython/pull/29639#issuecomment-974146979
>>
>> The only places I've seen "if 0:" or "if False:" in live code was for
>> debugging. Optimizing that hardly seems necessary. In any case, the
>> original comment was about comparisons of two constants. I suppose
>> sweeping up all of that into a constant expression folding/elimination
>> step performed on the AST and/or during peephole optimization would
>> cover both cases.
>
> "if 0:" and "if False:" is already optimized by the compiler. The OP
> proposes to optimize "2 < 1", and I cannot imagine any use case for this.

I agree. I suggest we don’t add this optimization.

Eric
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JP6FF2RHDQSIOS6ZAI45S7X6UXWGPBKR/
Code of Conduct: http://python.org/psf/codeofconduct/

I am slightly surprised that it seems to be *easier* to fold selected
constant expressions than to have more generic code to fold them all.
Or at least, all those that don't contain containers, such as
    1 in [0,1,2]
Rob Cliffe

On 28/11/2021 21:10, Eric V. Smith wrote:
>> On Nov 28, 2021, at 3:03 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
>>
>> ?28.11.21 17:13, Skip Montanaro ????:
>>>> That is not entirely true: https://github.com/python/cpython/pull/29639#issuecomment-974146979
>>> The only places I've seen "if 0:" or "if False:" in live code was for
>>> debugging. Optimizing that hardly seems necessary. In any case, the
>>> original comment was about comparisons of two constants. I suppose
>>> sweeping up all of that into a constant expression folding/elimination
>>> step performed on the AST and/or during peephole optimization would
>>> cover both cases.
>> "if 0:" and "if False:" is already optimized by the compiler. The OP
>> proposes to optimize "2 < 1", and I cannot imagine any use case for this.
> I agree. I suggest we don’t add this optimization.
>
> Eric
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JP6FF2RHDQSIOS6ZAI45S7X6UXWGPBKR/
> Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LD3XHINO7VPDE5EMNFD5ON4FQIJLY4DI/
Code of Conduct: http://python.org/psf/codeofconduct/

I will frequently do simple computation with literals to make my code more
clear:

t = 2 * 3600 # 2 hours in seconds

But I see no need to optimize this kind of thing -- it would never be in a
tight loop.

-CHB


On Sun, Nov 28, 2021 at 3:06 PM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

> I am slightly surprised that it seems to be *easier* to fold selected
> constant expressions than to have more generic code to fold them all.
> Or at least, all those that don't contain containers, such as
> 1 in [0,1,2]
> Rob Cliffe
>
> On 28/11/2021 21:10, Eric V. Smith wrote:
> >> On Nov 28, 2021, at 3:03 PM, Serhiy Storchaka <storchaka@gmail.com>
> wrote:
> >>
> >> ?28.11.21 17:13, Skip Montanaro ????:
> >>>> That is not entirely true:
> https://github.com/python/cpython/pull/29639#issuecomment-974146979
> >>> The only places I've seen "if 0:" or "if False:" in live code was for
> >>> debugging. Optimizing that hardly seems necessary. In any case, the
> >>> original comment was about comparisons of two constants. I suppose
> >>> sweeping up all of that into a constant expression folding/elimination
> >>> step performed on the AST and/or during peephole optimization would
> >>> cover both cases.
> >> "if 0:" and "if False:" is already optimized by the compiler. The OP
> >> proposes to optimize "2 < 1", and I cannot imagine any use case for
> this.
> > I agree. I suggest we don’t add this optimization.
> >
> > Eric
> > _______________________________________________
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-leave@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/JP6FF2RHDQSIOS6ZAI45S7X6UXWGPBKR/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LD3XHINO7VPDE5EMNFD5ON4FQIJLY4DI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

On 11/28/2021 7:52 PM, Christopher Barker wrote:
> I will frequently do simple computation with literals to make my code
> more clear:
>
> t = 2 * 3600  # 2 hours in seconds

That is optimized as you'd hope. Tested in 3.8:

>>> dis.dis("t = 2 * 3600")
  1           0 LOAD_CONST               0 (7200)
              2 STORE_NAME               0 (t)
              4 LOAD_CONST               1 (None)
              6 RETURN_VALUE

Eric

>
> But I see no need to optimize this kind of thing -- it would never be
> in a tight loop.
>
> -CHB
>
>
> On Sun, Nov 28, 2021 at 3:06 PM Rob Cliffe via Python-Dev
> <python-dev@python.org> wrote:
>
> I am slightly surprised that it seems to be *easier* to fold selected
> constant expressions than to have more generic code to fold them all.
> Or at least, all those that don't contain containers, such as
>      1 in [0,1,2]
> Rob Cliffe
>
> On 28/11/2021 21:10, Eric V. Smith wrote:
> >> On Nov 28, 2021, at 3:03 PM, Serhiy Storchaka
> <storchaka@gmail.com> wrote:
> >>
> >> ?28.11.21 17:13, Skip Montanaro ????:
> >>>> That is not entirely true:
> https://github.com/python/cpython/pull/29639#issuecomment-974146979
> >>> The only places I've seen "if 0:" or "if False:" in live code
> was for
> >>> debugging. Optimizing that hardly seems necessary. In any
> case, the
> >>> original comment was about comparisons of two constants. I suppose
> >>> sweeping up all of that into a constant expression
> folding/elimination
> >>> step performed on the AST and/or during peephole optimization
> would
> >>> cover both cases.
> >> "if 0:" and "if False:" is already optimized by the compiler.
> The OP
> >> proposes to optimize "2 < 1", and I cannot imagine any use case
> for this.
> > I agree. I suggest we don’t add this optimization.
> >
> > Eric
> > _______________________________________________
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-leave@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/JP6FF2RHDQSIOS6ZAI45S7X6UXWGPBKR/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LD3XHINO7VPDE5EMNFD5ON4FQIJLY4DI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>
> _______________________________________________
> Python-Dev mailing list --python-dev@python.org
> To unsubscribe send an email topython-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived athttps://mail.python.org/archives/list/python-dev@python.org/message/NJWCKNV4ULEBHSLR44G3HNVROE4IAM47/
> Code of Conduct:http://python.org/psf/codeofconduct/

On Mon, Nov 29, 2021 at 10:11 AM Rob Cliffe via Python-Dev
<python-dev@python.org> wrote:
>
> I am slightly surprised that it seems to be *easier* to fold selected
> constant expressions than to have more generic code to fold them all.
> Or at least, all those that don't contain containers, such as
> 1 in [0,1,2]

This is optimized to a tuple rather than a list (and if you used a set
instead of a list, it'd be optimized to a frozenset), but the 'in'
comparison isn't optimized. The common case where it's "x in [0,1,2]"
is optimized as far as it can be.

ChrisA
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KV7E4ALZLNY7BNMCNDVLUZHPORRRMRCC/
Code of Conduct: http://python.org/psf/codeofconduct/

On 2021-11-29 00:52, Christopher Barker wrote:
> I will frequently do simple computation with literals to make my code
> more clear:
>
> t = 2 * 3600  # 2 hours in seconds
>
> But I see no need to optimize this kind of thing -- it would never be in
> a tight loop.
>
The suggestion was specifically about optimising comparison of literals
such as 1 < 2, which is not done at present, and the objection is
basically YAGNI - that kind of thing is just too rare to be worth it.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2VS4ZPFYAYVOG4BBHRWAFIEH7CU62X4B/
Code of Conduct: http://python.org/psf/codeofconduct/

Hi,

I am surprised by the insistence on this thread for excluding comparisons from constant folding.
Why should we special case comparisons? Am I missing something here?

We already constant fold a variety of expressions

0 * 7
'' * 7
True - True
True * False

(All the above are falsey)

Excluding 1 < 2 seems inconsistent.

Cheers,
Mark.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BRQHDHZKNIMMXCA5SSAW2N3D57V2ZDZJ/
Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, 29 Nov 2021 12:32:19 +0000
Mark Shannon <mark@hotpy.org> wrote:
> Hi,
>
> I am surprised by the insistence on this thread for excluding comparisons from constant folding.
> Why should we special case comparisons? Am I missing something here?

Is it actually special-cased or is it just not implemented?

IMHO at compile-time there's not much potential (for Python, which
doesn't have "true" constants). At run-time and based on
specialization, there could be.

Regards

Antoine.


>
> We already constant fold a variety of expressions
>
> 0 * 7
> '' * 7
> True - True
> True * False
>
> (All the above are falsey)
>
> Excluding 1 < 2 seems inconsistent.
>
> Cheers,
> Mark.



_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/253RQ2BTTVUEUBFAMULQBBUTMQB5EH2W/
Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Nov 29, 2021 at 12:32:19PM +0000, Mark Shannon wrote:
> Hi,
>
> I am surprised by the insistence on this thread for excluding comparisons
> from constant folding.
> Why should we special case comparisons? Am I missing something here?

We[1] are worried that the benefit gained will not be worth the
maintenance burden of constant folding comparisons. Unlike
constant-folding arithmetic expressions, the benefit for comparisons is
small: code that compares two literals e.g. `3 < 5` is probably very
rare, outside of tests. So this will help almost nobody, but still
require maintenance.

(And the tests will need to be changed, if we add this, otherwise they
will only be testing the keyhole optimizer, not the runtime comparison!)

I have no idea of how much maintenance the keyhole optimizer requires.

We have a volunteer willing to do the work (Jeremy). Do we have a core
developer willing to review their work, and mentor them if if it is not
up to standard? If not, then this conversation will go nowhere.



[1] That's an editorial "we". Personally, I don't have an opinion one
way or another :-)


--
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MUL7KTCPUGBTYZF4AXYI5UDE7UIC5ANR/
Code of Conduct: http://python.org/psf/codeofconduct/

29.11.21 14:32, Mark Shannon ????:
> Excluding  1 < 2 seems inconsistent.

It is not excluded, it is just not included. There should be reasons for
adding any feature, and the benefit should exceed the cost.

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/53Q5J2MHMQRIJL4KD5FSWRAQICDQXDUT/
Code of Conduct: http://python.org/psf/codeofconduct/

You should consider "no longer have to justify why it's not optimized"
as a clear benefit of making this change :-) This optimization is
proposed once a year for many years...

For me, any possible compilation-ahead optimization (which doesn't
break the Python semantics) is worth it ;-) It's done once, possible
even before the program is run for the first time, and then makes the
code faster.

Victor
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HEFGUVWHSN276YXEKEBOKYLUPFNLILTF/
Code of Conduct: http://python.org/psf/codeofconduct/

29.11.21 18:36, Victor Stinner ????:
> You should consider "no longer have to justify why it's not optimized"
> as a clear benefit of making this change :-) This optimization is
> proposed once a year for many years...
>
> For me, any possible compilation-ahead optimization (which doesn't
> break the Python semantics) is worth it ;-) It's done once, possible
> even before the program is run for the first time, and then makes the
> code faster.

I consider the cost of rejecting such idea (this is actually the first
time it was pushed so persistent) less than the cost of implementing and
maintaining it. The proposed PR adds around 200 lines of code. It is
almost 20% of the current size of ast_opt.c, it is not small. And just
at first look I see a flaw in it -- it will emit a BytesWarning when
compare strings and bytes. After fixing this the size will grow even
more. And there may be other issues with this code which will be found
months later. Later, when we rewrite the optimizer or change the
structure of AST we will need to update this code too, with possibility
to introduce new bugs.

On other hand, the benefit of this optimization is exact zero. It does
not make code faster, because it optimizes the code not used in real
programs.

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LOIK6ZX43QHQSNWWUSE6YE3O5YBVGJOM/
Code of Conduct: http://python.org/psf/codeofconduct/

I agree with Serhiy's analysis.

On Mon, 29 Nov 2021 at 17:10, Serhiy Storchaka <storchaka@gmail.com> wrote:

> 29.11.21 18:36, Victor Stinner ????:
> > You should consider "no longer have to justify why it's not optimized"
> > as a clear benefit of making this change :-) This optimization is
> > proposed once a year for many years...
> >
> > For me, any possible compilation-ahead optimization (which doesn't
> > break the Python semantics) is worth it ;-) It's done once, possible
> > even before the program is run for the first time, and then makes the
> > code faster.
>
> I consider the cost of rejecting such idea (this is actually the first
> time it was pushed so persistent) less than the cost of implementing and
> maintaining it. The proposed PR adds around 200 lines of code. It is
> almost 20% of the current size of ast_opt.c, it is not small. And just
> at first look I see a flaw in it -- it will emit a BytesWarning when
> compare strings and bytes. After fixing this the size will grow even
> more. And there may be other issues with this code which will be found
> months later. Later, when we rewrite the optimizer or change the
> structure of AST we will need to update this code too, with possibility
> to introduce new bugs.
>
> On other hand, the benefit of this optimization is exact zero. It does
> not make code faster, because it optimizes the code not used in real
> programs.
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LOIK6ZX43QHQSNWWUSE6YE3O5YBVGJOM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

I guess that you're talking about
https://github.com/python/cpython/pull/29810/files

To be honest, I never looked into Python/ast_opt.c. I expected a
shorter implementation, a copy/paste or a few lines additions of "x ==
y" optimization. But it seems like "1 == 1" is not optimized neither.
Oh. I made the assumptions that other operations were already
optimized.

Victor

On Mon, Nov 29, 2021 at 6:11 PM Serhiy Storchaka <storchaka@gmail.com> wrote:
>
> 29.11.21 18:36, Victor Stinner ????:
> > You should consider "no longer have to justify why it's not optimized"
> > as a clear benefit of making this change :-) This optimization is
> > proposed once a year for many years...
> >
> > For me, any possible compilation-ahead optimization (which doesn't
> > break the Python semantics) is worth it ;-) It's done once, possible
> > even before the program is run for the first time, and then makes the
> > code faster.
>
> I consider the cost of rejecting such idea (this is actually the first
> time it was pushed so persistent) less than the cost of implementing and
> maintaining it. The proposed PR adds around 200 lines of code. It is
> almost 20% of the current size of ast_opt.c, it is not small. And just
> at first look I see a flaw in it -- it will emit a BytesWarning when
> compare strings and bytes. After fixing this the size will grow even
> more. And there may be other issues with this code which will be found
> months later. Later, when we rewrite the optimizer or change the
> structure of AST we will need to update this code too, with possibility
> to introduce new bugs.
>
> On other hand, the benefit of this optimization is exact zero. It does
> not make code faster, because it optimizes the code not used in real
> programs.
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LOIK6ZX43QHQSNWWUSE6YE3O5YBVGJOM/
> Code of Conduct: http://python.org/psf/codeofconduct/



--
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7LEERBQSXAFRFZKRGHUDO4RMDI6GODLE/
Code of Conduct: http://python.org/psf/codeofconduct/

I also agree with this analysis. I’ll just add that any discussion about optimization needs to also show some data, for let’s say both contrived examples (like this one IMHO) and as real-world examples as possible. Sometimes “obvious” optimizations fool you and things actually get slower. Or they don’t speed things up as much as you think they will.

Optimizations usually involve adding complexity. I would like some sense of what we’d gain for the added complexity.

Cheers,
-Barry

> On Nov 29, 2021, at 09:04, Serhiy Storchaka <storchaka@gmail.com> wrote:
>
> 29.11.21 18:36, Victor Stinner ????:
>> You should consider "no longer have to justify why it's not optimized"
>> as a clear benefit of making this change :-) This optimization is
>> proposed once a year for many years...
>>
>> For me, any possible compilation-ahead optimization (which doesn't
>> break the Python semantics) is worth it ;-) It's done once, possible
>> even before the program is run for the first time, and then makes the
>> code faster.
>
> I consider the cost of rejecting such idea (this is actually the first
> time it was pushed so persistent) less than the cost of implementing and
> maintaining it. The proposed PR adds around 200 lines of code. It is
> almost 20% of the current size of ast_opt.c, it is not small. And just
> at first look I see a flaw in it -- it will emit a BytesWarning when
> compare strings and bytes. After fixing this the size will grow even
> more. And there may be other issues with this code which will be found
> months later. Later, when we rewrite the optimizer or change the
> structure of AST we will need to update this code too, with possibility
> to introduce new bugs.
>
> On other hand, the benefit of this optimization is exact zero. It does
> not make code faster, because it optimizes the code not used in real
> programs.
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LOIK6ZX43QHQSNWWUSE6YE3O5YBVGJOM/
> Code of Conduct: http://python.org/psf/codeofconduct/

If someone wants to experiment such optimization, there is no need to
modify the Python internal optimizer, it can be done externally:
https://faster-cpython.readthedocs.io/ast_optimizer.html

For example, I implemented many optimizations like constant
propagation and loop unrolling in my old AST fatoptimizer project:
https://github.com/vstinner/fatoptimizer/blob/master/doc/optimizations.rst

Optimizing "2 < 3" becomes more interesting when other optimizations
are implemented, like constant propagation or loop unrolling. So "x=2;
if x < 10: ..." can be optimized for example.

Victor
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DGJLWZ6TCLFC3KLN7KZ7ALMLB5QD6FSY/
Code of Conduct: http://python.org/psf/codeofconduct/

The code in the pull request is not updated and cannot be updated (though I seem to have fixed the bugs in the test in my modified CPython build). It won't merge, and I definitely believe it won't pass.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VZSDFTCYQUQUMF37FR4W6XI3C372GHCB/
Code of Conduct: http://python.org/psf/codeofconduct/