Chris Angelico wrote: > We have people who believe that a bit > mask will slow things down, others who claim that improved cache > locality will speed things up, and Mark asks us to please justify our > objections with numbers. But surely it's up to Mark to show numbers > first?
+1. While it would be helpful for criticisms of the PEP to be more specific and provide more of a cost-benefit analysis, the burden of proof for demonstrating the benefits provided are ultimately up to the author(s) of the PEP. We require far more justification for making a change to impose the limits in the first place than we do for maintaining the status quo. Personally, I don't think it would be reasonable to impose any of these limits without some form of concrete evidence that doing so will provide an improvement; in any combination of efficiency, performance, and/or security, as the PEP suggests would happen. But, I don't think exact numbers are needed. (I.E. adding these limits will improve performance across all Python programs by an average of 22.359%!). On Mon, Dec 9, 2019 at 7:15 PM Chris Angelico <ros...@gmail.com> wrote: > On Tue, Dec 10, 2019 at 10:51 AM Steven D'Aprano <st...@pearwood.info> > wrote: > > > > On Mon, Dec 09, 2019 at 02:12:37PM -0800, Nathaniel Smith wrote: > > > > > On 09/12/2019 2:15 pm, Chris Angelico wrote: > > > > You: "We should limit things. Stuff will be faster." > > > > Others: "Really? Because bit masking is work. It'll be slower." > > > > I'm not an expert, but the impression I've got from various discussions > > on performance over the last few years is that the single biggest > > bottleneck for CPU performance is memory locality. Cache misses are so > > expensive, and CPU instructions so fast, that memory locality is king > > and the cost of bit masking is insignificant. In other words, worrying > > about the cost of bit masking in C code is so very 1990s. > > > > I could be wrong of course: I'm not an expert. And I don't think we > > should take it for granted that this is the case, unless some experts on > > modern CPUs speak up and say that Mark is so obviously correct that a > > demonstration is unnecessary. > > And the speculation continues. > > > > > You: "Maybe we limit it somewhere else, whatever. It'll be faster." > > > > That's a totally unfair and inaccurate representation of Mark's > > position. The PEP doesn't say "let's put in arbitrary limits in random > > places for the lols", he proposed seven concrete limits and gave reasons > > for why he expects that they will improve memory efficiency, safety, > > performance or all three. > > *He expects that*. That's what I'm talking about. We have lots of > speculation and no evidence either way. > > > Having said that though, I think you are right that the PEP could do > > with a bit more detail on the current status quo and existing limits, > > and how the proposed changes will improve safety and memory use. > > Exactly. Yes, I know that I massively oversimplified things in that > post. But you nonetheless acknowledge here that we are *still* quite > lacking in any actual evidence. We have people who believe that a bit > mask will slow things down, others who claim that improved cache > locality will speed things up, and Mark asks us to please justify our > objections with numbers. But surely it's up to Mark to show numbers > first? > > ChrisA > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@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/YN2BDJFPGHTEZJRDN7LXNDAGXWXB6XRA/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/EDZOEKHLF52MG3JJ6HIVHLCGXQJRIM34/ Code of Conduct: http://python.org/psf/codeofconduct/
