Slackware's performance is poor compared to other "big" Linux distribution
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.
And just like you say, my point was actually, that a selection of a platform is usually being made based on more than one criterion. Decisions are made based also on load tests (if they are not benchmarks), vulnerability analyses and stability under conditions resembling later usage scenarios in a laboratory environment to ensure comparability of different offerings.
So benchmarks can be useful, but only if they are done properly and consistently for all candidates to be assessed, and they are just one of several pieces of the big picture.
And that's why Slackware is my distro of choice, and BTW, it feels pretty fast to me, in my particular use cases.
No two Linux distributions use the same kernel configuration, the same software versions, or the same optimizations to their software. You can't even begin to say there are proper ways to benchmark two distributions against each other.
You are missing the point. This is exactly why people do benchmarks: distros are different and hence perform differently. Why on earth would you want to remove all the variables?
Benchmarks are made using specifics, so to use that benchmark as a means to indicate universal status is moot. The benchmark data is for the environment and system variables at the time performed. Really cannot use this to compare between equipment that is not equivalent or better than the test bench equipment.
If Gnu/Linux(a) is compared/bench marked then to do same tests on Gnu/Linux(b) on the same equipment then a somewhat fair test. Most users do not interpret the benchmark properly, most users then make assumptions on the test as compared to their known environment, which is comparing apples & oranges.
Yet they even haven't included Gentoo in the test. Slackware is naturally slow since it's meant to be generic to run with most hardware and not optimized to native ones e.g. it doesn't include machine-specific instructions when building the packages. I'm a "Slacker" (it's my first distro, and it's my alternative distro to Gentoo), but really, there's a noticeable difference when it comes to performance as I compared it to Gentoo.
P.S. Distro doesn't necessarily mean binary distros right? So Gentoo should have been included.
P.P.S. Slackware could still be made faster if it's recompiled from sources with machine-specific optimization flags.
You can do it and show us the result.
But really man you have to study how processors works and then you will understand why it's impossible to get big result from that kind of optimization. And you may even believe that but you can't believe that you will get back the processor time that you wasted while you compile and recomplie that package every time it gets updated.
Studying how processor works? Well I'm halfway there - at least seeing how using special instructions would help big time (e.g. having 1 CPU cycles instead of 4; using special string operations, etc.), and making proper use of caches. And sorry but I don't have the time for tests. You should have at least tried optimizing your system yourself, and/or study some concepts of GCC before making an aggressive reply to my post.
Gentoo is hard to test, I mean it is compiled from source, so it depends entirely on CFLAGS.
Yes it does, and sometimes more hardcore is that trying to build a more native system from earlier stages than stage3 (whereas you would change CHOST).
I will test the live CD if you want.
Not necessary for me. I don't really mind proving it. But Gentoo is not really about live packages.
What do you mean by general test ? If you want me to test something else, tell me. I was gonna test mencoder, but as I said, too many dependencies in the one included with the Arch live CD.
I mean based from system-wide usage, so it's more like in most environment most people use like the effect on the desktop manager, X, etc. But if you would really make a test, it would be best to test not-really data dependent tasks, and softwares that has their own instruction patterns since some explicitly use their own arrangement of instructions most notably those that handle media files.
Yet they even haven't included Gentoo in the test. Slackware is naturally slow since it's meant to be generic to run with most hardware
and not optimized to native ones e.g. it doesn't include machine-specific instructions when building the packages.
Most softwares (like Microsoft Windows) don't include machine-specific instructions, CPU vendors know this and optimize their hardware for it (and not for Gentoo). A modern x86 CPU has an instruction decoder to feed RISC-like execution units with micro-instructions for the optimal execution speed. Of course exotic instructions get a penalty and will be emulated in micro-code.
So as a compiler you are aiming for using only the most generic instructions, because the others are slow.
Performance-wise the best thing you can do on modern hardware is to implement multi-threading and make use of specialised units like GPGPU and AESNI. Both you can't do by compiler flags, you have to change the algorithm. Case closed.
I'm a "Slacker" (it's my first distro, and it's my alternative distro to Gentoo), but really, there's a noticeable difference when it comes to performance as I compared it to Gentoo.
Studying how processor works? Well I'm halfway there - at least seeing how using special instructions would help big time (e.g. having 1 CPU cycles instead of 4;
In modern hyper-threaded superscalar pipelined out-of-order-execution CPUs there is no concept of "cycles". How much cycles an instruction takes depends on the instructions around it, instructions of other threads, which will be executed on the same core or module, the results of the branch prediction and so on...
using special string operations, etc.)
Using "special" CISC instructions from early x86 assembly is a good way to slow your program down.