LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices

Reply
 
Search this Thread
Old 07-04-2008, 02:49 AM   #1
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
Benchmarking software, compare 32-bit to 64-bit


I don't know if it's a good idea or if it will give useful data, but what I want to do is this. I have a system here, quite powerful, and I want to benchmark a 32-bit version of Linux versus a 64-bit version. Currently I have Slackware 12.1 on it, and I was thinking of running benchmarks on it as is, saving those, then installing Slamd64 12.1 (the 64-bit version of Slackware), doing some more benchmarks, then comparing the results. But, I don't really know what software to use to do this. I know probably there won't be much difference, but some things may actually be different. Can anyone recommend any general benchmarking software to accomplish such a task ?
 
Old 07-04-2008, 02:55 AM   #2
lazlow
Senior Member
 
Registered: Jan 2006
Posts: 4,362

Rep: Reputation: 171Reputation: 171
The easiest way is just to use time (see man time). Run whatever tasks you are interested in while timing them, record it, and do likewise for the other OS. The place you will usually see a significant difference is in stuff that uses a lot of memory. For any system with less than 2gb I would not bother with 64bit, for 2-3 it is a coin toss, for over 3gb use 64bit.
 
Old 07-05-2008, 09:13 AM   #3
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Original Poster
Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
Thanks for the reply, I have 2 GB of RAM, so then it would make a slight difference ?

I know about 'time' and I'll surely use it to time app startup times. Anything else that might be different between the two ? maybe compile times, to compile something big. I can't think of too much else.

EDIT:
Oh, and I did find these benchmarks:
http://www.osnews.com/story/5768/Are...naries_/page1/

Looks like he had the same mentality in doing those as I do. I want to know if most 64-bit apps will actually run slower and be larger ... and indeed there is a lack of such benchmarks for some odd reason. So far, my suspicions are confirmed, most apps in 64-bit will be larger and run slower than 32-bit.

Last edited by H_TeXMeX_H; 07-05-2008 at 09:32 AM.
 
Old 07-05-2008, 12:43 PM   #4
jlinkels
Senior Member
 
Registered: Oct 2003
Location: Bonaire
Distribution: Debian Lenny/Squeeze/Wheezy/Sid
Posts: 4,053

Rep: Reputation: 484Reputation: 484Reputation: 484Reputation: 484Reputation: 484
I might be off track but in history I have seen that every time the architecture changed to a higher bit count, the processor was faster. Not just due to clock speed, but due to the ability to fetch larger chunks of data and instructions at once, and in mathematics carry them out more efficiently. I am back of the era that the 8080 became 8086, 80286, 80386 etc, going from 8 to 16 bit, then to 32.

Despite of what many editors write, how could it be that 64-bits programs become slower? Or isn't true that the data bus width doubled from 32 to 64 bits as well? And the internal cache?

I am talking about programs which are compiled for their respective platforms of course. Which is true in Linux.

jlinkels
 
Old 07-05-2008, 12:55 PM   #5
lazlow
Senior Member
 
Registered: Jan 2006
Posts: 4,362

Rep: Reputation: 171Reputation: 171
For normal day to day stuff you will not see any difference (Firefox, Openoffice, thunderbird, etc). Editing or trans coding video, large (1gb+) gimp files, or heavy number crunching you will see a difference. The reason for the memory limits I mentioned above is two fold. First the apps that take advantage of 64 bit basically require more memory. Second when you get above 3gb of ram 32bit requires duct tape to use it (PAE kernel or equivalent), the transaction time for this creates a performance hit.
 
Old 07-05-2008, 02:27 PM   #6
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Original Poster
Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
Yeah, I heard that PAE is a workaround and is costly, so if I had more RAM it would be worthwhile to use 64-bit. I want to do this mostly so I can see if it's worth it. I know I'll probably end up using plenty of 32-bit libs to make stuff work.
 
Old 07-05-2008, 05:01 PM   #7
lazlow
Senior Member
 
Registered: Jan 2006
Posts: 4,362

Rep: Reputation: 171Reputation: 171
Things have advanced enough now in the 64bit world (at least for RH based) that you should be able to do almost everything in 64bit. The only 32bit thing that I am still using is wine(that I can think of).
 
Old 07-08-2008, 11:33 AM   #8
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Original Poster
Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
Well, ok I did switch over to slamd64 and I did some benchmarks too, if you want here they are:

mean +- std. deviation

tests done with openoffice tgz

1) time tar -xzf OOo_2.4.1_LinuxIntel_install_en-US.tar.gz

32-bit:
Code:
real	3.0   +- 0.1s
user	1.33  +- 0.01s
sys	0.284 +- 0.007s
64-bit:
Code:
real	2.0   +- 0.4s
user	1.332 +- 0.008s
sys	0.245 +- 0.009s
2) time tar -czf test.tgz OOH680_m17_native_packed-1_en-US.9310

32-bit:
Code:
real	9.6  +- 0.2s
user	9.14 +- 0.08s
sys	0.28 +- 0.03s
64-bit:
Code:
real	8.66  +- 0.05s
user	8.36  +- 0.02s
sys	0.233 +- 0.004s
tests done compiling paco (a package manager), why paco ? because it was there at the time

3) time make -j4

32-bit:
Code:
real	16    +- 1s
user	42.24 +- 0.04s
sys	 2.63 +- 0.03s
64-bit:
Code:
real	14.0  +- 0.3s
user	38.57 +- 0.03s
sys	 3.63 +- 0.02s
running glxgears for my GeForce 8800 GTS 512 with latest nvidia drivers, I know it's not a benchmark, but I couldn't think of anything else

4) glxgears

32-bit:
Code:
9530 +- 80 FPS
64-bit:
Code:
9770 +- 30 FPS
the final test, this is the only test in which 32-bit beat 64-bit and by a huge margin too, using imagemagick converting large image

5) time convert mapGWtyria.jpg mapGWtyria.png

32-bit:
Code:
real	1m 14.0  +- 0.2s
user	1m 13.5  +- 0.1s
sys	    0.56 +- 0.01s
64-bit:
Code:
real	1m 53.6 +- 0.5s
user	1m 52.6 +- 0.1s
sys	    0.6 +- 0.3s
I can't understand why it would take 64-bit imagemagick so much longer to convert an image than on 32-bit. Maybe the way it was compiled.

Also, I had custom kernels running at the time the tests were taken, 32-bit = slackware 12.1, 64-bit = slamd64 12.1. Both kernels were specifically optimized for the Core 2, as I have a Core 2 Quad Q9300. Note that compiling was done with make -j4 to simulate a more real world situation, as this is how I compile most things.

EDIT: Oh, and just so you know, all tests showed significant difference between groups (using t-test, alpha 0.05), if you don't know what that is (unlikely), don't worry about it.

Last edited by H_TeXMeX_H; 07-08-2008 at 11:36 AM.
 
Old 07-08-2008, 12:55 PM   #9
amani
Senior Member
 
Registered: Jul 2006
Location: Kolkata, India
Distribution: 64-bit GNU/Linux, Kubuntu64, Fedora QA, Slackware,
Posts: 2,758

Rep: Reputation: Disabled
I have written R programs that produce over 120 pdf/eps graphs in a single run and they would take about 1/2 the time on 64-bit Linux in comparison with 32-bit linux. Imagemagick was not used. 64-bit is the natural choice for heavy computation of course.
 
Old 07-08-2008, 08:37 PM   #10
kenoshi
Member
 
Registered: Sep 2007
Location: SF Bay Area, CA
Distribution: CentOS, SLES 10+, RHEL 3+, Debian Sarge
Posts: 159

Rep: Reputation: 32
The advantage of 64bit over 32bit is the ability to move data in larger chunks, as well as the ability to address more memory. Thus for memory-intensive applications such as databases, it makes a difference when you go 64bit.

As far as speed, well, some applications will run slower in 64bit due to:

- larger pointer size
- larger module/library size
- larger instruction size and cycles

Etc etc etc.
 
Old 07-09-2008, 04:41 PM   #11
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,051

Rep: Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100
Quote:
Originally Posted by H_TeXMeX_H View Post
I can't understand why it would take 64-bit imagemagick so much longer to convert an image than on 32-bit. Maybe the way it was compiled.
Part of compiling ImageMagick is selecting the internal pixel size. The precompiled 32-bit Windows versions I found were available both Q8 and Q16. But the precompiled 64-bit Windows version was only Q16.

The precompiled Linux versions I found weren't identified by pixel size.

In Windows, you can use the ImageMagick command
identify -version
to find out the pixel size. I assume (may test later) that the Linux build has that same command.

If you were comparing a Q8 build with a Q16 build, that would explain the big difference in execution time.

ImageMagick also has an internal caching system, that makes complicated decisions about use of memory vs. temp files, etc. Inferior decisions made in that caching system could lead to enormous slowdown. On a large task, it is likely that the 64-bit build would be confused by a system with a low amount of physical ram and make worse internal caching decisions than a 32-bit build. But I doubt the task you gave it was large enough for that effect. I'm pretty sure you just compared a Q8 build with a Q16 build.
 
Old 07-10-2008, 03:54 AM   #12
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Original Poster
Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
I checked both imagemagick versions and they are both:
Code:
Version: ImageMagick 6.3.7 04/07/08 Q16 http://www.imagemagick.org
both Q16
The image is 8150 x 9154 and about 6 MB as jpg and 65 MB as png.
 
Old 07-14-2008, 06:30 AM   #13
resetreset
Senior Member
 
Registered: Mar 2008
Location: India
Distribution: Dynebolic, Ubuntu 10.10
Posts: 1,320

Rep: Reputation: 51
There are a LOT of differences between 32 bit and 64 bit besides size. Pl. search on the web.
 
Old 07-14-2008, 07:48 AM   #14
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,051

Rep: Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100
I did a similar test with imagemagick and got similar results. I might have time later to rebuild from source (the lib that does the work, not the command line wrapper) to try to figure why the 64 bit is so much slower. I still think it should be faster.

I installed the 64 bit version directly from the Mepis repository using the package manager.

I don't know how to use the package manager to install a 32 bit package in a 64 bit system, so I did that all manually. I wasn't sure I was doing it right, but the result worked. I downloaded the .deb files (imagemagick and those of its dependencies that were needed for this test) from the Mepis ftp site, then opened each using Ark to drag out the data .gz file, then opened that to drag out the executable files. I created /usr/bin32 as a place to put the top level executables. In 64 bit Debian, there is already a /usr/lib32 for lib files that in a 32 bit system would go in /usr/lib, so the major part of installing a 32 bit package is copying from /usr/lib inside the .gz file to /usr/lib32. Each .so in the .gz was actually a pair of a real file and a link (giving the file a second name). I couldn't figure out how to copy those pairs, so I copied each real file, then recreated the link. That left the protection wrong, so I then did a chmod to fix it. I did all that for each required .so file, then tried /usr/bin32/identify and /usr/bin32/convert and they both worked and convert was significantly faster than the 64 bit versions.

both identify -version and /usr/bin32/identify -version show that they are Q16. From the Imagemagick documentation, I would expect the capabilities given by Q16 (missing in Q8) would be very rarely needed, while the performance difference should be significant. So I don't understand why all these Imagemagick packages are Q16. I think most users would be better off with Q8.


BTW, if you happen to know a more automated way to install a 32 bit package in a 64 bit system, please tell me.

Last edited by johnsfine; 07-14-2008 at 07:52 AM.
 
Old 07-14-2008, 09:36 AM   #15
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,051

Rep: Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100
ImageMagick has strange performance characteristics! There must be something wrong (probably in its makefile) wrecking performance of the Linux 64bit Q16 version. But it has plenty of performance strangeness even beyond that.

I tested on Windows with all three prebuilt versions of ImageMagick (32 bit Q8, 32 bit Q16, and 64 bit Q16).

I used a .jpg file that was 23MB (10368 x 7776). It converted to a 90MB .png file.

64-Q16 took 173 seconds, using 638MB of ram.
32-Q16 took 186 seconds, using 638MB of ram.
32-Q8 took 185 seconds, using 322MB of ram.

All those values reproduced with no change at all when rerun in a different sequence.

I don't have exact times for 64-Q16 and 32-Q16 on Linux handy, but as far as I recall, Linux 32-Q16 was much slower than Windows 32-Q16 and Linux 64-Q16 was MUCH slower than even Linux 32-Q16.

On Windows, convert was definitely using just one of the cores of a slow quad core CPU. On Linux, I thought it was using both cores of a faster dual core CPU (in which case slower total time would mean more than twice as slow CPU time) but I'm not sure about both cores and H_TeXMeX_H posted info above saying his copy only used one core.

So in Windows, 64-Q16 is faster than 32-Q16 as it ought to be. So whatever the build issue is with 64-Q16, it is just in Linux.

But why isn't 64 bit faster by a larger margin?

Why is the memory use the same between 64-Q16 and 32-Q16? 64-Q16 should need slightly more memory. And what is all that memory for anyway? 10368x7776 is just 120,932,352 pixels. So it is using over five bytes per pixel (two copies at two bytes per pixel plus ? overhead?).

Then why is the Q8 memory so little above half the Q16 memory? Q8's raw pixel storage would be half of Q16's, but all that overhead should be the same between 32-Q8 and 32-Q16. 322MB is too close to half of 638MB to allow for significant overhead.

Most unreasonable: Why is the execution time of 32-Q8 just one second faster than 32-Q16? Any interesting activity on that 322MB of ram is going to be dominated by cache misses. The 32-Q16 version should have the same pattern of access but need to load twice as many cache lines to resolve the misses (because it is accessing 16 bit values instead of 8 bit). Also, both the 32 bit and 64 bit x86 architecture have cleaner instructions for both 8bit and 32bit values than for 16bit, so that should give Q16 a further disadvantage. It just makes no sense that all that adds up to 1 second out of 186 seconds.
 
  


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
64 bit cpu-64 bit Ubuntu-are there 32 bit app issues? sofasurfer Ubuntu 7 04-09-2014 02:02 PM
Differences in performance for 32-bit and 64-bit software exceed1 Linux - General 10 03-14-2008 04:50 PM
How to install 32-bit software in 64-bit system jshih Linux - Kernel 5 04-14-2007 12:26 PM
32 bit or 64 bit install - is 32 bit easier for a newbie? dms05 Linux - Newbie 3 05-19-2006 03:05 PM
Using 32 bit software on 64 bit Kantonix rahish Linux - Newbie 1 02-24-2006 10:27 AM


All times are GMT -5. The time now is 11:11 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