<html><body><div><div><br></div><div><br></div><div>-On [20111024 09:22], Stefan Behnel (stefan_ml@behnel.de) wrote:</div><div>>>I agree. Given that the analysis shows that the libc memcmp() is </div><div>>>particularly fast on many Linux systems, it should be up to the Python </div><div>>>package maintainers for these systems to set that option externally through </div><div>>>the optimisation CFLAGS.</div><div><br></div><div>Indeed, this is how I constructed my Python 3.3 and Python 2.7 :</div><div>setenv CFLAGS '-fno-builtin-memcmp'</div><div>just before I configured.</div><div><br></div><div>I would like to revisit changing unicode_compare: adding a </div><div>special arm for using memcmp when the "unicode kinds" are the </div><div>same will only work in two specific instances:</div><div><br></div><div>(1) the strings are the same kind, the char size is 1</div><div> * We could add THIS to unicode_compare, but it seems extremely</div><div> specialized by itself</div><div><br></div><div>(2) the strings are the same kind, the char size is >1, and checking</div><div> for equality</div><div> * Since unicode_compare can't detect equality checking, we can't</div><div> really add this to unicode_compare at all</div><div><br></div><div>The problem is, of course, that memcmp won't compare for less-than</div><div>or greater-than correctly (unless on a BIG ENDIAN machine) for</div><div>char sizes of 2 or 4.</div><div><br></div><div>If we wanted to put memcmp in unicodeobject.c, it would probably need</div><div>to go into PyUnicode_RichCompare (so we would have some more semantic</div><div>information). I may try to put together a patch for that, if people</div><div>think that's a good idea? It would be JUST adding a call to memcmp</div><div>for two instances specified above.</div><div><br></div><div>>From: Jeroen Ruigrok van der Werven <asmodai@in-nomine.org></div><div>>In the same stretch, stuff like this needs to be documented. Package</div><div>>maintainers cannot be expected to follow each and every mailinglist's posts</div><div>>for nuggets of information like this. Been there, done that, it's impossible</div><div>>to keep track.</div><div><br></div><div>I would like to second that: the whole point of a Makefile/configuration</div><div>file is to capture knowledge like this so it doesn't get lost.</div><div><br></div><div>I would prefer the option would be part of a standard build Python</div><div>distributes, but as long as the information gets captured SOMEWHERE </div><div>so that (say) Fedora Core 17 has Python 2.7 built with -fno-builtin-memcmp, </div><div>I would be happy.</div><div><br></div><div><br></div><div> Gooday,</div></div><div><br></div><div> Richie</div><div><br></div></body></html>