First I should apologize for my likely naive questions, but I have only started playing with actual optimizations in the last week or so; I have always just compiled with the defaults before.

Anyway, I have recently been playing with compiler flags through the use od SlackBuild scripts, and had a few questions and thoughts that I would like cleared up.

1. I have read in the GCC documentation that -march implies -mtune to the same CPU type. But I have seen many scripts specifying both. Is it alright that I am just using -march?

2. In the official Slackware build scripts, the following is added to ./configure:

Now, since $ARCH is also used when it names the package, I have been using "i786", even though I use "pentium4" for -march. Is this correct? I assume so, because when I give --build "pentium4", the response I get back is still:

3. Since I mainly compile my packages on a centralized server and then push them out to my machines, should I be using --host rather than --build when optimizing for a specific CPU (one which the server does not have)? At the very least I know I am misrepresenting the build machine (does this matter?), though the host machine does show up as i786 in the ./configure output.

4. Finally, I have noticed that when I build a package that should be compiled only for Pentium 4 (if I am doing it right), I am able to run the binaries on the server. I had got the impression that once they were compiled for a specific CPU, that was it, and they would not run on a different chip (the server has an AMD XP 1500+, and my desktop has a 2.4 GHz P4). So this has gotten me thinking that I have either done something wrong and they are not fully optimized for Pentium 4, or that I was a little too gullible with what I read online about CPU optimizations.

Again, I am sorry if a lot of this is very obvious, but I have not been able to find clear explanations for some of these issues, and it seems like the kind of thing were you really want to hear other's first hand accounts to make sure you are getting the best performance. I should also note that I do "feel" a considerable performance boost in some applications (most notably, Wine) so I must be doing something right.

Not that I'm any kind of expert, but....

1. It shouldn't hurt. I specify both in my build flags and haven't had any problems.

2. i786 is the technology used in Intel's Pentium 4 chips.

3. --build=build-type is the machine that you are configuring and building the package on (your server)
--host=host-type is the machine that will run the resulting binaries. By default it is the same as build. Specify both --build and --host to cross-compile.
--target=target-type is the type of machine that any compiler tools in the package will produce code. By
default, it is the same as host.

4. Optimized, not exclusive. It will still run on x86 architectures, just not optimally.

I am aware of this, but the i786 is still a generic CPU type. The GCC documentation lists 3 separate versions of the Pentium 4 (not counting the 64 bit extended version) for cpu_type, and I obviously only want to optimize for just one of them.

I'll play with this a bit more then, but in my quick tests, I got a number of errors from ./configure's output when specifying i786 for --host.

This is very interesting, since it is the complete opposite of what I have read online (from sources such as the Gentoo docs). Basically my understanding was that -march would target the code only for the specified CPU or newer (not maintaining any backwards compatibility), while -mtune would optimize lightly enough that it would still run on generic CPUs.

From Gentoo handbook:

I also see this in the official Slackware build scripts, which specify "-march=i486 -mtune=i686" which equates to (if I have the concept right): "Optimize for i686 so long as it doesn't keep the code from running on a i486".

But even with -march, I have gone so far as to run Pentium 4 optimized binaries on a Pentium 3 and have not had problems, to say nothing of the AMD XP. But perhaps the code I was optimizing was too simplistic for the optimizations to make that much of an impact on the resulting binary, I was only using simple programs to test.