Also its not the case that everyone using Slackware only wants to install it on some traditional PC. I grant you its a tiny number of users but there are a lot of embedded systems where i486 and i586 class stuff is quite popular. Lots of older network hardware, that isn't nearly as old PCs that would be sporting classic pentiums like PIX units used i586 parts as well. Its possible with some doing to boot Linux on that stuff, and Slackware is one of the few binary distros you can use/pull from.

The OP is using a x86-64 system but is running the 32-bit OS. I'd ask the opposite question. If you are so concerned about missing out on performance due to not having optimizations present for more capable CPUs why don't you switch the 64bit build? Seems better than cutting off otherwise supported equipment from the bottom end. Remember Slackware changes for i386 only because critical upstream stuff stopped supporting it as matter of more than just compiler flags.

Also keep in mind the 64bit Slackware builds are targeted to essentially the earliest x86-64 AMD parts from like 2k3! There is if anything probably more left on the table there in terms of performance.

I have a still in use 64 bit system running 14.2 Multilib on an AMD FX-57 which was originally introduced in 2005 as their 64 bit flagship for over $1100.00 USD... just for the CPU!!. I bought mine new in 2009 for $225.00 USD. One doesn't have to be even affluent let alone rich to have good gear if you "do your homework" and look around.

I think it's worth saving up and waiting to pounce because it's not like suddenly 5 years from now PCs are gonna disappear like 8 track players.

Cool!

But did you are aware that that means the entire income of an usual Venezuelan employed full time, for 100 months? Just to ensure that you do not read wrong: ONE HUNDRED MONTHS.

Well, this was just an example - there are millions of people doing even worst than this.

If I try to build some app or lib for my exact CPU architecture: sandy bridge, will it be faster? Or I'll need to recompile everything, especially the kernel?

Why? What will replace them?

What sense makes to use a 32bit operating system on an Intel Sandy Bridge CPU?

Probably even an usual x86_64 Linux distribution, like is the Slackware64, does not uses at max the resources of your CPU...

1 members found this post helpful.

Why don't we just go to the source?

That was back in 2018. I'd imagine this isn't the only reason, but it seems Pat had been testing i686 at least back then (and probably earlier). As most of the world has moved to x86_64, it is probable that the code hasn't been changed since he last tested to work better on i686.

Also, it should be noted that Slackware has been using -mtune=i686 for quite some time (seems like the switch was made for 13.1) even though the SlackBuilds contained an -march of either i486 or i586. So while programs on -current will still work on i586 hardware, they are optimized to run on i686 hardware.

I would be interested to see if there is an actual decent performance improvement on using an march of i686, with whatever new instruction sets are provided. However, I've long left the 32bit world (I'm not even running multilib on my 2 Slackware machines, although, that might change on 15.0 to not require a container to run Steam), so I have no horse in this race, so the interest is just for curiosity's sake.

2 members found this post helpful.

Answers maybe and it depends ;-).

The target architecture determines what features / instructions the compiler is allowed to use and sets some other rules like minimal number of no-ops after certain branch operations etc. There is a degree of tune options as well where certain features might be available on certain CPU level but it might be faster to do things one way vs another. Completely making this up but as an exampele of that maybe CPU-version-99 supports SQR (square) but its faster to do as multiple shifts, because shift is one cycle and SQR takes 20 cycles or some nonsense; but on CPU-version-100 SQR is optimized and now runs in 4, so its faster than multiple fetches registers copies. The compiler knows this and can spit out code that will run faster on CPU-100 with its SQR function, but still works on CPU-99. Meanwhile code for CPU-98 with no SQR will also work on CPU-99 and CPU-100 but it won't leverage SQR at all will always uses the slower series of shifts.

Now its a little more complex than this because SQR would not been added at all unless it was better for some situations. After all its more circuit and more cost. So depending on the situation maybe which registers are used, if its a 16/32/64 bit value etc SQR is probably better even in CPU-99.

Do you have recompile everything to take advantage - probably not. Depends on the code in question. If the app is something like a video codec where its got highly optimized implementations of the algorithms it uses built-in than you'd see the performance just rebuilding that, on the other hand if it 99% of what it does is done by the standard C library math functions and you don't rebuild libc - well you probably see no gains at all!

1 members found this post helpful.

The answer to the question is the same as the answer to MANY Slackware questions: It is that way because that way WORKS!

If you want to play around with it, nothing stops you. The whole selling point of Slackware is that it is pretty darn solid and pure/true to the original philosophy. When moving forward one way makes something break, it moves forward a different way. And it changes only when it (he) is darn good and ready. Any user can intentionally change something and compile differently to see if it blows up or gives them some advantage, but to expect the base to go running off that way is unrealistic.

2 members found this post helpful.

