|
Home > Archive > Unix Programming > September 2006 > Deciding factors to move from 32-bit to 64-bit application??
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Deciding factors to move from 32-bit to 64-bit application??
|
|
| qazmlp1209@rediffmail.com 2006-09-27, 1:21 pm |
| Currently, my application runs as a 32-bit application. I am wondering
whether it will help in improving the performance, if I make it 64-bit.
What are the factors that I should consider, while deciding about it?
| |
| Mikko Rauhala 2006-09-27, 1:21 pm |
| ["Followup-To:" header set to comp.unix.programmer.]
On 27 Sep 2006 07:05:19 -0700, qazmlp1209@rediffmail.com
<qazmlp1209@rediffmail.com> wrote:
> Currently, my application runs as a 32-bit application. I am wondering
> whether it will help in improving the performance, if I make it 64-bit.
> What are the factors that I should consider, while deciding about it?
The main factor is simple: Is your CPU faster in 64-bit mode than in
32-bit mode? The crosspost to .solaris tells me that you're either
running on sparc or amd64. Generally, 64-bit code takes up more space
(pointers are double the size, etc.), causing more cache misses,
causing lesser performance. On amd64, however, 64-bit mode has access
to more registers and can assume the availability of several extended
x86 instruction sets, such as SSE2. This makes 64-bit code likely to
execute a bit faster than 32-bit code on amd64, cache issues
notwithstanding.
So, on sparc, don't go 64-bit unless you need the VM, but you might
want to have a go at it on amd64.
--
Mikko Rauhala - mjr@iki.fi - <URL:http://www.iki.fi/mjr/>
Transhumanist - WTA member - <URL:http://www.transhumanism.org/>
Singularitarian - SIAI supporter - <URL:http://www.singinst.org/>
| |
| Henry Townsend 2006-09-27, 1:21 pm |
| Mikko Rauhala wrote:
> So, on sparc, don't go 64-bit unless you need the VM, but you might
> want to have a go at it on amd64.
There are ancillary factors - for instance, 32-bit processes have limits
on open file descriptors and select. A 64-bit version will have much
higher limits, which may allow you to select on more file descriptors,
which may allow you to write your app in a higher-performance way. But
the main point is that despite the marketing keywords chip companies
like to sell them with, 64-bit is not particularly a performance
enhancer. It does many great things but faster is not one of them.
HT
| |
| Casper H.S. Dik 2006-09-27, 1:21 pm |
| Mikko Rauhala <mjr@iki.fi> writes:
>The main factor is simple: Is your CPU faster in 64-bit mode than in
>32-bit mode? The crosspost to .solaris tells me that you're either
>running on sparc or amd64. Generally, 64-bit code takes up more space
>(pointers are double the size, etc.), causing more cache misses,
>causing lesser performance. On amd64, however, 64-bit mode has access
>to more registers and can assume the availability of several extended
>x86 instruction sets, such as SSE2. This makes 64-bit code likely to
>execute a bit faster than 32-bit code on amd64, cache issues
>notwithstanding.
>So, on sparc, don't go 64-bit unless you need the VM, but you might
>want to have a go at it on amd64.
Or if you need > 256 FILE *s. Or if you run into any of the other
32 bit runtime limitations.
Casper
| |
| qazmlp1209@rediffmail.com 2006-09-27, 1:21 pm |
|
Mikko Rauhala wrote:
> The main factor is simple: Is your CPU faster in 64-bit mode than in
> 32-bit mode? The crosspost to .solaris tells me that you're either
> running on sparc or amd64. Generally, 64-bit code takes up more space
> [snip]
> So, on sparc, don't go 64-bit unless you need the VM, but you might
> want to have a go at it on amd64.
My application runs on sparcv9 processors.
Thanks for the suggestion!
| |
| Maxim Yegorushkin 2006-09-28, 7:33 am |
| Henry Townsend wrote:
> Mikko Rauhala wrote:
>
> There are ancillary factors - for instance, 32-bit processes have limits
> on open file descriptors and select. A 64-bit version will have much
> higher limits, which may allow you to select on more file descriptors,
> which may allow you to write your app in a higher-performance way.
They say select() scales badly, you might not want to use it with a
large number of descriptors in the first place.
http://www.monkey.org/~provos/libevent/
| |
| Casper H.S. Dik 2006-09-29, 1:52 pm |
| "Maxim Yegorushkin" <maxim.yegorushkin@gmail.com> writes:
>They say select() scales badly, you might not want to use it with a
>large number of descriptors in the first place.
>http://www.monkey.org/~provos/libevent/
But the problem with select is that if you want to poll on just one
fd, it needs to be a small one.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
|
|
|
|
|