[Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

Raymond Hettinger raymond.hettinger at gmail.com
Mon Jun 24 05:37:37 CEST 2013

On Jun 23, 2013, at 6:52 PM, Scott Dial <scott+python-dev at scottdial.com> wrote:

> Nowadays, cache lines are still 64 bytes but pointers are 8 bytes, and
> we still allocating on 16 byte alignment, so you have a 25% chance of a
> cache miss now.

Honestly, I'm not sure what you're arguing for or against.

The struct should to be reordered so that the leftmost data element
and left link are positioned side-by-side, and the same goes for the
rightmost element and right link.

Whether the blocksize should change is debatable.
It causes an unfortunate odd-size at the end (not good for
the final cache line), but it does improve the speed of the 
deque_index() code.  The former seems to make no difference
in timings while the latter gives a measureable speed-up.

Unfortunately, I'm losing interest in this part of the deque work.
I've already invested substantial time reading papers
(such as http://www.akkadia.org/drepper/cpumemory.pdf
and http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html),
analyzing the code, reading disassembly, and making timings.
But it isn't worth all the second guessing (and what feels like sniping).
I've worked on this code for almost a decade.  As far as I can tell, none
of the participants in this thread has ever previously shown any interest
in the deque object.  It is discouraging to have a simple parameter 
change and struct reordering reverted.  This thread has offered zero 
support or encouragement for my work.  The python-dev 
social environment appears to be degrading over time.
I only have a few hours of development time each week
and now I'm wasting that time responding to these emails
(it may go with the territory, but it is a waste none-the-less).

If it is what you guys what, then leave the code as is
(with an incorrect comment, a blocklen that is unfavorable
to indexing, and a struct order that doesn't exploit
cache locality by following the natural access patterns
in the code).

I understand that the code for Py2.7 is sensitive and understand
if you all prefer to leave it untouched. 


P.S. This has all arisen in context of my working on patch
for implementing slicing for deques.  In that context, the
code for deque_item() and deque_rotate() will become
more important than they were before.   Along the way,
I am re-examining all my existing code.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130623/aeb06fef/attachment.html>

More information about the Python-Dev mailing list