On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote: > This is an attempt to summarize some points. > > 1. Why do we have a problem, other than performance issues? > > * To maintain binary compatibility with other distributions for C++ > packages, Debian needs to use the i486+ version of atomicity.h supplied > by GCC. > * This version is significantly faster than the i386 version. > * GCC 3.2 doesn't even supply a working i386 version (GCC 3.3 does). > * This is exposed ABI (currently) and therefore cannot be solved by > multilibbing. > > 2. What performance benefits do we get as side effects of dropping 386? > > * i486 guarantees a 32-bit external data bus (386SX has a 16-bit bus.). > http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02043.html > Not sure if there's anyone programming to the data bus. :-) > * i486 has a cache, and accordingly an 'invalidate cache' instruction. > * i486 has an 'invalidate TLB entry' instruction (INVLPG). 386 requires > the flushing of the entire page table. > * i486 has the BSWAP, XADD, and CMPXCHG instructions (and possibly > others -- I haven't found a complete list). > * OpenSSL is *much* faster on i486+ than on i386. The improvements for > going to i586, i686, etc. are not that great. > http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02031.html > * The kernel is markedly faster compiled for i486+ than on i386. > Again, the improvements for subsequent chips are not as impressive. > This is at least partly *not* a tuning issue; for 386, the kernel needs > extra code whenever it writes to user pages > (http://www.cs.helsinki.fi/linux/linux-kernel/2002-13/0445.html), > has to clear the whole page table rather than using INVLPG, > and uses less efficient options rather than CMPXCHG,XADD, and > BSWAP in heavily-used code paths (including read-write semaphores). > > Other instances I've seen show a really sharp performance improvement > with i486-specific code rather than i386-specific code, and declining > benefits for each subsequent model. I'm not sure how much is tuning and > how much is architecture-specific, of course.
> Oddly, it looks like > GCC doesn't currently ever generate 486-specific instructions; they are > only (currently) of benefit to assembly programmers. Note that <bits/byteswap.h> uses asm statements to do byte swapping, and it has separate cases for i386 and i486. This file is used by <netinet/in.h> which defines htonl() and friends, and by <byteswap.h> which defines bswap_32() and friends. Compiling for the i486 will make a difference here even if GCC doesn't care itself. Richard Braakman