Antoine Pitrou <pit...@free.fr> added the comment: > >> Before going further with this, I'd suggest you have a look at your > >> compiler settings. > > > > They are set by the configure script: > > > > gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall > > -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o > > Objects/unicodeobject.o Objects/unicodeobject.c > > Which gcc version are you using ?
$ gcc -v Utilisation des specs internes. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-mageia-linux-gnu/4.5.2/lto-wrapper Target: x86_64-mageia-linux-gnu Configuré avec: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib64 --with-bugurl=http://bugs.mageia.org/ --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c ++,ada,fortran,objc,obj-c++,java --build=x86_64-mageia-linux-gnu --host=x86_64-mageia-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-objc-gc --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp --disable-werror --with-ppl --with-cloog --with-python-dir=/lib/python2.7/site-packages --enable-lto Modèle de thread: posix gcc version 4.5.2 (GCC) > Is it possible that you have -fno-builtin enabled ? Why would it be enabled? It is not on the command line. > >> Such optimizations are normally performed by the > >> compiler and don't need to be implemented in C, making maintenance > >> harder. > > > > The fact that the glibc includes such optimization (in much more > > sophisticated form) suggests to me that many compilers don't perform > > these optimizations automically. > > When using gcc, the glibc functions are usually not used at all, > since gcc comes with a (rather large) set of builtins which are > inlined directly, if you have optimizations enabled and inlining > is found to be more efficient than calling the glibc function: What would that change? Whether the optimized memchr() comes from gcc or the glibc is not relevant here. > There is: the compiler will have alignement information available and > can also benefit from using registers instead of the stack, knowledge > about processor cache lines, etc. Such information is lost when calling > a function. The function call itself will also create some overhead. > > BTW: You should not only test the optimization with long strings, but also > with short ones (e.g. 2-15 chars) - which is a much more common case > in practice. With very short strings, the runtimes tend to be identical, which is understandable. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13134> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
