[SOLVED] cpu optimisations and slackware - Any '486 users?
SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Go ahead, be my guest.
Rebuild Slackware twice in its entirety and run benchmarks. Then publish the results here.
Hehe, Well that's nail on the head. I really wish Pat would just go ahead and do it. Just because some extremely small niche of Slackware users either do, or might 'want' to run Slack current on a 486 should not hold back progress. Letting other Os's pass us by is kind of ridiculous IMO.
Older hardware, run an older version. I don't see users demanding the latest OSX to build on their Macintosh IIci. Or Win7 on a 486. At least we can run a much better OS on that older hardware. In fact, Linux & Slack are probably the best at it. But the 486 days are long gone, and it's so long in the tooth it's just not worth it.
Where are you pulling your stats from for the 'average' i486 machine? Is that a desktop or a server? I would think that a server would have a much higher chance of supporting more ram. Even an i486 processor has 32bit address space that would support 4 gigs of ram.
As Alien Bob pointed out, making the change is no trivial matter. Of course PatV and the team are all up to the task, but I don't think the improvement would be worth it for most users.
What I mean is this: there is much more performance gain to be had from simply re-compiling your kernel to match your CPU, than there is to be gained from recompiling everythig to match later CPU's. Most of the hefty imporovements are actually in the i386-to-i486 step. i586 would be a bad choice because it is commonly problematic to cross-compile for i586 (BTW, we *are*, techincally speaking, talking about a cross-compile here). So i686 would be a better choice.
Still, only users who do heavy sound/video editing would notice much difference. As Alien Bob said, anyone who feels themselves capable should put in the time to do the job -although they might as well create a fork if they really can do it. The current i486/i686 setup already takes advantage of any later CPU features if they are available. Simply re-compile your kernel for i686 and you already have an i686 system.
I see the present setup, and it works. What concerned me to be honest was that i486 was not mmx capable, and mmx does provide benefits. Libjpeg, and libtiff are i486 and surely that is a case where block copies and moves are relevant. I'm not bothered going to assembly language to check out what's happening. If Slackware32-13.2 is i686 as a result of this thread, that will be a considerable achievement.
It should also prompt a kernel revision. When Slamd64-12.2 came out, my laptop had a poor time on the kernel. Kernel recompile took about 2 hours(!). I grabbed the fedora (9?) config and started with that, and got a kernel compile down under 15 minutes. Checking through the kernel, I found that every 32 bit bugfix that was ever contemplated had found it's way into the 64 bit kernel, and no k8 optimisations were included. I wrote to Fred Emmot and urged him to fork his 64 bit kernel, which he did. Compile times also came down under 15 minutes, and my own kernel was fastest of the lot at around 13 minutes.
If improvements like that were available on 64 bit, it seems reasonable to expect that a kernel for i686 would also bring improvements. The RZ1000 and similar bug fixes could be dumped, as video cards that should never have seen the light of day, etc.
For the record, my 1994 laptop (mentioned in post #1) was very fast - a 486/DX-100, with no more than 16 MB of ram. I do have to hand a pentium 120 in working order, w/32Megs of ram. I keep it to run dos and an old program to drive my Analogue Signature Analyser. The software simplky refuses to run on K6 or above. It will not run i686 code. But it will firmly test if Slackware loads on such a machine if none closer hardware can be found. Please allow me till the weekend to give it a try, as things are v. busy for me right now.
I think moving to i568 would not alienate any users, but would it be worth it ? performance-wise and the amount of work it would take ?
You could try to compile a favourite application of yours for i586 and benchmark it! For example, I use a lot of time running gzip while making daily backups, so I benchmarked gzip. If the default CFLAGS (-march=i486 -mtune=i686) gives a baseline speed of 100, then march=i386 mtune=i686 gave 91 (on P4) or 101 (on i7), march=i586 mtune=i686 gave 101 (on both P4 and i7) and -march=i686 gave 103 (on P4) or 105 (on i7). On the other hand, a 64-bit binary gave 114 (on both P4 and i7).
(Gzipped a tar file of 111 MB ten times to /dev/null with each binary on two computers. gcc was version 4.4.4)