Benchmarks are useful if you can give a meaning to the results and I don't really understand what all these numbers mean. Some of the tests, like the SciMark, are probably meaningful only to compare different hardware platforms, or different compilers on the same platform but not for comparing different distributions.
Slackware, for example, is better than Centos in the Monte Carlo test but Centos is better than Slackware in the Fast Fourier Transform. What does this tell me? I don't even understand *what* is being tested; the compiler? The kernel? The scheduler? It is also not clear (or maybe I missed that part) if they are testing inside a GUI.
Anyway, at least when I'll start making a living out of calculating FFTs, I know what to install, at least until the next benchmark.

2 members found this post helpful.

Benchmarks. Fuh!
I bet he didn't even use Slackware for more than 2 days. Had he actually done that, there wouldn't have been no benchmark of such sort and then he would've burnt up his entire lab of 25 computers which is setup for these overrated tests and gone to Himalayas or deep in Amazon's to regret and to praise bob.

Just kidding, use what is working fine. Slackware FTW.

Regards.

This. Numbers without context are meaningless. I also notice that no conclusions are drawn.

As for Slackware mostly being slower, that may be true. I don't know. I do know that Arch felt a lot faster to me, but I didn't like how it felt.

Fedora might be a test bed for Red Hat, and Ubuntu based on debian testing and unstable, but that doesn't mean that either is comparable to 'beta'. The fact is that they both are developed, go alpha, beta and are then released just go to show that the packages released are not necessarily vanilla. It just happens on a shorter cycle.

I benchmarked slackware 13.37 versus arch, mostly because I couldn't mirror -current properly. Arch is obviously faster. When Slackware 14.0 comes out, I will apply the same benchmarks, mostly compression, decompression, copying, deleting, encryption, decryption and post the results. I was going to do some multimedia encoding, but I'm using the Arch live CD, and it doesn't have anything like that, and technically there's only mplayer on slackware no ffmpeg by default.

1 members found this post helpful.

Is that 32 or 64 bit? Arch is compiled for i686 on 32 bit, Slackware for i486, which may explain the differences. Since you state that you do use the live-CD, do you make those benchmarks in RAM or on a disk?
If you want to make multimedia benchmarks you can try mencoder instead of ffmpeg.

Phoronix is an ad farm IMHO with gotcha titles to get people to go to the site and view the popup ads that you are forced to click through. Of course, most of us use some kind of ad blocking software, but if you send a link to someone who doesn't, they usually comment on it.

It is the dual live CD, this means it has both 32-bit and 64-bit on one disk. I tested Arch 64-bit and Slackware 13.37 64-bit, and I will test Slackware 14.0 64-bit, because after all, if anyone truly cares about performance they have no business on 32-bit.

All benchmarks were on disk with JFS filesystem.

I can try mencoder, but I'll have to find a way to use it with the arch live CD.

I think that someone running the benchmarks over there at phoronix is on crack.

The 'huge' kernel is about as vanilla as you can get, no unneccessary tweaking or introducing intangible instabilities as a result, and it's recommended that one creates an initrd for production machinery anyway. I'm not surprised to see Arch Linux do so well, it's currently running the 3.5.3 kernel, yet only an asshat would use the 'huge' kernel in Slackware and call it a benchmark - Stock does not mean using the huge kernel - phoronix should read the docs before making such assumptions.

b.b.b.boneheads is as b.b.b.boneheads does.

The next time someone benchmarks OSes at Phoronix they should use the distro's recommended kernel. With Slackware, that would currently [most probably] be the *generic* 3.2.29 SMP kernel.

I know my Slackware machines walk away from my other machines and are much more responsive and snappy. Again, I'm not surprised at all to see Arch do so well, as it is indeed a good distro too.

Whatev!

.

No, you want to run benchmarks on each distro as it comes out of the box. That is the comparison.

Everyone suggesting that the -Ox flags and kernel must be the same are missing the point: comparing Linux distributions. Choices that the distro makes (kernel, compiler flags, etc) influence benchmarking results and that is what the author is measuring. These variables are needed to measure differences between distros with respect to performance.

1 members found this post helpful.

Hi

Compiler flags are not the same.
Arch - don't know is it 32 bit system or 64?
Ubuntu , fedora,centos are compiled with flag --with_arch_32.
Maybe this is the point.
32 bit aplications run faster in 32 bit environment to about 10%.

The problem with comparing distributions can be seen when you compare distributions that don't have a default configuration, like Arch, or a default desktop, like Slackware. Then you have to make arbitrary decisions which can or can not distort the benchmark results. From my experience Micheal Larabell is not very good in making those decisions fair or at least comprehensible. It is comprehensible why he uses Gnome Shell (Fedora), Unity (Ubuntu) and Gnome 2 (CentOS), they are just the default. But he does not make any comment why he uses the rather lightweight XFCE on Slackware and why it seems that he has not used a GUI at all on Arch.

Something similar could be seen with his recent benchmark of nouveau, on not defined hardware (Geforce 9600GSO, which has three different versions with different performance), with a comment that performance regressions in Unity may have or may have not caused some slow downs and with no comparison at all to the standard proprietary driver.

In general, Phoronix benchmarks are useless, just because that guy has no clue how to make proper benchmarks.

1 members found this post helpful.

I prefer stability over performance. 'nuff said.

1 members found this post helpful.

Anyone who is even half-seriouly concerned about benchmarks results about Slackware, especially from Phoronix,
is just .. well, he/she is not enlightened yet. I am currently burning 32 and 64 bit disks.
Thanks a lot to Pat and everyone who helped/helps Slackware.

I have the benchmarks, I have attached them, as well as the commands I ran. I was unable to do the mencoder benchmark, because the one that comes with arch has lots of dependencies.

commands:
All benchmarks were done on the same machine:
Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz
2GB Corsair RAM 800 MHz dual-channel
Intel DP35DP mobo
nvidia GeForce 8800 GTS 512
Seagate Barracuda 7200.10

The two distros benchmarked were:
Arch Linux 2012.09.07 (this is the latest one at the moment), it is the live CD with both 32-bit and 64-bit versions. I used the 64-bit one.
Slackware64 14.0 from the torrent DVD

All benchmarks were done in the same directory on disk, the filesystem is JFS.
Both distros were unmodified. I used the standard kernels that came with install on both.

Summary of the ttests.
I have also included benchmarks of slackware64 13.37 versus arch, and the results are that slackware is obviously slower in all tests but the first two. Technically I was using a custom kernel, but I doubt it slowed it down. But, really, you can't compare the two because they were released years apart, it's just there as reference.

Anyway, it's pretty clear that Phoronix is full of s***.
The phoronix benchmark was flawed because:
1. It was NOT done on the same hardware. Check the first page.
2. It was NOT done on the stable Slackware release.
3. It was done using non real world tests.

I am boycotting phoronix permanently.

Attached Files

archbench.gnumeric.log (7.7 KB, 41 views)

6 members found this post helpful.