Dropping/splitting (proper) i386 support
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. (Hmm... maybe I
should see if there's an enhancement opportunity to GCC there.)
3. How much impact will this have on users?
* Two people have reported live 386 systems (not clear if they're using
Debian):
Being used for ISDN logger and for DNS server:
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01915.html
Being used for ADSL firewall:
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01918.html
* Lots of people have reported live 486 systems using Debian.
* 486s are still being sold.
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02099.html
* Supposedly, i386 was never as popular as i486.
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02014.html
This matches my recollection that until the 486 came out, software was
generally targeted at the 286 (IBM AT).
4. Conclusion.
The i386 support is marginal, there are very few users of it, and it's
significantly impeding the rest of the distribution.
There are several ways to deal with this.
* Split into a full 'i386' architecture and a full 'i486'
architecture. Causes massive wasteful archive bloat... unless
someone enhances the architecture system, so that binary packages can
identify themselves as being the same for 386 and 486 (or different
and incompatible with ABI breakage...), and so that source packages can
identify themselves as building in the appropriate manner, and so that
dependencies are handled correctly,... This is quite difficult and
seems unlikely to happen in the near future, if ever.
* Drop i386 support entirely; 'i386' architecture becomes 'i486'.
The most dramatic option.
* Drop i386 support mostly. 'i386' architecture becomes 'i486'.
Start a 'Debian-real-i386' subproject, with a 'real-i386' architecture,
but don't require that any packages build on it in order to go into
testing or to release Debian; it would be a bonus architecture, with
a limited number of packages avaiable.
This seems to be the most immediately feasible option. Several people
have already indicated their approval of this idea. I wouldn't wait for
sarge to release, but do it ASAP. (Since C++ is already semi-broken on
386s, this would likely make things better for i386 in fact; at least
it would have a specific functioning project.)
This is assuming someone with a real i386 is willing to lead a
'Debian-real-i386' project (which wouldn't be a huge amount of work,
really; upstream support is usually pretty good, you don't have to
actually compile packages on your slow 386, just test them there, and
you don't have to worry about ABI compatibility with anyone much). If nobody
is willing then I'd say there just isn't enough support and 386 should be
dropped outright.
--Nathanael
Reply to: