[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: