i've been wondering about this for a while, it came up a bunch when i was complining my first kernel and now i'm seeing it out on www.linuxiso.org. you can sort the distros by processor architecture:
so, i know that the i*86 are intel architectures, but whats the difference between them? are they all 32 bit? is there such thing as i486?

what's the difference between 32 and 64 bit processors anyway? what's a bit?

i know amd64 is 64 bit, but whats ppc, sparc, and alpha?

a) i486 Intel "486"
b)i586 is Intel Pentium
c)i686 is Intel Pentium 2 or Intel Pentium Pro
d)Alpha: Alpha processor from DEC
e)Sparc: Sparc processor family from SUN
f)PPC: PowerPC from IBM
g)AMD64: AMD Athlon 64 from AMD

a)-c) 32bit
d)-g) 64 bit

Bit: has a value of 0 or 1. lowest "quantity" in computer technique

i386, i486 etc are different incarnations of the x86. i386 is the 80386, the lowest end x86 cpu that can run Linux, i486 is the 80486, i586 is the original Pentium, i686 is the Penium Pro and above (inluding current processors such as the P4 and Athlon XP).

You can use software compile for the 386 on any x86, but software compiled, say, for the i686 will not work on a Pentium or below.

A 32-bit processor has a 32-bit (4 byte) data bus, registers, etc and therefore reads 4 bytes at a time. A 64-bit processors reads 8 bytes at a time. Does that make it better? It depends on the application. For text processing (emailing, programming etc), it's irrelevant since you're dealing with single characters (8-bits). For beefier stuff like video editing, ogg encoding, games etc, it may provide better performance (or it may not -- of course, the app has to be written to use 64-bit data types (i.e. doubles, not floats etc)).

As for a bit ( You really don't know what a bit is?). A "bit" is a contraction of "binary digit". It is a switch, either on (1) or off (0). This is the most basic principle of digital electronics.

The IBM/Motorola PPC is available in both 32-bit (G4 and below) and 64-bit (G5).

Sun's SPARC is also available in 32 and 64 bit. UltraSparcs are 64-bit, while older cpus are 32-bit (not that the Ultra is particularly new, mind you).

Digital's (formerly DEC) Alpha is a 64-bit cpu.

Thanks IOERROR...this info helped me alot.

I'm afraid that is a dramatic oversimplification. The size of registers mostly works, but there are many architectures on which pairs of register can be concatenated so that a processor with 32 bit registers can also have 64 bit registers.

For recent incarnations of the intel x86 architectures (and that includes the AMD x86 parts) processors can be used with either a 32 bit or 64 bit instruction sets. This does not change the width of the data bus and does not change the number of bytes read at a time.

In fact, the whole business is rather more involved than that, but glossing over the whole business with caching and virtual memory, there is a pre-fetch unit which fetches a constant amount of data when an address not in cache is required (a cache miss). So, when program execution moves on to a new address (not in any of the caches) the pre-fetcher grabs the next n bytes (whatever that is for this particular arch) in a burst. In fact recent sdrams are set up to encourage this mode of operation.

There is an internal issue of how this is organised or represented once it has been grabbed by the pre-fetcher, but the pre-fetcher grabs data in the same way however the data will be used internally.

Back in the days of the 8086/8088 (the original members of the x86 familiy) this was all rather different. The 8088 had only half the data bus width of the 8086 and needed two fetches for the 8086's one. From the programmer's perspective, both looked the same, just one was slower than the other, because of the extra cycles for a fetch.

true, but...

...but not for that reason.

Given that you can pull in the same amount of information in the same amount of time (the same bandwidth to RAM) the issue is how well the instruction sets utilise the information available to them. A 32 bit application uses 32 bits to specify an address and so uses less inforamtion to specify a collection of data that resides in ram and that should make it faster (assuming the same caching, the same interface to memory, etc).

This isn't a really a 'level playing field' however. The 64 bit x86 instruction set is more recent than the 32 bit ones and have extra improvements. The later versions tend to have more advanced versions of the simd instructions (SSE-whatever). These are of limited use, but on the occasions that are of use, they can make a masssive difference. There has also been a general 'clean-up' of an instruction set that had some interesting omissions and historical anomalies. (There is an interesting question about how much extra performance the clean-ups deliver when everything comes via a compiler - they certainly make the compiler-writer's lives easier, but it is unclear how much performance difference that makes, if any.)

So, you could say that (on an x86) 64 bit should slow the system down a bit, except when the advantages speed it up a lot. In the end, this often turns out to be more-or-less a wash.

There is another factor that needs to be taken into account that, in some circumstances makes the above discussion irrelevant. A 32 bit address only allows you to select what is, in effect, 4G of memory. If you need to address more for your application, because hard disks as so, relatively, slow, anything that allows you to keep the data in ram is going to win over having to keep moving data to and from disk.

And, of course, being a complication, the complication is a more complicated comlication than that; you may think that it is now completely clear that if you need more than 4G (in practice, more like 3.2) you need 64 bits, but there is another option. There is PAE, which uses what I'll refer to as 'hacks' to extend 32 bits somewhat in order to make a larger address space seem to be available to the system. This doesn't make an apparently unified address space of more the 4G available to an individual application, but it does make more memory available to the system. In some cases that is useless and in some cases its just as good as 'real' 64 bits.

ah, yes, but did you know that it isn't just AMD?

if you are interested, there are very good wiki pages on most architectures.

i486 is a superset of i386, similarly i586 is a superset of i486 and i686 is a superset of i586. All of them are 32 bit x86 architectures.

IIUC, actual i386 is not supported by current Linux software and where anything in current Linux refers to "i386" it actually means some minimal for Linux superset of the true i386 architecture.

AMD64, also known as x86-64, is a 64 bit architecture based on x86 architecture. Any CPU that is able to run x86-64 architecture is also able to run i686, but some i686 CPUs do not support x86-64.

CPUs that can run x86-64 programs might be faster or slower at running i686 programs vs. x86-64 programs. It depends on the individual program. If you have an x86-64 OS you can run both kinds of programs. But if you have an x86 OS, even on an x86-64 CPU, you can run only x86 programs.

Most of the performance differences are minor and most people using Linux systems run almost all programs in the same architecture as the OS, rather than try to figure out which individual programs would run faster as x86.

x86-64 programs tend to need slightly more code size because the instruction set isn't as dense and they tend to need slightly more data size because of the most basic difference between the architectures, which is that pointers take 64 bits in x86-64 and take 32 bits in x86. These larger sizes may lead to more cache misses, leading to slightly slower execution.

All x86-64 CPUs and all current x86 CPUs have SSE and related extensions to the older x86 architecture. But compilers for x86 tend to not use those features (in part for compatibility with older x86 CPUs that lack those features). In some cases the fact that the compiler used those features for x86-64 and not for x86 will make an x86-64 program much faster.

X86-64 architecture also has twice as many registers as x86. The GCC compiler is particularly bad at dealing with the register shortage of x86 (compared to some non free compilers). Some programs will run slower in x86, or might even be bigger in x86 than in x86-64, because the code fundamentally can't be compiled well with too few registers or just because GCC can't compile it well with too few registers.

X86-64 natively supports 64 integers. X86 needs extra instructions to deal with 64 bit integers. Very few programs explicitly use 64 bit integers. Most programs use 64 bit integers only when they are needed to support the use of 64 bit pointers, so the same program would use 32 bit integers in x86 mode and use slightly slower 64 bit integers in x86-64 mode, so x86 would be faster. But if a program uses 64 bit integers explicitly and regardless of architecture, it would use slightly slow 64 bit integers in x86-64 and use much slower 64 bit integers in x86. Note this effect is not the same for floating point. x86 and x86-64 both have native 64 bit floating point.

Very few programs need more than 3GB of virtual addressing. Such programs need pointers larger than 32 bits. In x86, that requires a lot of extra overhead and dynamic remapping of the address space and/or file I/O. So the program might be too difficult to even be worth writing for x86 or if written might run much more slowly than in x86-64. Data processing demands are always growing and as such programs become more common, they will represent a much more fundamental advantage of x86-64. For now, the doubled number of registers and the fact that the compiler uses the SSE are more likely to be the reason when the x86-64 version of a program is faster than x86.