Mark wrote, in reply to me: > On 09/12/2019 3:01 pm, Paddy McCarthy wrote: > > "Bear in mind that the costs of higher limits are paid by everyone, but > > the benefits are gained by few." > > > > Is there some evidence for the above statement? One of the issues with C > > programming is the need for limits Its hard to choose the right limits > > leading to so many failures. You propose limiting Python for performance > > gains but loose in ease of use and security. > > How does this make anything less secure? > Many basic exploits have components taking advantage of limits known as buffer overflows
Suppose we can improve the interpreter in such a way that it takes > advantage of the one million bytecode per code object and speeds it up > by 0.1% (I can do a *lot* better than that). > What would the performance gain save globally? $100k, $1M p.a.? > What does it cost? A few developer hours. You are looking to unproven execution gains. Adding an arbitrary limit might make it 0.1% faster to get the *wrong *result . Optimisation isn't just speedThe less mind-clutter spent on such* micro optimisations* might leave one able to think of a better algorithm or a better data structure that could give thousands of % speedups. You should only quote C or C++ compiler limitations as a warning of what *not *to do. Python wins by being different; by being more orthoganal; by having *less *arbitrary restrictions. Case in point: http://paddy3118.blogspot.com/2019/11/quasi-random-sobol-sequence.html Itook decade old C++ library, converted it to straight python, Python allowed me to see the opportunity for improvement leading to a Python version that is half the speed of the C++ code and generates points on demand. That's how Python wins big time. Having to worry about stifling limits is the wrong direction for the language to take. On Mon, 9 Dec 2019 at 21:26, David Mertz <me...@gnosis.cx> wrote: > I think a much more sensible approach than mandating a limit because "who > knows, it might speed something up" would be finding the speedup first. > > Probably that means one limit at a time too. E.g. maybe some patch imposes > the 1 million LOC limit and demonstrates a repeatable benchmark improvement > because of some coffee change that allows. That cold be interesting. > > Even them, I wouldn't want some arbitrary round number just for its own > sake. For example, if taking 10 bits away from a word that holds a LOC > index speeds something up, make the LOC limit 4,194,304 (2**22)... Maybe. > If you only need 9 bits for that use, make the limit twice as much. > > On Mon, Dec 9, 2019, 12:53 PM Mark Shannon <m...@hotpy.org> wrote: > >> >> On 09/12/2019 2:15 pm, Chris Angelico wrote: >> > On Tue, Dec 10, 2019 at 1:09 AM Mark Shannon <m...@hotpy.org> wrote: >> >> Bear in mind that the costs of higher limits are paid by everyone, but >> >> the benefits are gained by few. >> > >> > Can we get some stats on what the costs of higher limits (or having no >> > limit at all) is? Or, putting it the other way: Since CPython >> > currently does not enforce limits, what are the benefits of placing >> > those limits? Merely having a limit doesn't in itself give a benefit >> > (and is a (minor) cost); it would help the discussion if we knew >> > exactly WHAT the costs of the higher limits were. >> >> Given there is an infinite number of potential optimizations that it >> would enable, it is a bit hard to put a number on it :) >> >> It is also impossible to put precise numbers on the speedups of a >> particular optimizations unless it is implemented. I suspect no one is >> going to do that unless paid to do so, or are guaranteed that the work >> won't be thrown away because the PEP is rejected. >> >> Cheers, >> Mark. >> >> > >> > 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/4IKBEMNGC5DZXOAR555ZUGNJGWSFV3QI/ >> > 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/BWTOEHKYZ3NES4XPZA7QA57UHTVGRMQZ/ >> 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/MAOXN66JYZAN4L4ER6SH43TP3YMKHCVY/ > 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/LBAQILUUD2WKWOPQJ5DEAVQOPYNJ23H2/ Code of Conduct: http://python.org/psf/codeofconduct/
