Performance Of 64-bit Application Compare To 32-bit Application.

[yck]

Hi all, i have make an experiment to compare performance between 32-bit and 64-bit application. However, i found that 64-bit performance is 1% slower than 32-bit on large data sets that runs for more than 30 minutes. Is this correct? What else to look out for?

What i really means is.. is that realistic that performance of 64-bit application is not much different compare to 32-bit application? I means speed of application (involve arithmetic computing). Cause from what i read from 64-bit article is 64-bit application have much performance compare to 32-bit application.

For your information, application that i try is involve with many number crunching, or arithmetic computing.

[Michael Tully]

Check out these links, they maybe of some assistance to what you are after.

http://www.specbench.org/
http://www.tpc.org/

Regards
Michael

[Magdi KAMAL]

Hi yck,

I belive that 64-bit apps are much faster than 32-bit. I would say you have to tune your kernel params in order to have the max power of 64-bit apps.

Check following kernel parameters :

streampipes must be 0.
maxssiz
maxtsiz

Magdi

[Tim D Fulford]

Yck

Remember that with a 64 bit app you will need more resource. as a basic example the rough relative throughput speeds are

CPU - 1
Memory - 100
Disk - 1,000,000

If you look at this pyramid moving to 64-bit will (in general) push stuff to the lower level as it will require twice as much space. So by moving to 64-bit Apps if you do not have sufficient CPU cache, or memory you performance could be hit enourmously.

That said the previous reply suggested looking at your kernel settings (shmmax, maxtsiz, maxdsiz, maxssiz, I would also add semaphores to this just in case sem???)

Godd luck

Tim

[rick jones]

i wouldsay that it is not unreasonable for a 64-bit app to have perf close to that of a 32-bit app. it could also be faster, it could also be slower. it really is one of those "it depends on the app" sorts of things.

many if not most "32-bit" apps are also PA 1.1. for PA, a 64-bit app must be PA 2.0. so, many 32 to 64-bit comparisons are actually changing (at least) two variables at once - the "bitness" of pointers and such, and the instruction set used.

at one point, when i compared a 32 bit 1.1 compile of an 8.mumble named from BIND with a 64 bit 2.0 compilation, the 64 bit compilation was about 10% faster.

[Angus Crome]

One other possible explanation;

Many apps that claim to be 64-bit are legacy apps that have been ported. Generally the first releases of these more modern versions are not compiled at a very high optimization level. I would expect that as time goes by, and testing continues, the code optimizations will improve (or the older versions will be phased out, whichever can be done faster/cheaper/smarter).

[yck]

Thanks for your all reply. Anyway, information below this is configuration parameters for my HP machine:
maxdsiz 3221225472
maxdsiz_64bit 1073741824
maxssiz 83570688
maxssiz_64bit 8388608
maxtsiz 67108864
maxtsiz_64bit 1073741824
shmem 1
shmmax 1073741824
sema 1
semaem 16384
semmap 66
semmni 64
semmns 128
semmnu 30
semume 30
semvmx 32767

How can i determine which setting should be suitable for 64-bit application? Like where can i refer to?

And lastly, is that 64-bit application didn't have much performance compare to 32-bit application if main function of application is to make arithmetic computing?

Thanks all again.

[Tim D Fulford]

Yck

Some of your max?siz parameters are larger than your max?siz_64bit!!!

I would suggest (well I usually use) the following

maxdsiz ==> 0.5 to 1x your memory
maxdsiz_64bit ==> 0.5 to 1x your memory
maxssiz ==> 0.5 to 1x your memory
maxssiz_64bit ==> 0.5 to 1x your memory
maxtsiz ==> 0.5 to 1x your memory
maxtsiz_64bit ==> 0.5 to 1x your memory
semmap (SEMMNI+2)
semmni 4096
semmns 4096
shmmax ==> 0.5 to 1x your memory

The above is from experience, so may not be 100% applicable to you situation. We arrived at it by requirements from various apps or has needed to be increased due to some system shortage. (e.g. we did a massive memory data load & found that maxdsiz was not big enough)

Tim