[SOLVED] SphinUX OS: much faster than Linux?

Pearlseattle · 06-09-2013, 03:18 PM

Btw., to update the SW-repository of SphinUX:

Quote:

you can add this line to your /etc/apt/sources.list:
deb http://de.sphinux.org/repos/deb/exprepo /
then run
apt-get update

(from here)

Pearlseattle · 06-09-2013, 04:32 PM

I'm not able to install Ubuntu 13

- the installer gets stuck when trying to format the root partition (on the usb drive) and it doesn't show what exactly is going wrong or is waiting for => giving up temporarily - will continue tomorrow.

Btw. I said it: Windows is a black box (e.g. the 99% never-ending installations), so Linux should try to highlight transparency. This is a good practical demostration of how Linux should not be.

jlliagre · 06-09-2013, 06:06 PM

Quote:

Originally Posted by Pearlseattle

2)
Yep, I agree that I have no clue from where the 300% less mem used would come from - it would especially involve a new compression algorithm blahblahblah and already only with that you could make a lot of money without having to create a whole new os.

You still fail to understand 300% less memory is pure nonsense.
Let say a reference OS require 1 GB or RAM to work properly, 300% less memory would imply SphinxOS will use no RAM at all and still have 2 GB free to redistribute (out of nowhere just like Madoff investment fund)

Quote:

I can especially agree to the fact that my test program does not make much sense as I expected as well the results to be the same (as as mentioned it could be fully executed in the CPU without external influences), but in the end THEY WEREN'T and because of this I have to continue to drill down and try to understand what's going on... .

The only logical explanations would be one of
- there is an error in the way you have measured or reported the performance
- the compiler defaults to heavy optimization on the phony OS

Quote:

In any case let's not forget that whenever any program runs, there is still a huge dialogue going on between programs and the OS and other programs

There is no huge dialog, nothing that would significantly impact a CPU bound test.

Quote:

otherwise I wouldn't even be able to stop the program from running with [ctrl]+[c] from the X-terminal.

Control-C handling is based on events at the X11 layer and interruptions/signals at the tty / shell one, nothing that impact your test.

273 · 06-09-2013, 06:11 PM

Quote:

Originally Posted by jlliagre

You still fail to understand 300% less memory is pure nonsense.

To be fair this kind of thing is fairly common nowadays in a number of settings. It could be a cultural/translation misunderstanding and, while that doesn't bode well for the OS, I think the meaning they are trying to convey is fairly obvious.

Pearlseattle · 06-11-2013, 04:56 PM

So, I managed to install Ubuntu on my external USB2-HDD.
Both OSs were updated to their latest package versions.

Went back to the first PC I originally used in this thread:
Hardware:

Code:

- Both SphinUX and Ubuntu installed on an external USB2-HDD.
- 8GB RAM
- CPU "Intel(R) Xeon(R) CPU E31270 @ 3.40GHz"

The tests:
1) Compress 4GB-file containing random data (same file on both OSs, generated on another notebook with "dd if=/dev/urandom of=zipme.random bs=64k count=65536"). This test won't fully use the CPU as from time to time the zipped data has to be synch'ed to disk.
2) Compute the first 80000 prime numbers

================================
Details about the OSs:
Ubuntu:

Code:

gcc --version
gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
uname -a
Linux ubuntupc 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

SphinUX:

Code:

gcc --version
gcc (Debian 4.7.2-5) 4.7.2

uname -a
SphinUX #sphinux
sphinux 3.2.32 #1 SMP LSX-arch 1.0.12-1 x86_64 GNU/Linux

================================

Test results - summary:
1) zip compression
Ubuntu: 2 minutes and 10 seconds
Sphinux: 2 minutes and 19 seconds

2) Prime numbers:
Ubuntu: 5 minutes and 15 seconds
Sphinux: 2 minutes and 24 seconds

================================
Test results - details:

Ubuntu:

Code:

time ./a.out 
Enter the number of prime numbers required
The last 80000 prime number is:
qThe last prime number computed was: 1020379

