Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
09-28-2012, 08:03 AM
|
#31
|
Member
Registered: Jan 2011
Distribution: Slackware 14.1
Posts: 118
Rep:
|
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.
|
09-28-2012, 09:42 AM
|
#32
|
Member
Registered: Aug 2009
Location: /Universe/Earth/India/Pune
Distribution: Slackware64 -Current
Posts: 890
Rep: 
|
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.
|
|
|
09-28-2012, 10:41 AM
|
#33
|
Member
Registered: Apr 2004
Distribution: Slackware
Posts: 127
Rep: 
|
Quote:
Originally Posted by fgcl2k
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.
|
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.
|
|
|
09-28-2012, 12:19 PM
|
#34
|
LQ Guru
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
|
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.
|
09-28-2012, 12:43 PM
|
#35
|
Moderator
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
|
Quote:
Originally Posted by H_TeXMeX_H
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.
|
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.
|
|
|
09-28-2012, 01:18 PM
|
#36
|
Member
Registered: Jun 2011
Posts: 87
Rep: 
|
Quote:
Originally Posted by chrisretusn
I think it is just another meaningless test. Not any huge differences that one would see during normal use. It's certainly not going to convince me to switch to a "faster" distribution. Slackware is fast in my book that's all that matters.
|
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.
|
|
|
09-28-2012, 01:27 PM
|
#37
|
LQ Guru
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
|
Quote:
Originally Posted by TobiSGD
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.
|
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.
|
|
|
09-28-2012, 01:59 PM
|
#38
|
Member
Registered: Jul 2003
Location: On the Beaches of Super Sunny Southern San Clemente, California USA
Distribution: Slackware - duh!
Posts: 534
Rep: 
|
Quote:
Originally Posted by parcox
Hi,
I just read an article[1] from phoronix about performance comparison ...Slackware performs "bad" compared to the other distro. What do you think guys?
|
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!
.
Last edited by tallship; 09-28-2012 at 02:24 PM.
Reason: maek pritty
|
|
|
09-28-2012, 02:15 PM
|
#39
|
Member
Registered: Apr 2011
Location: British Columbia, Canada
Posts: 304
Rep: 
|
Quote:
Originally Posted by jmccue
I checked out the chart, looks to me the systems used have some minor differences (memory config different, GPU ...). But what I am really curious about are the compiler details. I am far from a 'benchmark person', but wouldn't you want to run the same statically linked binary across all Linux systems ?
John
|
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.
|
09-28-2012, 02:32 PM
|
#40
|
LQ Veteran
Registered: Jan 2011
Location: Abingdon, VA
Distribution: Catalina
Posts: 9,374
Rep: 
|
|
|
|
09-28-2012, 02:40 PM
|
#41
|
Member
Registered: Jan 2011
Posts: 253
Rep: 
|
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%.
|
|
|
09-28-2012, 03:41 PM
|
#42
|
Moderator
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
|
Quote:
Originally Posted by bosth
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.
|
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.
Last edited by TobiSGD; 09-28-2012 at 03:43 PM.
|
|
1 members found this post helpful.
|
09-28-2012, 07:32 PM
|
#43
|
Member
Registered: Sep 2011
Posts: 925
|
I prefer stability over performance. 'nuff said.
|
|
1 members found this post helpful.
|
09-28-2012, 10:07 PM
|
#44
|
Member
Registered: May 2006
Location: Netherlands
Distribution: Slackware64
Posts: 66
Rep:
|
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.
|
|
|
09-29-2012, 01:22 PM
|
#45
|
LQ Guru
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
|
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:
Code:
time tar -xf linux-firmware.tgz
rm -rf linux-firmware
time tar -cJf linux-firmware.tar.xz linux-firmware
time tar -xf linux-firmware.tar.xz
time cp -r linux-firmware test
time openssl bf -salt -in linux-firmware.tgz -out crypt -k test
time openssl bf -salt -in crypt -out uncrypt -k test
time openssl aes-256-cbc -salt -in linux-firmware.tgz -out crypt -k test
time openssl aes-256-cbc -salt -in crypt -out uncrypt -k test
time openssl aes-256-ecb -salt -in linux-firmware.tgz -out crypt -k test
time openssl aes-256-ecb -salt -in crypt -out uncrypt -k test
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.
Code:
No difference. time tar -xf linux-firmware.tgz
No difference. rm -rf linux-firmware
No difference. time tar -cJf linux-firmware.tar.xz linux-firmware
No difference. time tar -xf linux-firmware.tar.xz
No difference. time cp -r linux-firmware test
No difference. time openssl bf -salt -in linux-firmware.tgz -out crypt -k test
No difference. time openssl bf -salt -in crypt -out uncrypt -k test
Slackware is faster. time openssl aes-256-cbc -salt -in linux-firmware.tgz -out crypt -k test
Slackware is faster. time openssl aes-256-cbc -salt -in crypt -out uncrypt -k test
Slackware is faster. time openssl aes-256-ecb -salt -in linux-firmware.tgz -out crypt -k test
Slackware is faster. time openssl aes-256-ecb -salt -in crypt -out uncrypt -k test
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.
|
|
6 members found this post helpful.
|
All times are GMT -5. The time now is 08:01 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|