On Jun 23, 2013, at 6:52 PM, Scott Dial <scott+python-...@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. Raymond 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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