real	5m15.736s
user	5m15.488s
sys	0m0.000s
_________________________________________
time zip /mnt/target/ziptest/zippy.zip /home/somebody/zipme.random 
  adding: home/somebody/zipme.random (deflated 0%)

real	2m10.392s
user	1m55.148s
sys	0m2.352s

SphinUX:

Code:

time ./a.out 
Enter the number of prime numbers required
The last 80000 prime number is:
The last prime number computed was: 1020379

real	2m24.315s
user	2m24.225s
sys	0m0.000s

_______________________________
time zip /mnt/target/ziptest/zippy.zip /home/somebody/zipme.random 
  adding: home/somebody/zipme.random (deflated 0%)

real	2m19.605s
user	1m59.075s
sys	0m2.864s

===============================
Conclusions:
SphinUX lost when compressing the 4GB-file but won by a great margin with the compiled prime number test => maybe jlliagre is right when saying that perhaps SphinUX uses heavily optimized compilation options. Unluckily that's for me still weird as I thought that on my "real" distribution (Gentoo, running on the same PC) I already had some quite good CXXFLAGS & CFLAGS ("-march=native -O2 -pipe -fomit-frame-pointer") and there I almost get the same timings I get on Ubuntu (actually 20 seconds more - 5:40 - but I'm using an older gcc 4.5.4).

I wanted to use the Phoronix Test Suite to run some more tests, but because the architecture of SphinUX is unknown I cannot install any test.

So, don't know what else I should do.
I'll still try to understand why the prime numbers test is so much faster on SphinUX.
Let me know if you have any suggestions for tests and/or checks.
Cheers

TobiSGD · 06-11-2013, 05:13 PM

Compile your prime number test on a different system than the test systems, this way you won't run into compile time tweaks to the system. Then use that binary for the tests.

Pearlseattle · 06-11-2013, 05:19 PM

Quote:

Originally Posted by TobiSGD

Compile your prime number test on a different system than the test systems, this way you won't run into compile time tweaks to the system. Then use that binary for the tests.

Well, if I compile it on the Ubuntu distribution then the best I can expect is that it will run as fast as it ran on Ubuntu. On the other side if I compile it on SphinUX then it won't probably run at all on Linux - but I will still give it a try.
Thanks!

TobiSGD · 06-11-2013, 06:06 PM

Sphinux OS claims that it is faster because it use a different kernel. Since it also uses the Debian userland, it has to run faster even with software compiled on Debian or Ubuntu, otherwise the claims must be a hoax. So you will see if there kernel is really faster, or if they are using dirty tricks.
Since I think that they simply use a Linux kernel with some strings exchanged to make it look different in uname, I assume that the latter will be the case.

Pearlseattle · 06-11-2013, 06:06 PM

Quote:

Originally Posted by TobiSGD

Compile your prime number test on a different system than the test systems, this way you won't run into compile time tweaks to the system. Then use that binary for the tests.

You're a genius TobiSGD!
I took the prime number test that I compiled on SphinUX and copied it to the Gentoo distribution, ran it and the timings are now superfast. The Gentoo version took 5:40 and the SphinUX version 2:25

On Gentoo with version compiled in Gentoo:

Code:

time ./a.out 
Enter the number of prime numbers required
The last 80000 prime number is:
The last prime number computed was: 1020379

real    5m40.713s
user    5m40.490s
sys    0m0.001s

On Gentoo with version compiled in SphinUX:

Code:

time ./a-sphinux.out 
Enter the number of prime numbers required
The last 80000 prime number is:
The last prime number computed was: 1020379

real    2m25.532s
user    2m25.294s
sys    0m0.002s

=======================
Details about the two files:
Gentoo-version:

Code:

ls -l a.out && file a.out && ldd a.out 
-rwxr-xr-x 1 root root 7933 Jun 12 00:57 a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
    linux-vdso.so.1 (0x00007fff0b7c0000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f6c89504000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f6c898af000)

SphinUX version:

Code:

