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. Failing that, I think it would be good for the PEP to give some evidence that more compact data structures will be faster despite the cost of bit masking: references to reliable sources (let's say, a similar discussion on the Linux kernel mailing list), or some sample C code that skeptics can run. > > 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. > > Others: "Will it? How much faster?" > > You: "It'll be faster." > > Mark, possibly you want to re-frame the PEP to be more like "this is > good for correctness and enabling robust reasoning about the > interpreter, which has a variety of benefits (and possibly speed will > be one of them eventually)"? My impression is that you see speedups as > a secondary motivation, while other people are getting the impression > that speedups are the entire motivation, so one way or the other the > text is confusing people. In fairness to Mark, the PEP is *already* framed in terms of safety and memory use. One has to read all the way to literally the very last sentence of the "Motivation" sentence before "speed" is mentioned: "There is also the potential for a more efficient instruction format, speeding up interpreter dispatch." To get to that point, you have to go past: - at least five references to efficiency; - at least four references to safety (vulnerability to overflow); - a reference to memory locality being the bottleneck on modern CPUs. In the rest of the document, Mark refers to speed three more times: - "instructions can be represented in a compact 64 bit form allowing very fast passes over the instruction sequence." - "Using super-instructions would make that the 32 bit format almost as compact as the 16 bit format, and significantly faster." - and a reference to optionally switching to a saturating ref count mechanism, which would allow the use of unlimited memory but would be "a little bit slower". (The above counts are based on Mark's initial post to the list, archived here: https://mail.python.org/archives/list/python-dev@python.org/thread/QM4QUJOBQORN5WJ2WZ4RVSHSQG52VKCQ/#QM4QUJOBQORN5WJ2WZ4RVSHSQG52VKCQ and may not reflect the current state of the PEP.) 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. -- Steven _______________________________________________ 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/2YRB5T2WTTFMXKRK5SCGTDN7OG4VL7XW/ Code of Conduct: http://python.org/psf/codeofconduct/
