Diego Calleja García said on Mon, May 19, 2003 at 10:02:22PM +0200: > > really include things like your random GNOME application. If you have > > actual numbers on how much faster doing things with a > > processor-specific libc vs. a generic libc is, that might be > > interesting. > Are you doubting i can't show numbers where compiling libc for i386 sucks > against a optimized one? Yes. This comes up constantly. If you can demonstrate a repeatable improvement in end-user experienced speed by recompiling libc, then we'll be able to have a conversation. Otherwise, read the archives; this comes up fairly often. > This: > http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02134.html > (yeah, it's crypto as you said) > shows how much optimization can matter. Do you doubt that libc (a performance-critical > library) won't be faster? Yes, I doubt it, and here's why: crypto operations, unlike almost everything else you do with your computer, are almost completely CPU bound. This makes it worthwhile to optimize them for a specific CPU (and look, that's what Debian is now doing... hurray, the system works!). Pretty much everything else is either I/O bound, to your disk or to the network, or user bound (waiting for the user to do something interesting). Most of the performance critical parts of libc (string operations, memcpy, that sort of low-level stuff), are heavily optimized already, often with hand-rolled assembly. Could libs be faster? Sure. Will it be faster enough to notice? Maybe. Will it be faster enough to warrent the serious debugging issues, archive strain, and overhead? I suspect not. The only move I've seen towards resetting the Debian x86 default architecture setting from 386 was in order to maintain C++ binary compat. with the rest of the Linux distros, and even then it was just to move to i486 (since they added syncronization ops, and fixed some processor bugs). > X, GTK; a lot of apps are dynamically linked against libc. It matters. If you think it matters, feel free to rebuild, benchmark, and offer it up for discussion. M
Attachment:
pgprtBGIu8kLi.pgp
Description: PGP signature