Mid-2012: Arch Linux vs. Slackware vs. Ubuntu vs. Fedora

[nightmarex]

You could set these systems up identically. That's where the futility of these tests lay. However that being said Ubuntu's default did fair better than I would of given it credit for.

I haven't done a install of Arch since the swap, mostly because my Arch box's never need a re-install and the server heads use the LTS branch so until I get a new computer to mess with I won't get to try the new scripts, may VM it just for fun.

[gens]

wierd about slackware
stock scheduler frequency is 1000hz, same as others
and packages are compiled (for64bit) usualy with SLKCFLAGS="-O2 -fPIC" (or -O3, this is from the fluxbox slackbuild)

almost all vanilla, except for security patches and if something has a problem by default(example X11 has a "x11.startwithblackscreen.diff.gz" patch)
only thing blatently different is that KDE is the default, althou theres alot more WM's there

maybe some1 else knows why shud it be 10-20% slower ?

[ganloo]

Don't forget Arch is no big name behind, that's the different.

Everytime I see Arch can easily switch from one technology to another (for example, adopt systemd for inintialization) , I am still amazed.

[aceman]

I've always heard that Slackware performs great because it's more simple and vanilla. I guess it's just a myth?

I'm also surprised with Slackware coming out so bad. I wanted to say that Slackware's packages (and probably the kernel too) is compiled for i486. However I now see the benchmark was done on x86_64 (so hopefully Slackware64 was used)...
Maybe there still are some differences in kernel settings, e.g. Slackware could have a server scheduling (less context switches per second and less preemption points) and something like Ubuntu could use the desktop settings. But in case of benchmarks the server settings could actually be an advantage.

So I can't explain this and I find it sad as I am using it for years

[blackout23]

Brainfuck doesn't improve every benchmark. A lot of times when you decrease latency, you also decrease throughput. It does however do quite a bit to make your system feel more responsive.

And that's what matters the most for me. I would call it percieved performance. That's why SSDs give you that WOW feeling everything reacts instantly. Doesn't matter if you have an old 1.8 Ghz dualcore CPU which is easy beaten by every modern laptop in CPU heavy benchmarks aslong as your UI reacts faster it's still better than having a fast CPU with slow 5400rm HDD when all you do is basic "office work" anyway. Of course when your main task is to encode videos 24/7 you wouldn't care about having a slower feeling system which has more CPU oomph.

[WorBlux]

Cool, I use the Linux-CK Kernel with Brainfuck Scheduler and Core i7 Optimizations it makes my Arch even quicker.
Absolutely love the new InstallScripts aswell. No more getting out of the AIF just to get your system to work with GPT
and dd'ing syslinux into the bootsector and such. Now it comes down to 1. Partitioning 2. Getting files on that Partion with an easy pacstrap command 3. Setup Bootloader 4. Chrooting without having to bind sysfs and proc and all that just with "arch-chroot" and make changes to config. Done.

If you want to see that there is a difference in how fast the distro feels make 2 Virutal Machine with identical Specs. Install Ubuntu on on VM and Arch with Gnome on the other. Boot them both up and open a terminal. It's easy to see that the Arch terminal simply appears where on Ubuntu you can see it gradually build up over time. I've tested this with 11.10.

Brainfuck doesn't improve every benchmark. A lot of times when you decrease latency, you also decrease throughput. It does however do quite a bit to make your system feel more responsive.

[blackout23]

Cool, I use the Linux-CK Kernel with Brainfuck Scheduler and Core i7 Optimizations it makes my Arch even quicker.
Absolutely love the new InstallScripts aswell. No more getting out of the AIF just to get your system to work with GPT
and dd'ing syslinux into the bootsector and such. Now it comes down to 1. Partitioning 2. Getting files on that Partion with an easy pacstrap command 3. Setup Bootloader 4. Chrooting without having to bind sysfs and proc and all that just with "arch-chroot" and make changes to config. Done.

If you want to see that there is a difference in how fast the distro feels make 2 Virutal Machine with identical Specs. Install Ubuntu on on VM and Arch with Gnome on the other. Boot them both up and open a terminal. It's easy to see that the Arch terminal simply appears where on Ubuntu you can see it gradually build up over time. I've tested this with 11.10.

[MuPuF]

Is there any point with these benchmarks? I feel that when you compare the speed of programs running on the latest versions from the most popular distributions, the results wont really be that much different from each other. And any differences can't really be explained anyway. Theyre all running on the same hardware with the same kernel and probably the same scheduler, compiled with the same compiler. Correct me if I'm wrong but I feel that any differences in performance has more to do with scheduling and maybe the way the program is compiled than anything else.

What about compiler flags? Arch's default compiler flags provide more security than ubuntu IIRC. It is always interesting to check for differences. Otherwise, there may be some performance problems on some distro and noone knows.

[PeterKraus]

That's exactly the point of the article. Long gone are the days, when Gentoo was measurably, significantly faster - and even back then, it was due to two things - an improved compiler, and slow hardware (mainly memory limits). Nowadays, especially if your WM/DE is the same, there is going to be almost no significant difference between distributions (unless you're comparing Debian Stable with Arch Linux Testing, which can be 15 months apart in some packages)...

[igano]

I've always heard that Slackware performs great because it's more simple and vanilla. I guess it's just a myth?