-On [20111024 09:22], Stefan Behnel (stefan...@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 <asmo...@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
_______________________________________________ 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
