Re: Dropping/splitting (proper) i386 support
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
Reply to: