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

[Gregory P. Smith]

Your work is great! I even agree with the changes on a coding best
practices level.

It's just that it belongs on the default (3.4) branch as it is an
enhancement, not a bug fix.

We don't do new things on release branches.

I agree that can be extremely frustrating at times, knowing that code won't
see the light of day for most users for years, but it is what has always
kept the Python project stable.

-gps
 On Jun 23, 2013 8:38 PM, "Raymond Hettinger" <raymond.hettinger at gmail.com>
wrote:

>
> 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.
>
>
>
> 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130623/b7dcc8a7/attachment.html>