AMD Shanghai Opteron: Linux vs. OpenSolaris Benchmarks

[etacarinae]

$ du -hb pts-trondheim.wav
81904044 pts-trondheim.wav

This is built with Sun Studio Express (CFLAGS="-fast -m64"), run on a measly T8300 based laptop.

$ file lame
lame: ELF 64-bit LSB executable AMD64 Version 1 [SSE2 SSE FXSR CMOV FPU], dynamically linked, not stripped

$ time ./lame -h pts-trondheim.wav /dev/null 2>&1
LAME 3.98.2 64bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding pts-trondheim.wav to /dev/null
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
17776/17776 (100%)| 0:37/ 0:37| 0:38/ 0:38| 12.268x| 0:00
-----------------------------------------------------------------------------------------------------------
kbps LR MS % long switch short %
128.0 13.9 86.1 91.6 4.9 3.5
Writing LAME Tag...done
ReplayGain: -8.8dB

real 0m37.933s
user 0m37.808s
sys 0m0.067s

This is with gcc 3.4.3, on the same machine:

$ file lame
lame: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available

$ time ./lame -h pts-trondheim.wav /dev/null 2>&1
LAME 3.98.2 32bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding pts-trondheim.wav to /dev/null
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
17776/17776 (100%)| 0:43/ 0:43| 0:43/ 0:43| 10.764x| 0:00
-----------------------------------------------------------------------------------------------------------
kbps LR MS % long switch short %
128.0 13.9 86.1 91.6 4.9 3.5
Writing LAME Tag...done
ReplayGain: -8.8dB

real 0m43.244s
user 0m43.103s
sys 0m0.065s

Sure, I will (if I find the time to do it).

[kraftman]

I dont know much about Linux, so I dont know how old the kernels are. But this test seems better. I will have to read it later. Thank you. I hope they didnt do anything like in the Phoronix benches: 32bits binaries against 64bits, use old version of software vs new versions, etc. I will see if they are doing something similar. As someone showed, 64 bits binaries Opensolaris doubled the numbers and Opensolaris should have won easily.

They did those test to decide what system will best fit to their needs. Seriously I'm not sure if they do something similar or not, but it seems to be more fair benchmark. As you can see Etacarinae gained only few percent when using 64bits, but it's only one test.

About linux scaling:

http://blogs.zdnet.com/BTL/?p=8769

"you don?t currently see the level of geometric performance increases on Linux above 16 cores like you do with UNIX. The maturity in the Linux kernel for this level of enterprise performance and stability on this type of hardware just isn?t there yet."

About Linux as a file server:
http://www.enterprisestorageforum.co...le.php/3745996

It always depends on who benches There was/is known scaling problem when you use bad library. Here's great example:

http://ozlabs.org/~anton/linux/sysbench/

Btw. this is old, but interesting article about FUD about Linux scalability:

http://searchenterpriselinux.techtarget.com/news/article/0,289142,sid39_gci929755,00.html

[etacarinae]

...
As you can see Etacarinae gained only few percent when using 64bits, but it's only one test.

Over 12% gain is not a few percent...

[kraftman]

Over 12% gain is not a few percent...

OK, but it would be still slower in Phoronix benchmark and same flags should be used on Linux.

[etacarinae]

Why would it be slower ? Their 8 core system compressed the SAME file on Linux in 35 seconds, while my 2 core laptop processor did it in 38 ?

OK, but it would be still slower in Phoronix benchmark and same flags should be used on Linux.

[kraftman]

Why would it be slower ? Their 8 core system compressed the SAME file on Linux in 35 seconds, while my 2 core laptop processor did it in 38 ?

If you gained 12% on your laptop Solaris should gain the same on Phoronix computer, so still slower than Linux. Don't compare results on two different computers. Why don't you do tests using Linux too?

[etacarinae]

This is only if you assume that the dependency is linear with the same number of cores that I have. As I said, they used an 8 cores system. Not to mention other optimizations SunStudio might do for AMD processors.

If you gained 12% on your laptop Solaris should gain the same on Phoronix computer, so still slower than Linux. Don't compare results on two different computers. Why don't you do tests using Linux too?

[Kano]

Using lots of cores does not automatically gain speed - maybe for compiling with -j X make option but not for standard apps. Many apps use only one thread or maybe 2 then more cores would not help.

[kebabbert]

They did those test to decide what system will best fit to their needs. Seriously I'm not sure if they do something similar or not, but it seems to be more fair benchmark. As you can see Etacarinae gained only few percent when using 64bits, but it's only one test.

And two other OpenSolaris tests in the old Phoronix benchmark, Linux vs FreeBSD vs OpenSolaris, gained 80% and 100% going from 32bits to 64bits. It seems that the OpenSolaris benches should be increased from 12% to 100%. Then it would look different, right?

It always depends on who benches There was/is known scaling problem when you use bad library. Here's great example:
http://ozlabs.org/~anton/linux/sysbench/

Actually, measure "scaling" on 4 cpus is not really what I mean to be scalable. I talk about hundreds of CPUs with many more threads. Measuring 4 cpus is not really interesting, I think.

Btw. this is old, but interesting article about FUD about Linux scalability:
http://searchenterpriselinux.techtar...929755,00.html

Interesting link. He talks about all the FUD about Linux scalability. There are "evil" vendors claiming that Linux scales bad, he says. Then he says that it is just FUD. Linux scales very well, he says. He mentions evidence of Linux scalability: large clusters with specially modified Linux kernels, non standard Linux (which is not really evidence of scalability according to me). He spends lots of energy on proving Linux bad scalability is only FUD.



Lastly he says things as:

"In 1998, Linux would successfully run on one to two CPUs. Today, it can handle eight or more CPUs."

"With the 2.6 kernel, the vertical scaling will improve to 16-way."
Wow! 16 cpus! That is really really good! (NOT). Why does he talk about large Linux clusters with thousands of machines as a proof on Linux scales well, and at the same time declares that in several years from now, Linux will handle 16 cpus? Is 16 CPUs something to brag about?

"Question: Two years from now, where will Linux be, scalability-wise, in comparison to Windows and Unix?
O'Keefe: It will be at least comparable in most areas."


Is it only me thinking he seems to be contradicting himself? First he goes on and on how good Linux scales, and concludes saying that "Linux will be at least comparable with Unix" in a few years? But at the same time "evil vendors claims that Linux doesnt scale well as the other Unix"? Is he stupid, or what? Doesnt he see his own contradictions? Is Linux scaling well or not? If he brags about 8-16 cpus, then Linux scales bad.

To me it seems that Linux people thinks that scalability is about 4-8 CPUs. The Solaris people talks about hundreds of CPUs. With the very same kernel, unmodified. Now THAT is scalability.

I dont get it. What is wrong with the Linux people? Someone posted links to a comparison on a 800MHz SPARC vs 2.8GHz Xeon Linux and claimed that as evidence of Linux being faster. And now above, this moron claims Linux scales very well, and it is just FUD and at the same time he brags about 8CPUs? And this phoronix benchmarks, 32bits against 64bits with an old compiler - how dumb is that? I really really wonder, how can the Linux people call this fair?

[etacarinae]

This is precisely why I indicated the assumption, I haven't looked at lame's code so I don't know the level of parallelization there, if any.

Using lots of cores does not automatically gain speed - maybe for compiling with -j X make option but not for standard apps. Many apps use only one thread or maybe 2 then more cores would not help.