Alien prove that Slackware runs in i486.
But it would be interesting to see a Slackware i586 in a very similar machine but with a processor i586 to see the difference in time for some jobs.

Go ahead, be my guest.
Rebuild Slackware twice in its entirety and run benchmarks. Then publish the results here.

Eric

Wait a minute here, that means you gave it 512 MB of RAM ... how likely is this on a 486 ?

32 MB of RAM is easy enough to test with QEMU-KVM. I may even try it this weekend.

I'm glad to see some some attempt at a poll of users on this subject. I did something similar a few years back: How old are your Slackware computers?

At least in 2007, 33% of users who responded had computers older than seven years. Still, those computers would probably be at least Pentiums; most of them, anyway.

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.

I think we do a very old mistake here, because we are talking about an abstract processor. Unfortunately, there is a whole system which must run a modern Slackware ...

A typical system i486: is a 25 or 33 MHz processor, 16 or 32 MB RAM and 40 MB or 250 as hard. And I forgot to tell that the video card has no more than 1MB or 4, and it is not 3D.

Is this system able to run smoothly a Slackware desktop? I doubt, because only the X server, now consumes 32.2 MB, in my Slackware Current.

Not to mention that for installing Slackware, it requires at least 128MB of RAM ...

Darth Vader I think your opinion is correct.
A i486 computer is to old to run future releases of Slackware.

I think we are only delay the change to i686.

So I guessed right ? I guessed at 16-32 MB, I didn't know for sure so I edited it out of the last post.

Yeah! You guessed right...

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.

1 members found this post helpful.

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)

Yeah, I have noticed a significant improvement for most apps on x86_64, but much less of a difference with any kind of optimizations on 32-bit, something minor like you found.

Maybe the best way is just to leave slackware as is and encourage those who seek performance to use 64-bit version.