ls -l a-sphinux.out && file a-sphinux.out && ldd a-sphinux.out 
-rwxr-xr-x 1 root root 5235 Jun 12 00:51 a-sphinux.out
a-sphinux.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xec260b6005a386c0f12924c91e4c367b6e1d8796, not stripped
    linux-gate.so.1 (0xf76f2000)
    libc.so.6 => /lib32/libc.so.6 (0xf7533000)
    /lib/ld-linux.so.2 (0xf76f3000)

TobiSGD · 06-11-2013, 06:30 PM

Which means there is nothing special about their kernel and since the benchmark is written by you and therefore can't be compromised it must be a hoax.

Pearlseattle · 06-11-2013, 06:46 PM

You're right.
And by looking at the output of ldd I found out the reason.
The 32bit executable is much faster to execute than the 64bit.
If I now compile on Gentoo the prime number test with "gcc -m32" instead of just "gcc" (which defaults to 64bit) I get as well on Gentoo great timings:

Running on Gentoo compiled on Gentoo

Code:

time ./a.out 
Enter the number of prime numbers required
The last 80000 prime number is:
The last prime number computed was: 1020379

real	2m25.255s
user	2m25.158s
sys	0m0.001s

This explains as well why when using the EeePC (32bit CPU) I did not see any difference when performing this test.

I knew that the "long" datatype uses 4 bytes on 32bit systems and 8 bytes on 64bit ones, but I really did not expect that it would have such a performance impact. Never looked into the details, but on 64bit machines I expected operations that use a 64bit integer datatype to execute exactly as fast as the ones that use a 32bit datatype.
There is obviously more going on than I know of => will check this out but otherwise this is the end of this story.

Thanks to everybody!

273 · 06-11-2013, 06:56 PM

I have been following this thread and almost posted earlier asking whether both systems were running the same 64 bit system, then saw your uname outputs (easy to miss on an EEPC screen).
After that I thought nothing about the architecture since I had assumed as you did.

Quote:

Originally Posted by Pearlseattle

I knew that the "long" datatype uses 4 bytes on 32bit systems and 8 bytes on 64bit ones, but I really did not expect that it would have such a performance impact. Never looked into the details, but on 64bit machines I expected operations that use a 64bit integer datatype to execute exactly as fast as the ones that use a 32bit datatype.

Now I want to know why that processor is slower for 64 bit operations and will have to compile your program to see whether mine is too.

Nice to prove the claims false through experimentation -- good job.

jlliagre · 06-13-2013, 03:41 AM

Quote:

Originally Posted by 273

I think the meaning they are trying to convey is fairly obvious.

I'm afraid that is a naive approach. What is clearly obvious is this OS is a hoax (and possibly a scam) trying to attract attention with bogus statements.

Investigating it is at best a loss of time and at worst a security risk as you are installing binaries with no published source code. The web site clearly lies about some parts of the OS. I wouldn't be surprised your data/network has been compromised, especially as there has been people reporting "phone home" traffic while using it.

273 · 06-13-2013, 07:44 AM

Quote:

Originally Posted by jlliagre

I'm afraid that is a naive approach.

Not really. I just live in the real world where advertising of this type is shoved down everyone's throats on a daily basis. "Two times less" is a pretty common phrase in advertising, for example, and we all know what it means even though we know the phrase used ought to be "half as much" or similar.
As for investigating the OS -- I think putting it behind smoothwall in a VM and playing with nmap and wireshark could be educational.
Similarly Pearlseattle is doing a service by providing clear figures to demonstrate that they are lying and also bringing up an interesting point about 64 bit architecture. Finding that operations take twice as long on 64 bit numbers is interesting, wouldn't you say?
Understanding what lies mean is not the same as falling for them.

jlinkels · 06-13-2013, 10:50 AM

Quote:

Originally Posted by 273

Finding that operations take twice as long on 64 bit numbers is interesting,

No no no NO!!

That is completely opposite of the truth! Operations take two times less processing time on 32-bit systems. That is the correct phrase.

Just kidding though. Completely agree with you on you attitude and statements about false advertising.

jlinkels