SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
My question is what exactly makes a distro i686 optimized. There are a couple of distro's that say they are built off of a slackware base but optimized for i686 architecture. I've searched around these forums a bit and all I've come up with are:
1. Software is compiled with the --march=i686 and -mcpu=whatever flags set for optimization.
2. The kernel is compiled with options for i686 architecture
3. Slackware and most packages for it are already optimized for i686, but have compatibility built in for i386 or i486 and are named as such.
So does that mean if I install slack 10.1 and compile my own kernel selecting my cpu specifically, I'm running an i686 optimized distro?
I was tempted to look into a couple of these other distro's but I really don't understand the difference when they say they are optimized for i686. When it comes down to it, it sounds like the only real differences between distro's are configuration changes, package management tools, and the default packages it uses (extra software and/or newer versions).
I'm not naming any specific distro's because I don't intend to start any flaming or troll feeding. I'm not asking why slack is/isn't better, i'm just curious when people say so and so distro is basically slack but optimized for i686, what exactly does that mean, and is slack pretty much already optimized for i686 just with support for older hardware built in as well?
If anyone can shed any light on this for me, I'd appreciate it.
Basically a Linux distribution is based on two things :
- kernel
- softwares applications and libraries
The Kernel part is named Linux and the software part is named GNU, that's why
some purists call this system GNU/Linux
To optimize a system for i686 architecture, you configure the kernel processor feature to
i686 and you compile all the softwares applications, libraries with the gcc optimizer option
(also called CFLAGS for c language and CXXFLAGS for c++) http://linuxreviews.org/howtos/compiling/
Originally posted by kriton12 My question is what exactly makes a distro i686 optimized. There are a couple of distro's that say they are built off of a slackware base but optimized for i686 architecture. I've searched around these forums a bit and all I've come up with are:
1. Software is compiled with the --march=i686 and -mcpu=whatever flags set for optimization.
2. The kernel is compiled with options for i686 architecture
3. Slackware and most packages for it are already optimized for i686, but have compatibility built in for i386 or i486 and are named as such.
So does that mean if I install slack 10.1 and compile my own kernel selecting my cpu specifically, I'm running an i686 optimized distro?
I was tempted to look into a couple of these other distro's but I really don't understand the difference when they say they are optimized for i686. When it comes down to it, it sounds like the only real differences between distro's are configuration changes, package management tools, and the default packages it uses (extra software and/or newer versions).
I'm not naming any specific distro's because I don't intend to start any flaming or troll feeding. I'm not asking why slack is/isn't better, i'm just curious when people say so and so distro is basically slack but optimized for i686, what exactly does that mean, and is slack pretty much already optimized for i686 just with support for older hardware built in as well?
If anyone can shed any light on this for me, I'd appreciate it.
slack is built with -mcpu=i686. the -march option tells gcc to optimize for a specific arch ( and will not run on anything lower). For example, if you compiled an app with -march=athlon-xp and tried to run it on a Duron processor, it wouldn't run. but if you compiled and app with -mcpu=athlon-xp, gcc would optimize it for the athlon-xp, but it would run on an i486.
Originally posted by __J the -march option tells gcc to optimize for a specific arch ( and will not run on anything lower).
This in an oversimplification. The -march option defines the specific ISA (Instruction Set Architecture) which is to be targeted. This is the set of machine instructions that a particular CPU is capable of executing. As modern x86 ISAs are supersets of older ones, to say that compiling for a later ISA means it won't run on an older one is a fallacy - it may or may not run on an older architecture, depending on which instructions are generated. It's not guaranteed to run on anything else, but it might. I just compiled "Hello world" with -march=athlon-xp and it runs fine on a PII.
-mcpu (deprecated and now called -mtune which probably better reflects its purpose) defines optimisations of the outputted object which don't depend on the specific ISA, eg instruction ordering.
Quote:
For example, if you compiled an app with -march=athlon-xp and tried to run it on a Duron processor, it wouldn't run.
This is a particularly bad example as later Durons are based on the Athlon XP core and have the exact same ISA AFAIK. In fact, if you wanted to optomise for a Duron, you'd have to use one of the -march=athlon* options, because gcc doesn't define any Duron specific ones.
march: The architecture your program is compiled for. If you build for i486, it is backwards compatible by the nature of the later chips, not by anything fancy on the compiler side.
Edit: The following is wrong and has been corrected in my later post
mcpu: The processor of the machine you are compiling on. It does *not* affect the code you produce at the end, just the instruction scheduling for the machine you are building on (i.e. tries to speed up the compiling, but you still get the same output)
(In GCC 3.4, this is now march and mtune)
Very few programs will benefit from a specific -march being set above i486, so for compatibility, leave it as i486, and just change the -mcpu/-mtune to match your processor (probably i686 as has already been said)
now that is clear. a little bit about i486, i586, i686
they refers to the instruction set that the processor has.
ever hear of assembly code? that is when a program enters the cpu instruction line by line. for instance add would be one instrucion.
add ax, 7 ; --> means: ax = ax + 7; where ax is a register in the cpu used for storage.
now i486 has certain built in instructions, i586 has more, and an i686 has even more. they are all backwards compatible of course. an i686 would inculde everything in i484 and i586 and just add new ones. not that diffucult to understand, right?
so when you optimize for a specific arch the compiler optimizing the binary to use that specific instruction set. if you tell it to include a lower arch it will but will make the executable bigger of course becuase it has to write some code for the lower arch.
optimizing for a specific arch is not as great a thing as people think (gentoo lovers)! Sorry, I had to mention that. it only makes a difference if the program is using 100% cpu. A lot of times it is acually better to optimize for size using Os, becuase most of the time waiting is spent loading the program from disk to memory. And when the program loads it's not using 100% cpu so it doesn't matter if it's optimized or not. makes sense, right?
the bottle neck of your system is the disk not the cpu, most of the time. you wont notice a difference between a 2.8Ghz or a 3.0Ghz cpu. But if you can increase disk perfomance that same 7%. Wow what a difference it makes!
so when you optimize for a specific arch the compiler optimizing the binary to use that specific instruction set. if you tell it to include a lower arch it will but will make the executable bigger of course becuase it has to write some code for the lower arch.
scratch that... cathectic has enlightened me. thanks.
Originally posted by cathectic mcpu: The processor of the machine you are compiling on. It does *not* affect the code you produce at the end, just the instruction scheduling for the machine you are building on (i.e. tries to speed up the compiling, but you still get the same output)
Nonsense. It *does* affect the code you produce. What would be the point in having an option to tell the compiler which machine it's running on? It's in a far better position to enquire which features are supported by the CPU that is executing and even then, I doubt dynamically reordering its own instructions to improve performance is a viable option. If you want optimal performance for the compiler you're using, recompile it for the CPU you're compiling on.
I apologise for my initial mistake - a bit of research clears up that the -mtune does affect the code outputted. So, to make up for my stupidity, the findings of some slighly more thorough research:
The code is optimized for the targetted processor, mostly in terms of scheduling, on -mtune, but does not add any instructions that are not compatible with the processor specified in -march.
For instance, if I specify "-march=i386 -mtune=i686" the code will be optimised for everything it can be for the i686 (especially in terms of instruction scheduling, etc) but it will not generate any instructions that are not compatible with the i386 instruction set.
wow, thanks for all of the information. So essentially any speed gains claimed by a distro saying it's been optimized for i686 architecture is on the whole negligent mainly because of system bottlenecks. I understand that faster processors generally only perform better when you keep the cpu fed and that memory speed and cache size are what affects this. Without getting into a huge hardware discussion is it basically fair to say that Slack 10.1 runs pretty much the same speed as other distros built off of slack and "optimized for i686"? That's kind of what I gather from the general response (albeit not so clear cut).
Oh, and for the record, I'm talking daily, average computing tasks, not high performance gaming or compiling software, just general day to day stuff.
Originally posted by cathectic For instance, if I specify "-march=i386 -mtune=i686" the code will be optimised for everything it can be for the i686 (especially in terms of instruction scheduling, etc) but it will not generate any instructions that are not compatible with the i386 instruction set.
If the instruction set is i386 compatible (-march), how can it be optimized for i686 (-mtune)?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.