LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Other *NIX Forums > Other *NIX
User Name
Password
Other *NIX This forum is for the discussion of any UNIX platform that does not have its own forum. Examples would include HP-UX, IRIX, Darwin, Tru64 and OS X.

Notices

Reply
 
Search this Thread
Old 06-09-2013, 03:18 PM   #16
Pearlseattle
Member
 
Registered: Aug 2007
Location: Switzerland
Distribution: Gentoo
Posts: 703

Original Poster
Rep: Reputation: 80

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)

Last edited by Pearlseattle; 06-09-2013 at 04:50 PM.
 
Old 06-09-2013, 04:32 PM   #17
Pearlseattle
Member
 
Registered: Aug 2007
Location: Switzerland
Distribution: Gentoo
Posts: 703

Original Poster
Rep: Reputation: 80
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.
 
Old 06-09-2013, 06:06 PM   #18
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris10, Solaris 11, Mint, OL
Posts: 9,493

Rep: Reputation: 355Reputation: 355Reputation: 355Reputation: 355
Quote:
Originally Posted by Pearlseattle View Post
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.
 
1 members found this post helpful.
Old 06-09-2013, 06:11 PM   #19
273
Senior Member
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 3,352

Rep: Reputation: 773Reputation: 773Reputation: 773Reputation: 773Reputation: 773Reputation: 773Reputation: 773
Quote:
Originally Posted by jlliagre View Post
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.
 
1 members found this post helpful.
Old 06-11-2013, 04:56 PM   #20
Pearlseattle
Member
 
Registered: Aug 2007
Location: Switzerland
Distribution: Gentoo
Posts: 703

Original Poster
Rep: Reputation: 80
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
 
Old 06-11-2013, 05:13 PM   #21
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,579
Blog Entries: 2

Rep: Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036
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.
 
1 members found this post helpful.
Old 06-11-2013, 05:19 PM   #22
Pearlseattle
Member
 
Registered: Aug 2007
Location: Switzerland
Distribution: Gentoo
Posts: 703

Original Poster
Rep: Reputation: 80
Quote:
Originally Posted by TobiSGD View Post
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!
 
Old 06-11-2013, 06:06 PM   #23
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,579
Blog Entries: 2

Rep: Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036
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.
 
1 members found this post helpful.
Old 06-11-2013, 06:06 PM   #24
Pearlseattle
Member
 
Registered: Aug 2007
Location: Switzerland
Distribution: Gentoo
Posts: 703

Original Poster
Rep: Reputation: 80
Quote:
Originally Posted by TobiSGD View Post
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)
 
Old 06-11-2013, 06:30 PM   #25
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,579
Blog Entries: 2

Rep: Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036Reputation: 4036
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.
 
Old 06-11-2013, 06:46 PM   #26
Pearlseattle
Member
 
Registered: Aug 2007
Location: Switzerland
Distribution: Gentoo
Posts: 703

Original Poster
Rep: Reputation: 80
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!
 
Old 06-11-2013, 06:56 PM   #27
273
Senior Member
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 3,352

Rep: Reputation: 773Reputation: 773Reputation: 773Reputation: 773Reputation: 773Reputation: 773Reputation: 773
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 View Post
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.
 
Old 06-13-2013, 03:41 AM   #28
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris10, Solaris 11, Mint, OL
Posts: 9,493

Rep: Reputation: 355Reputation: 355Reputation: 355Reputation: 355
Quote:
Originally Posted by 273 View Post
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.
 
Old 06-13-2013, 07:44 AM   #29
273
Senior Member
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 3,352

Rep: Reputation: 773Reputation: 773Reputation: 773Reputation: 773Reputation: 773Reputation: 773Reputation: 773
Quote:
Originally Posted by jlliagre View Post
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.
 
1 members found this post helpful.
Old 06-13-2013, 10:50 AM   #30
jlinkels
Senior Member
 
Registered: Oct 2003
Location: Bonaire
Distribution: Debian Lenny/Squeeze/Wheezy/Sid
Posts: 4,067

Rep: Reputation: 491Reputation: 491Reputation: 491Reputation: 491Reputation: 491
Quote:
Originally Posted by 273 View Post
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Linux 2.6.30 Gets Faster Boot - but is Fedora Faster? LXer Syndicated Linux News 0 06-11-2009 04:40 AM
LXer: Firefox 3.5 Speed Freak: Faster Development, Faster Performance LXer Syndicated Linux News 0 06-10-2009 02:42 AM
LXer: Firefox 3 Beta 4 is 5x faster than IE7, 3x faster than FF2 LXer Syndicated Linux News 0 03-12-2008 05:50 PM
DISCUSSION: Faster and Faster Compilation jeremy LinuxAnswers Discussion 5 12-06-2005 01:41 AM
Faster Linux CatSC Linux - Newbie 5 11-26-2003 05:25 AM


All times are GMT -5. The time now is 01:41 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration