I've been wondering about this. Ever since the first Pentium processors hit the market back in the 90's, computers have been using at least i586 architecture - most computers in use nowadays are i686, mind you. It makes no sense to compile the kernel and all the applications in such a major distros like Ubuntu or Fedora to not utilize even basic Pentium capabilities from get-go. Especially considering that there is no fear that such a distro would end up in old 386 or 486 computers when recommended system requirements are already in that i686 range. There are specialized distros to utilize old hardware, no need to tie down mainstream distros aimed for mainstream computers for that.

Wouldn't it be time for some major change across the field already?

i386 is used primarily for maximum compatibility. There has occasionally been some deviations from the standards with some CPUs which can cause higher optimized binaries to fail even if the CPU is supposedly running at that architecture. For example, I have an AMD i686 CPU in one of my laptops that cannot reliably run i686 binaries, I can't use anything beyond i586 without the machine becoming unstable.

Of course, even beyond the issue of compatibility, the fact of the matter is that there very little performance to be gained by building for i686 vs i386. The only time you are really going to get noticeable optimization results is by building for your specific CPU, not just the processor family it belongs to (and obviously that can't be done for a binary distribution).

Even then, many people don't feel it is worth the effort. If a person is that concerned with CPU optimizations, then they will probably go with Gentoo.

Yes I understand that part about i686 which apparently causes some fringe between SSE3 vs. 3DNow! on some later processors, but what's wrong with not using i586 across the range? Pentium was tremendous improvement over older architectures. Sure it may seem like minor issue with modern clock speeds when only 8Mhz is needed to run your email, but there is a lot of computing power wasted.

Some distributions are starting to build for i486 (like Slackware) but there is really no noticeable performance increase by building for anything higher. You can try for yourself if you like, under most conditions the performance of a i486 binary is going to be essentially identical to a i686. Not enough of an increase to be humanly perceptible in the majority of cases.

The only way you are going to get a real performance increase is to tune the optimization much tighter than you can do in a binary distribution that is designed to run on any machine you throw at it. I build all the software on my machine with "-O2 -pipe -mfpmath=sse -march=pentium4" and even then, it is very rare for me to encounter an application that actually has a noticeable performance increase over the bog standard i386 version (the only one that jumps to mind is Wine, which runs considerably faster for me optimized).

WINE was the reason why I started this thread. I tried Ubuntu 8.04 for a few days and where HoI2 on SUSE ran faster than on XP, it was unplayable to the point of instability on Ubuntu. Since X settings, computer and version of WINE were the same the only differenting factor was the compilation architecture of WINE package. Compiling WINE from sources made it usable in Ubuntu. I did some digging and this applies to every processor intensive application - not a surprise, really.
You are also bound to see drastic performance improvements in GIMP with large images i386 vs i586. Not to even mention performance gain in Blender. Linux is going to slap itself hard performance-wise, if popular distros keep doing the wrong thing.
Let's face it: Windows XP SP3 is faster than Ubuntu 8.04 on the same hardware but slower than Gentoo and about on par with openSUSE. Getting a message to would-be users about how great Linux is will not be easy if it's not great.

This long and no further replies? I'm stunned. I honestly thought that Linux was about communal improvement, discussion about its flaws, what would be good for it and definately not some ridiculous fanboy crap where stupid geeks just mumble "oh it's great, u won't see a difference, M$ is evul lol" without any clue what they are talking about. Like anyone would see a performance difference in some goddamn vim editor, word processor or slight GIMPing of a image to not look like a desperate nerd in the Facebook on a 3.2Ghz dual-core machine when SSE & MMX support is dropped for "compatibility". Retards.

[this bit was entirely unnecessary]

You don't have to be pretentious about this. Read the rules on language:
http://www.linuxquestions.org/rules.php

Like MS3FGX said, too, compatibility is the key. Think of how old some programs are---the Bourne shell, vi, etc. Some of these might still have perfect, untouched code in them from back in the day where Pentiums did not exist. Maybe since then there hasn't been a need to modify some parts of these programs, since they were written really well. Compiling the code written for i386 as i686 executables might break something, leading to bugs. Just a thought.

Plus, some people might not care about this ("if it isn't broken, don't fix it"). Sure upgrading this would be fine, but who knows what kind of stuff it would cause. Think about migrating 32-bit code to run as 64-bit executables: not so simple.

-AM

If you have a 64 bit x86_64 architecture, the packages will be built for 64 bits. Years ago I used Mandrake Linux. It's packages were built for the Pentium arch.

Just because you don't use it, don't assume that nobody does. There are loads of old 386's happily ticking away out there (i have one running slackware and an even older 286 in the attic). Compiling for higher arch's would break compatibility with older chips for very little performance gain.

Maybe it's assumed that anyone with the level of knowledge to know about processor architecture is competant enough to compile the source of whatever application they are interested in fine tuning themselves.

If i understand correctly, most binary packages compile for x86_64 have not been optimized to make use of 64bit processors. I saw no performance gain at all in using a 64bit os and switched back to 32bit.

Compatibility is the reason - and there are distributions which are built for i686.
If you really care - use a "distribution" like Gentoo - and everything fits your machine.
I can understand your point on wine and the Ubuntu example and multimedia in general - I hit this too.

That is the reason why I'm using Gentoo - and the reason why I'll make the effort to build yet another optimized system (Gentoo) which fits the notebook my father and mother are using.
Initially I had installed Ubuntu - because it was fast and easy to install and because it works (almost) flawlessly.
But even though it is a pretty fast machine (AMD Athlon XP 1600 - or so...) it feels (and is) _very_ slow compared to my notebook with almost identical Specs. and which is running Gentoo.
Every time I have to use the Ubuntu-machine I notice the (to me) huge difference in speed.
My machine will run for about a full day or even two - then the optimized system for the AMD-machine will be ready.
But not everyone is willing to go that far - I know my way around in Gentoo, but this took some time and it still takes at least the time to build and sometimes a bit more to figure out glitches and errors.
A binary distro just works - if it is slow may often not matter much. What matters more is: almost everyone can install and use it.
He/she should not blame that "being slow" on linux in general though...

I echo the sentiments expressed here. I use Debian based desktop systems for most of my work and, generally speaking, they are more than adequate for my needs. Debian does have many kernels available for specific architectures, including i686, as well as many others. But for most systems, where a single kernel is provided, it makes sense to start with something that is likely to work with a wide variety of hardware.

For those who want to extract every possible ounce of performance, you can get sources, even in most binary based distributions, and then compile or recompile those sources where you feel that there might be a difference. I have done this in the past, and generally there is very little difference in performance. I find a much greater gain in performance by carefully selecting only those services that I actually plan to use, and disable everything else. That first level of customization gains me noticeable improvements in resource usage and responsiveness. The distributions that do not enable numerous services by default tend to provide a more responsive base system.

Beyond that, performing tasks like disk optimization and other tuning parameters provide additional speed and capabilities. Frankly, though, for my purposes, in 95% of the cases, simply turning off services that I do not need provide me with acceptable performance, even on my eight year old Dell Dimension 4100, a desktop system that had pretty good performance in the early years, but is showing signs of its age. On that box, I frequently resort to using light weight desktop managers or even just a simple window manager, though KDE and GNOME still continue to function, just a bit slower than they did when the aging 4100 was in its prime.

On my newer systems, I generally do very little to modify the default setups because they provide me, as installed, with adequate performance.

If you really have performance concerns, start by tuning the services that you have activated. If that does not provide sufficient improvement, look toward optimizing your disk and memory usage. If that still does not provide enough improvement, look into other system tuning aspects. If you still want to extract further improvements, then look into, as a last step, downloading sources for either the kernel or specific applications where you need better resource use, and compile with optimizations suited to your specific environment. I maintain that these last changes will result in the least amount of incremental gain, so I suggest trying them last, and only as a last resort after you have first optimized the services that you actually use, followed by disk and memory optimization.

The fact of the matter is that most standard configurations are reasonable compromises for every day use, but there are steps that you can take to improve specific scenarios. Since those scenarios vary from person to person, it is best to research your own specific needs and tailor your customizations to those needs. My recommendation is to approach this in the order I have suggested.

Regarding Gentoo Linux, a distribution specifically mentioned containing compiled optimizations, I do indeed find it to be among the fastest system available. Compared to Debian or Arch Linux systems, I personally find that it gives me very little, if any, gain over Debian or Arch, but takes a lot of work initially to get it all set up. Debian gives me a reasonable environment to start with. Arch Linux gives me a tighter environment, mostly because it includes only what I specifically install, and it also enables only the services that I include. Again, it takes a bit more work initially, but it does result in immediately noticeable improvement over just about all other systems.

To summarize, a Debian base system or a Debian derivative, provides a very reasonable and easy to configure base system. Tuning enabled services is usually enough to make it quite responsive. An Arch Linux system provides a very nicely tuned base system, but it does take a bit more initial effort, rewarding you immediately thereafter. Gentoo Linux provides fine control over the compiled performance and enabled services. You can start with a binary based setup and then recompile whatever you want to improve, but it does take more work.

In the end, simply managing and tuning just about any popular system is usually enough to gain significant performance improvement without having to resort to a lot of compilation and rebuilding, but it is always possible to build and replace any components that do not provide adequate performance and response. I maintain that the best gains come from optimizing the configuration instead of rebuilding. You can get some improvement by custom compiling select components. I suggest that unless the original software is really sluggish to begin with, any gains from recompiling will be minimal compared to tuning your system to the services you use and tuning disk and memory usage.