On Wed, Dec 11, 2019, 6:40 AM Mark Shannon <m...@hotpy.org> wrote: > Another thing I would like feedback on this: > My justification for a single limit of one million across the board is to > ease memorization and learning. > Is that sufficient justification, or would differing limits be better? >
Absolutely not! The "everything is a million" is a cute little phrase that we could remember. Even then, I and most people works need to check technical references to remember what "everything" includes. And I'm sure there will be edge cases where is not immediately clear if <foo> is one of those things limited, or which limit it might hot. More real-world, different limits are relevant to different things. Moreover, as I've said, even if there are specific gains, I STRONGLY prefer setting limits to the least restrictive number possible to get that gain. Maybe it's obvious you'll never need 2**53 of something, but if the specific gains only benefits from grabbing 11 bits from a 64-bit word, make that the limit. If the specific benefit comes from packing 3 counts into the same word, make the limits 2**21, not 2**20 for a "rounder" number. Before I would move from -100 on the idea, I'd want to see a specific benefit, not just a vague speculation that "a benefit might be possible." Performance and cache locality is the obvious thing. It seems plausible, but not certain. But if you can articulate and actual security gain (I'm sceptical of that) be specific. It's not obvious why am overflow of 32 bits is a more fundamental attack vector than an overflow of 20 bits. If anything, intuition would digest the opposite. But if the threat model involves detecting overflow, doesn't 1 overflow bit and a limit of 2**31 work just as well. Maybe not, but if not, *explain* why. > Thanks once again, > Mark. > > P.S. On the subject of tradeoffs, here's a bonus question: > What, in your opinion, increase in memory consumption is acceptable for > a 1% improvement in speed, or vice versa? > _______________________________________________ > 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/FXPYPRE7RBLJXGPDI3F24L6GJFWOSMBP/ > 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/NL5LBQAIG56DVCT7JDYTZRIFNCNRROOD/ Code of Conduct: http://python.org/psf/codeofconduct/
