This funroll-loops discussion started with "i586 optimization" in the 90s and even spawned a GCC fork back then. In 2014 it is completely obsolete. Modern x86 CPUs translate all CISC instructions into µOPs and execute them on a RISC-like core. There is absolutely no practical benefit in feeding the instruction decoder with slightly less antiquated instructions. They end up as the same µOPs anyway.

I want to see how you use the 32bit only computers and if, particularly, you have in normal use pre-i686 era computers...

Also, how you are impacted by a i686 Slackware. Positively or negatively.

BUT, I want something else than the fundamentalist speeches like "BUT PentiumM!" or "BUT home routers!". Come on! We can do better!

It's not a surprise that someone who fell for the global warming hoax does also believe in making computers faster by using compiler switches...

2 members found this post helpful.

Yes, your computer is the classic (and the real) problem "BUT PentiumM!", but, I ask you, it is your main computer? OR, you can live with it in the latest i486 Slackware (i.e. 14.1) without huge problems, if Slackware switch to i686?

You are sure? Do a test of Slackware (i486) and Arch (i686) in a old i686 computer...

Perhaps global warming maybe is questionable, but the economy of at least 100w/h of electricity, means something tangible in your pocket.

Also, I believe, to use the processor at its full capacity. These new instructions are specifically made ​​for faster processing. Do not you think? Test it! Or we must believe in i486 and to do not question, because you say that?

The operating system do not run in a abstract processor. There is a system. Looking to Slackware arch, i486, the users are encouraged to try to install the modern Slackware in their very old boxes. But, even if Slackware is able to run in their so old boxes, they will hit diverse problems, like I said, i.e. the drivers for SiS or Savage video-cards, which make the (complete) installation to fail. And no, the VESA driver is not magic. Is very likely to fail too.

In the mean time, us, all, we are "forced" to use an unoptimized operating system, in the name of a hypothetical compatibility which not really exists.

So, I believe that is better for all parts to have a i686 build. That optimization will be seen better, even on old computers, who are on the limit. Then, in fact, the i686 port will help even the users who really have old computers, but still enough modern to be used ordinary.

Yeah, I have a Pentium III with Arch. Basically, because on Arch, the Youtube movies and mplayer works fine. In Slackware the movies are framed. Still, good luck to convince them to pass to i686!

I tried that too, long time ago, but...

I don not want to convince them "to pass to i686", I want only to make them to look for and to try to do an i686 build...

Then do it yourself first (with all packages but -noarch ones rebuilt, of course) and come back with a link to an ISO image of it. I'm sure that a lot of us will be grateful for that and eager to try it. Maybe you could get advises from Eric or Stuart who already did something similar.

1 members found this post helpful.

Why should I? These ancient computers are from the 90s and completely outdated. I did write about modern x86 CPUs and how they handle the opcodes feed to them.

Despite this comparing Arch and Slackware is completely bullshit, because Arch and Slackware are very different.

Yeah, you can even waste time building Gentoo for i486 just for the sake of proving something, but you only get values for your specific (most likely outdated) CPU model. And this way you can tell absolutely nothing about thousands of different x86 CPUs out there.
About which specific opcodes are you talking about? Please name them. You don't have a single clue about microprocessors.

No, my main computer is my desktop. That laptop's HDD was broken now and since there's no one selling an old PATA HDD here, i don't use that laptop anymore. Last time, i installed Slax on it since Slax can be used from USB Flash Drive and it's working fine.

Yes, most users will not gain any significant improvements by switching to i686

Hmm.

I'd probably not be tempted -- I have come to believe in Slackware (well, it actually didn't take much of any time to decide that Slackware was and will be the one and only) and have no reason to fiddle and twiddle with the stable version of the 32-bit releases.

I've noticed that the Slackware SlackBuilds pick the poison (as it were) and compile for the platform, be it whatever processor might be there -- i486, i586, iwhatever6 (and, of course, xxx64). The distribution runs on the hardware that I have with no effort on my part (yay!) either 32- or 64-bit. Thus, I have no reason to fiddle around with anything.

I keep the old guys at stable and I do add a couple of SBo packages (which, of course, build for the platform on either the 32-bit or 64-bit boxes). I like this sort of thing, I don't particularly feel the drive I used to to optimize and mess around -- build it, install it and be done with it is a good rule (at least for me) and it's been working just fine for years. All that hardware stuff previously is from lshw, for example.

My main concern is that the data base servers do what they're supposed to; like I said, these guys sit in a closet mumbling to themselves and they don't get rebooted but maybe twice between Slackware releases (unless the power goes out and the UPS goes flat -- stuff happens).

Basically, I fiddled around with computers for a long, long time (from the 1970's anyway) and I've pretty much gotten over the reinvent the wheel thing a long time ago -- just ain't much fun any more, I value install it and leave it be nowadays. That's why I value Slackware so highly.

Those 32-bitter are just workhorses that do their thing and don't bother me much and they're going to keep being that until the die. I'll give 'em a nice funeral and send them off the the Great Byte Bucket in the Sky with best wishes (think these things will last as long a Voyager 1? Still going from launch in September 1977, pretty much out of the solar system?).

I really believe in Doug McIlroy's Unix Philosophy: write programs that do one thing and do it well (and don't screw with 'em once you've got 'em there).

So, to answer the question, probably not.

Hope this helps some.

Oh You Grand Master of the Assembler!

Sorry my humble opinion, but to take a classic example of conditional move used i.e. for a nice "IF THEN ELSE":

i486 code

Executed on 4 opcode reads.

i686 code

Executed on 3 opcode reads.

Oh, You Great Master of Assembler, don't think that the second code snippet is more compact (i.e. the executable is smaller) and executed in a better time?

No: http://yarchive.net/comp/linux/cmov.html
So now, where you've narrowed it down to a single instruction and got disproved by the kernel inventor himself, I think we can close the case.