Supplying 64-bit versions of your software

Do I expect to see a performance gain by building my own client and C ++ server on 64-bit code?

What applications can use a 64-bit specific assembly?

I would suggest that anything that has been widely used for a long time will benefit, or any application that needs huge memory (i.e. more than 2 GB), but I'm not sure what else.

+5
performance 64bit
Nov 27 '08 at 15:18
source share
6 answers

Architectural advantages of Intel x64 vs. x86

  • larger address space
  • richer set of registers
  • can link to external libraries or download plugins that are 64-bit

X64 Architectural Backside

  • all pointers (and therefore many instructions, too) occupy 2x memory, halving the effective size of the processor cache in the worst case
  • cannot link to external libraries or download plugins that are 32-bit

In the applications I wrote, I sometimes saw big accelerations (30%) and sometimes I saw big slowdowns (> 2x) when switching to 64-bit. Great accelerations have occurred in crunch / video processing applications, where I was case-sensitive.

The only significant slowdown I saw in my own code when converting to 64-bit was a massive pointer tracking application in which one compiler made some really bad "optimizations." Another compiler generated code where the performance difference was negligible.

Carry advantage now

Writing 64-bit code is not so difficult in 99% of cases, as soon as you know what to observe. Basically, it comes down to using size_t and ptrdiff_t instead of int when accessing memory addresses (here I assume C / C ++ code). It can be a pain to convert a lot of code that was not written for 64-bit information.

Even if it does not make sense to build a 64-bit build for your application (it probably isn’t), it’s worth the time to find out what it takes to build it so that at least all the new code and future refactorings are compatible with 64 -bit versions.

+14
Nov 27 '08 at 15:54
source share

Before you work too hard to find out if there is a technical solution for a 64-bit build, you must make sure that there is a business case. Are your customers asking for such an assembly? Will it give you a certain foot in competition with other suppliers? What is the cost of creating such an assembly and what business costs will be incurred by adding another element to the accounting, sales and marketing processes?

Although I understand that you need to understand the potential for improving productivity before you can gain access to competitive advantages, I strongly recommend that you approach the problem with the big picture. If you are a small or solo business, you must do this for yourself in order to perform due diligence. If you work in a larger organization, your superiors will be very grateful for the efforts that you thought about these questions (or consider the whole problem just regrettably if you are not ready to answer them).

With all that said, my general technical answer will be that the vast majority of user-oriented applications will not benefit from the 64-bit build. Think about it: how many performance issues in your current application are related to processor binding (or RAM access)? Is there a performance issue in your current application? (If not, you probably shouldn't ask this question.)

If this is a Client / Server application, my bet is that network latency contributes a lot more to client-side performance (especially if your queries usually return a lot of data). Assuming this is a database application, how much of your performance profile is associated with disk latency on the server? If you think about the whole constellation of factors that affect performance, you will get a clearer idea of ​​whether your particular application will benefit from a 64-bit update, and if so, then you need to update both sides or all of your benefits will be received only from server side updates.

+2
Nov 27 '08 at 15:39
source share

Not really anymore. Although writing a 64-bit application may have some advantages for you, as a programmer, in some cases. The simplest example is an application whose primary focus is on the registry. As a 32-bit process, your application will not have access to large registry keys on 64-bit systems.

+1
Nov 27 '08 at 15:21
source share

Continuing with @ mdbritt's comment , creating for 64-bit code makes much more sense [for now] if it is built by the server or if you are distributing Linux users.

It looks like a lot more Windows workstations are still 32-bit, and there might not be a large client base for the new build.

On the other hand, many server installations are now 64-bit: RHEL, Windows, SLES, etc. It would NOT be for them to cut off a lot of potential use, in my opinion.

Desktop Linux users are also likely to run 64-bit versions of their favorite distribution (most likely Ubuntu, SuSE, or Fedora).

The main obvious build advantage for 64-bit, however, is that you circumvent the 3 GB barrier for memory usage.

+1
Nov 27 '08 at 15:46
source share

According to this web page, you benefit most from additional general-purpose registers with 64-bit CPUs if you use a lot and / or deep loops.

0
Nov 27 '08 at 15:25
source share

You can expect amplification thanks to additional registers and a new convention of transmission parameters (which are really associated with additional registers).

0
Nov 27 '08 at 15:26
source share



All Articles