[Python-Dev] memcmp performance

[Richard Saunders]

-On [20111024 09:22], Stefan Behnel (stefan_ml at behnel.de) wrote:
>>I agree. Given that the analysis shows that the libc memcmp() is 
>>particularly fast on many Linux systems, it should be up to the Python 
>>package maintainers for these systems to set that option externally through 
>>the optimisation CFLAGS.

Indeed, this is how I constructed my Python 3.3 and Python 2.7 :
setenv CFLAGS '-fno-builtin-memcmp'
just before I configured.

I would like to revisit changing unicode_compare: adding a 
special arm for using memcmp when the "unicode kinds" are the 
same will only work in two specific instances:

(1) the strings are the same kind, the char size is 1
    * We could add THIS to unicode_compare, but it seems extremely
      specialized by itself

(2) the strings are the same kind, the char size is >1, and checking
    for equality
    * Since unicode_compare can't detect equality checking, we can't
      really add this to unicode_compare at all

The problem is, of course, that memcmp won't compare for less-than
or greater-than correctly (unless on a BIG ENDIAN machine) for
char sizes of 2 or 4.

If we wanted to put memcmp in unicodeobject.c, it would probably need
to go into PyUnicode_RichCompare (so we would have some more semantic
information).  I may try to put together a patch for that, if people
think that's a good idea?  It would be JUST adding a call to memcmp
for two instances specified above.

>From: Jeroen Ruigrok van der Werven <asmodai at in-nomine.org>
>In the same stretch, stuff like this needs to be documented. Package
>maintainers cannot be expected to follow each and every mailinglist's posts
>for nuggets of information like this. Been there, done that, it's impossible
>to keep track.

I would like to second that: the whole point of a Makefile/configuration
file is to capture knowledge like this so it doesn't get lost.

I would prefer the option would be part of a standard build Python
distributes, but as long as the information gets captured SOMEWHERE 
so that (say) Fedora Core 17 has Python 2.7 built with -fno-builtin-memcmp, 
I would be happy.


  Gooday,

  Richie

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