I like Crux but i find myself more confortable with Slackware. Personally i haven`t found any improvement in performance when using Crux. But it makes a good, solid and easy to use system.

If you have a 64-bit processor like one of the AMD64's, you would need to use k8, opteron, athlon64, or athlon-fx as the -mtune argument (-mcpu is the deprecated equivalent to -mtune). The i686 is a 32-bit architecture and will not take advantage of the additional 64-bit instruction set.

To build 64-bit packages, you will need to have 64-bit version of glibc and binutils and gcc need to be built with 64-bit support enabled. You'll need other 64-bit tools as well, libtool, perl, flex, and file come to mind as tools used during the build process. None of this will be available on a 32-bit Slackware system. Your best bet is to get a 64-bit distro or build one yourself.

That said, you're not likely to notice a difference between 32- and 64-bit because the difference in execution times are measured in nanoseconds. This is so small it takes the sum of tens of thousands to be perceptible to the human brain. If you're doing things computationally intensive, you'll notice differences like tasks that took 12 minutes on a 32-bit architecture only take 7-minutes on a 64-bit architecture. But day-to-day things like web browsing and word processing aren't going to be noticeably improved. Unless, of course, it takes 12-minutes to open your web browser.

The binary version provided by Gentoo is 32-bit for use on multilib systems. Versions of OO prior to 2.0.4 did not build on 64-bit systems. Newer versions of OO can be, and are, compiled locally.

well according to alot of people -Os gives better performance for pentium M

I don't know if it as anything to do with package optimization, but I can say that Arch is WAY faster than Slack, at least, on my system. That is in fact one of the reasons that made me switch.

Well, if one checks Gentoo mailing list, one can get to know A LOT on optimization issues... And it is easy to explain why -Os is in many ways better than -O3 and even why --funroll-loops is not always the best idea. The reason for this is, that internal processor clock is much faster than FSB. And processor cache is of limited size. So it is usually faster to run a slightly more expensive algorythm that fits into cache, than wait for portions of the program to load from RAM... but of course it depends on types of programs. But usually, -Os is not at all a bad idea, in many ways better than -O3...

http://gcc.gnu.org/onlinedocs/gcc-4....timize-Options

Yup, it's kind of a gamble ... usually it doesn't make too much difference either bad or good.

As for the -Os versus -O3 ... that's a bit too technical for me I'll try it out tho ... I can imagine that it may also result in some performance gain, but it was mainly designed as a size optimization.

Of course things are not straightforward and of course -Os is meant for size optimization. And what is funny (and yet explainable) is that it often happens that smaller programs run faster than larger programs even if the larger program executes fewer instructions...