will the whole distro build with the gcc option -march=native
the kernel AFAICT dose it's an option in menuconfig
gcc could use a speed boost being a number crunching program those extra registers and instructions can't hurt

so should I go about it like an up grade
and how do I get the slack builds to pass the options to the make files
should I just add $CFLAGS=$CFLAGS+"-march=native -usepipe" to the environment

Each slackbuild sets the march on its own, I think you would have to edit each one manually. By the way, why don't you try gentoo?

If you search the archives, you should find where someone was attempting to recompile Slackware from scratch. It isn't as straightforward as you might think, IIRC, since Pat doesn't build Slackware that way.

I doubt that I will have to do a linux from scratch operation
in that I'm not devorceing the new system from the build system
the libraries pass every thing on the stack or write to memory
nether of witch should be affected
by the way the CPU uses it's registers
AFAIK only the kernel passes perimeters in the registers

Recompiling the complete system will not much more speed than just recompiling the applications that can make use of adavnced CPU features. Compile the kernel with the CPU option set to your actual CPU, then compile the glibc with march=native. The other programs only need to be recompiled when you think there can really be a speed improvement. Firefox and OpenOffice will not run significantly faster, but "numbercrunching" software, like image editors, 3D rendering software, media encoding software, ... may get significant improvements.

1 members found this post helpful.

I think there were several threads about this (including one from half a year ago), but the short answer is that you'd have to recompile each package individually. That's how the all-packages-recompiled forks, such as BlueWhite64, Slamd64 and ARMedSlack, have had to be built.

my kernel was built with the native option
I'm thinking the libraries first (C programming is mostly gluing library functions together)
X,Gcc,kde,media-players

I would say, give it a try. Just for fun, install Gentoo or CRUX, with march=native. Then compare it to a Slackware system (default) and a Slackware system where only the specific application you are testing is compiled with march=native.
I have no number on that and would like to see them, but I guess that the Gentoo system will not be much faster than Slackware default in general and insignificant faster than Slackware with the specific application compiled natively. If it is worth the hassle is up to you, I wouldn't do it. If I wanted a totally optimized system I would go for Gentoo or CRUX (or one of the other source based distros), those make it easier to achieve that goal.

MY guess is there is a lot less ready to build install with the package manager software
for Gentoo or CRUX than there is for slackware

all I have is broad cast TV and small screen youtube is getting a little old

WTH I have another computer to mess with while gcc dose it's crunching

on x86 the kernel uses fastcall, yes
on amd64 it is bit different but still fastcall

edit: also 32bit uses interrupts to call the kernel while on 64bit there are special cpu instructions for it

x86 C calling convention says parameters on the stack
but amd64 C calling convention is fastcall

that and there are twice as many generic registers in 64bit mode (also twice as many sse registers) and they are twice as big
so i always recommend 64bit systems to everyone, even thou they use more RAM


like TobiSGD said, you get more gain by recompiling the programs that you test then everything else
then there is code like glibc that always uses the fastest version of a function regardless of the program using it