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.
I noticed that all the packages in slackware 9.1 is in the format of
packagename-i486.tgz. But my computer has a Pentium IV cpu and
I want to make full usage of my cpu function. Any one knows if there
is a release of slackware 9.1 but with all the packages compiled specific
for i686 or PIV? I don't think kernel re-compiling is enough.
Any one knows if there
is a release of slackware 9.1 but with all the packages compiled specific
for i686 or PIV? I don't think kernel re-compiling is enough.
Nope, does not exist.
i486 is just a minimum for system requirements, I have 2-- P4 boxes and they run FAST after a kernel re-compile.........FAST
do you have DMA enabled for your hard drives??
have you un-installed all the programs that you don't use/don't need??
they are lots of ways to optimize your box!!
I was looking at some *.SlackBuild files the other day and I noticed that they are compiled with march=i486 and mcpu=i686. I'm not positive ( I'm not a programmer yet! ) but I think that it means it's optimized for i686 but will still run on i486.
Originally posted by wallison I was looking at some *.SlackBuild files the other day and I noticed that they are compiled with march=i486 and mcpu=i686. I'm not positive ( I'm not a programmer yet! ) but I think that it means it's optimized for i686 but will still run on i486.
That is correct, and one of my favourite things to point out.
These -m options are defined for the i386 and x86-64 family of computers:
-mcpu=cpu-type
Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for cpu-type are i386, i486, i586, i686, pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp, winchip-c6, winchip2 and c3.
While picking a specific cpu-type will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used. i586 is equivalent to pentium and i686 is equivalent to pentiumpro. k6 and athlon are the AMD chips as opposed to the Intel ones.
-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mcpu. Moreover, specifying -march=cpu-type implies -mcpu=cpu-type.
Thanks. I checked the *.SlackBuild files. Just like you guys said, the compile
flag is "-march=i486 -mcpu=i686" for some (I think most) of the packages.
Slack is already optimized for i686, although not all the packges. I am
happy to find it out.
Optimizations are frequently discussed in the Linux circles, especially those who look forward to squeezing every last drop of performance from their machines.
However, there are tradeoffs in this approach. First and foremost is the time factor. As many of us source compilers already know, large packages (like X, and God-forbid... GCC) take eons to compile. And when they finally do (along with our optimization flags and so on), the performance improvement might not even be noticable.
However, some people would still like to have the bragging rights to say that they're running a highly optimized build of so and so app, to these people I say "Cool... and congratulations.".
But if you have quite some number of machines with different specs to admin/manage... you'd be grateful for precompiled binary packages
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.