Re: PCs lasting power vs/ 8 Track Players (an example of obsolete technology)

I'm not at all certain if you were referring to PCs or as a joke to 8 Track Players but my point was that every old PC I have, no matter how old, still does now what it always did. They didn't disappear altogether like some technology has. As long as you don't plan on doing much newer stuff your PC should still work for you in a way that you found to be valuable to you even if it is old and cheap. It likely will at some point be more difficult and more expensive to repair or expand (ie - RAM) and it may be prudent to consider "diminishing returns" but my overall point was that even if it takes years to save for your dream PC, it will likely still be worthwhile when you get it.

This is largely in response to those looking down on i586 machines and software. One can still do quite a lot with an i586. I think I've also implied it should be worth it to "shoot for the Moon" and get the best PC you can practically afford and that doesn't have to be "latest and greatest" nor does it have to "break the bank" if one learns how to look for deals.

I tend to be "that guy". Here we go....

I am into collecting rare-ish non-standard CPUs. One in particular; I have a Transmeta Crusoe TM8500 in a Compaq TC1000 that I use as a retro gaming machine (for which it works really well, thank you very much). This processor does not run i686 code at all, but is basically i586+MMX (give or take, the details get foggy). Retro gaming deserves a retro CPU. What can I say? I told you I was "that guy"...

This made choosing a distro quite interesting. I tried every single distro I could get my hands on that still supported i586, even including stuff like 9front and all the BSDs. Strangely enough, the only two that worked worth a damn were Slackware and Mageia. I even tried the source-based stuff like Gentoo. Most would complain about the processor at one point or another.

Even though it can load and run -current, I have 14.1 installed on it, because almost the entire distro works out of the box (including Firefox, and yes I know it is severely outdated, that is not the point, I do not surf the web on this thing at all). On 14.2, the Mozilla stuff stops working. On -current, anything linked to Qt5 (including all of KDE) does not work at all. But on 14.1, the only stuff that did not work was XaoS (which has been i686 going as far back as I can tell). And xine always works, even though it is marked as i686.

So, if it weren't for Slackware, I would either be having WAY less fun running (the much slower) Mageia on this thing, or it would wind up going to electronics recycling. In the mean time, it plays DOOM (and most non-3d games) just fine, so why get rid of it?

I will be celebrating this thing's 20th birthday next year. And I hope to play some DOOM on that day. Oh, and I am fully employed in the "first world", and I still am glad that Slackware supports i586.

7 members found this post helpful.

Re: My purchase of an $1100 CPU for $225 once dealers began serious clearout sales.

I am curious if you mean $1100 or $225 equals 100 months of income, but to answer your question, No, I was not aware that millions of people, especially those in the market for PCs exist on what amounts to $11.00/month and I can't even imagine $2.25/month as a livable income. Granted whenever I've lived in lower income areas, prices were commensurately lower, too, at least on basics, but I? am aware that Venezuela tops the Global Misery Charts and not only has a huge percentage of citizens below the extreme poverty level but worse, many severe shortages make it impossible to get basics no matter how much income one has.

Example: I have lived in areas where an efficiency apartment rents for $3000.00 per month and other areas where a 3 bedroom entire house rented for $125.00 per month. Obviously average incomes in those areas was very different. It is indeed an extremely sad situation with no easy solution, probably due to decades of poor management in politics and business in a mono-economy.

In any case I thought I was speaking to and for members here at LQN who must have not only afforded a reasonably powerful PC, even if it is an i586, but also can afford ISP fees. Surely you aren't suggesting people who make $11.00/month also own PCs and ISP accounts? Surely you aren't suggesting that $11.00/per incomes are commonplace all around the world.

For reference --- https://worldpopulationreview.com/co...ome-by-country

My point was that any kind of i686 runs code compiled for i586 just perfectly fine without drop in performance unless your software requires SIMD instructions.

[QUOTE=usr345;6248480]I looked at wiki, and it seems that SYSENTER/SYSEXIT were introduced only in Pentium II. So, it seems that i686 architecture is not enough. X86_instruction_listings#Added_with_Pentium_II.

You see, one can't benefit even by using sysenter/sysexit opcodes if you compile for ALL i686. As LuckyCyborg mentioned, the only instruction you can use in i686 vs i586 is CMOVcc. Are you sure this will give you any improvement?


So, you propose radical changes to Slackware (well known distro for its conservatism) without numbers in your hands? I can't understand you.

3 members found this post helpful.

Use the 64 bit version if you care about performance.

5 members found this post helpful.

Now I see that there will be almost no improvement. But can I compile some graphics app for my native sandy bridge CPU and look how it works? There may be improvement. I don't know: VLC, xine. But in this case I'll probably need to recompile the kernel too.

I am switching to x64 Slackware when 15.0 comes out.

1 members found this post helpful.