24

Delphi 64 bits is on its way as everybody knows (every delphi programmer at least) . Apart from what codegear says about the benefits of a 64 bits Delphi app (and codegear does not say much about), what will I benefit from having a 64 bits Delphi application? It is really a good idea to port my app to 64 bits as soon as codegear releases it?

EDIT:

I am just asking it because I want all opinions I can have. For now, I can say that I really need more memory available to my application because it consumes a lot of resources. I really could use more speed, if it is possible. I do not need shell extensions neither plugins.

My customers are also asking me about a x64 version of my app, but I really do not understand why they are asking for it, because they are actually lawyers who have no idea what is a 64 bits application.

EDIT

I actually do not participate directly into the app development. I am part of a technology team and I create stuff that other developers in the company I work for use to really develop the final app. So, my job is to do technical stuff, and port a app to x64 is the kind of thing I do, but I need to explain why I am doing that to my superiors.

casperOne
  • 73,706
  • 19
  • 184
  • 253
Rafael Colucci
  • 6,018
  • 4
  • 52
  • 121
  • "...because it consumes a lot of resources" doesn't mean you need 64-bit. It probably means you need to manage resources better. Availability of more memory doesn't mean you shouldn't use good practices with resource use; you should use the extra if you have no alternative, as my post mentions. I have apps that process 100s of thousands of medical claim transactions daily, and I won't gain anything from 64-bit for them other than a probable slow-down. 64-bit doesn't automatically mean faster; in fact, it often means slower except for certain operations that depend on large memory allocations. – Ken White Apr 15 '11 at 01:21
  • An edit put my comment below your reply, for other's reference. I wasn't trying to insult your code (or imply that I knew your app). I was pointing out that without a compelling need, your app won't benefit from 64-bit (as my edit tried to explain using my own apps as an example). No offense or criticism was intended, Rafael - if it sounds that way, I'll be happy to delete the comment. – Ken White Apr 15 '11 at 01:22
  • I am sorry, I misunderstood your post. I will delete it. Thanks for you help and sorry again. – Rafael Colucci Apr 15 '11 at 01:28
  • About the x64 version which is mandatory according to people unaware of what a computer is, you can easily say that your Delphi application adapts itself to x64 version of Windows, and is a already a 64 bit application. I'm quite sure there are some Int64 variables somewhere in the code, so, for people how don't know about what a CPU register is, you're already doing 64 bit calculation in your Delphi application. A bit "Jesuistic" as an answer, but to a wrong question, there is no right answer. You're the technical man here: YOU have the knowledge. Lawyers are doing this all day. So do it. – Arnaud Bouchez Apr 15 '11 at 05:30
  • 3
    If you have a splashscreen, add "64-bit certified" or "runs on 64-bit systems" or some other meaningless claim with 64-bit in it. Now the lawyers won't complain anymore. ;) – The_Fox Apr 15 '11 at 07:04

7 Answers7

30

A 64-bit program has the following advantages over the same one compiled for 32-bit (x86):

  • More registers. 64-bit x86 chips have several more registers and this can, in theory (if the compiler takes advantage) result in faster code in some cases.

  • More memory. With a 32-bit program you were generally limited to either a 2GB address space or a 4GB address space in total, if you compiled with /LARGEADDRESSAWARE, which was about 3.5GB in practice due to Windows' kernel/userspace split. A 64-bit process can address much more. This is only important if your app needs a lot of memory.

  • Ability to build plugins for 64-bit programs, like Explorer. Unless you're using COM for a plugin, where data is marshalled, you can't mix 32-bit and 64-bit code in the one process in Windows, such as a 64-bit EXE loading a 32-bit DLL. If you wanted to write an Explorer plugin, for example, you couldn't have it work with the 64-bit version of Explorer with old versions of Delphi. You will be able to with the 64-bit version.

  • Delphi-specific: the compiler will use SSE/SSE2 instructions for floating point calculations, where the current 32-bit compiler only uses x87 FPU instructions (I think.) This should give a speed increase for floating-point math. You probably won't even notice unless your app is highly FP-dependent (a game, perhaps, or a data processing application, that kind of thing.)

The answer to your question "will I benefit from having a 64 bits Delphi application?" is highly dependent on your specific application. In general, there is unlikely to be much benefit beyond, possibly, a small speed increase. Don't rely on 64-bit to speed up a slow application though: you will still need to make algorithmic changes for large speed boosts. 64-bit isn't a magic bullet. Other than that, you only need to change if you've already encountered one of the limits imposed by 32-bit - I suspect you haven't, or you wouldn't be asking the question.

If you decide to convert, you may find this thread very useful.

But one other thing: even if you don't need to change, you might want to, especially if your app is a personal project. You might learn stuff, your code will be higher quality when you fix 32/64-bit issues, and a project like that can be fun. You're a programmer, after all :)

Edit: I see you have updated your question with "I can say that I really need more memory available to my application because it consumes a lot of resources. I really could use more speed, if it is possible."

  • What resources? Memory? 64-bit will give you a greater addressable address space, that's it. It won't give you more GDI handles, etc, if those count as resources. However, if you truly do need more memory, then 64-bit will be worth converting to.

  • "More speed", if you want a big difference, is more likely to be achieved through algorithmic or threading changes than through a 64-bit compiler.

  • "My customers are also asking me about a x64 version of my app, but I really do not understand why they are asking for it, because they are actually lawyers who have no idea what is a 64 bits application." Chances are they've heard that 64-bit is better or faster. In an ideal world, customers would have reality-based requirements, but this isn't always the case. Pragmatically speaking if the customer wants something like this, it may be worth converting simply because it makes them happy: happy customers are good, and they may pay you for the new version, and it may help your company's word-of-mouth reputation.

Community
  • 1
  • 1
David
  • 13,360
  • 7
  • 66
  • 130
  • 6
    +1 for the very nice and explanatory post. – Rafael Colucci Apr 15 '11 at 01:07
  • Afaik handles are pointers/handles to memory mapped in the kernel memory space. The kernel memory space in 32-bit windows is 1 or 2 GB. The kernel memory space in 64-bit windows is IIRC half of the addressable range. I think there are handles available in 64-bit :-) – Marco van de Voort Apr 15 '11 at 10:54
  • 1
    Hi Marco! I'm afraid I'm not sure what you're saying. Handles are opaque and shouldn't be treated as pointers (although they may be. They may also be indices, hashes, pointers to pointers, who knows.) Or, are you saying that the `HANDLE` / `THandle` type is now wider? I was referring to the [limit on GDI handles](http://msdn.microsoft.com/en-us/library/ms724291.aspx) - as far as I know, address space or not, this still applies in 64-bit versions of Windows. I think many other system resource limits are the same too. – David Apr 16 '11 at 12:51
  • For me, the main use for 64 bit windows is that native 64 bit applications written in Delphi can make shell extensions, usable with the 64 bit windows explorer, and 64 bit DLLs and COM objects, that are living in the native Win64 world instead of in the Win32 (WOW) bubble, which is in fact, a virtual win32 environment. As time goes by, the list of handicaps incurred by only having a Win32 app will become larger and larger, as the Win64 world will eventually probably become more common and every-day than 32 bit apps. Delphi has to provide both 64 and 32 bit or else eventually it will die. – Warren P Apr 16 '11 at 17:46
  • 1
    David M: It's more that the max room from which memory attached to handlesh handles are allocated is known, and significantly increases in 64-bit. By default Windows NT variants take half the address space as kernel memory, and the bulk of that is used for dynamic handle allocation. As an exception, from XP onwards, 32-bit x86 can be switched between 1 and 2GB kernel space (the 1GB kernel space ups the room for application memory space) – Marco van de Voort Apr 18 '11 at 14:12
  • David M: there is a small extra advantage, namely that addresspace is typically again vastly bigger than actually memory in the system. One can easily memorymap e.g. a 50GB BD image in the difference. – Marco van de Voort Apr 18 '11 at 14:14
14

Do you have an actual need to access large (> 4GB) of memory in your application, like video or image processing, or processing of huge amounts of data very quickly? Is your application a shell extension that needs to run on 64-bit versions of Windows? Do you have customers or clients that are complaining because a 64-bit version of your app isn't available?

If you had a need for an immediate update of your app to 64-bit, you'd know it already. Since you don't, you probably have lots of time to do so - remember that 32-bit versions of most applications work fine on 64-bit Windows versions.

Ken White
  • 123,280
  • 14
  • 225
  • 444
  • IMO, in response to the "customer or clients that are complaining", if none of the previous conditions applies, the customers don't know what they're talking about and are doing themselves a dis-service by pestering you about it. – Chris Thornton Apr 15 '11 at 00:26
  • @Chris: Agreed 100%. However, sometimes customer demand (whether justified or not) can influence things, depending on your particular market. – Ken White Apr 15 '11 at 00:30
10

If you write shell extensions, you already know why you need 64. In my case, I have a DLL that gets loaded by Windows Explorer, and it cannot, absolutely will not, load a 32-bit DLL. There ARE apps that will benefit from 64-bit, but most, IMO will not. And for things like mine, 64-bit is more of an annoyance than anything else.

Good idea? Only if you think it'll make you more $$$. Otherwise, the time is better spent improving quality or adding features. Unless you're using pure native VCL controls and libraries, you'll likely have to wait for 3rd-party support to catch up. I am still fixing and replacing libraries, related to converting to Unicode....

Chris Thornton
  • 15,620
  • 5
  • 37
  • 62
5

Most programs won't care.

I have exactly one program I have written that I would make a 64-bit version of and that would be to increase the cache size and even then it's only because what I think would be the best tradeoff puts the maximum memory use somewhat over 2gb.

Loren Pechtel
  • 8,945
  • 3
  • 33
  • 45
  • @Loren, if you want over 2GB, but less than 3.5, try building with the `LARGEADDRESSAWARE` PE flag. You can do this with `{$SetPeFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}` I think, in Delphi, and by setting the image flag in the project options in C++Builder. – David Apr 15 '11 at 06:42
  • @david what do you mean 3.5? You get the full 4. – David Heffernan Apr 15 '11 at 06:47
  • @David Heffernan: on 32-bit windows, you won't be able to allocate 4GB because some of that is still reserved by the kernel. Running on 64-bit Windows you can access the full 4GB address space, yes. – David Apr 18 '11 at 01:33
  • My point (which probably wasn't explained well) was that Loren wants more than 2GB and he can get more than 2GB on 32-bit Windows, it doesn't require 64-bit (Windows or Delphi). Ie, he may be able to achieve what he wants already without waiting for the 64-bit compiler. – David Apr 18 '11 at 05:19
  • @david m it will be 2gb on 32 bit windows. The operating system reserves 2gb of address space for itself in 32 bit windows. – David Heffernan Apr 18 '11 at 06:33
5

One situation where 64 bit will matter is for data-parallel, multi-threaded numerical applications on many-core machines. For such an app the 32 bit address space can be constraining if the data cannot be split into small enough pieces.

Other than that the biggest push to 64 bit is for extensions to other programs. For example shell extensions, Excel add-ins, MATLAB extensions etc.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • very curious to know why this was downvoted. – David Heffernan Apr 15 '11 at 06:48
  • My guess: because of your claim on `multi-threaded numerical applications on many-core machines`. I trust you on that one because I know you're dealing with numerical applications, but it's very unintuitive! Might want to explain that a bit. – Cosmin Prund Apr 15 '11 at 07:40
  • @Cosmin I thinking of data parallel muult-threaded algorithms. – David Heffernan Apr 15 '11 at 07:50
  • @David, I can see it happening, but it takes a stretch of the imagination: it requires both unusually powerful hardware and lots of data to be crunched. I'm not working on numerical applications so it might not be unusual in that domain, but looking at my 8-way desktop, each thread would need to work on grater then 200Mb chunks of data before that became a problem. – Cosmin Prund Apr 15 '11 at 08:19
  • 2
    @Cosmin As of today I am dealing with a client who has a quad procesor, quad core machine, with 4 threads per core. That's 64 cores. And as it happens, my app works with finite element models that can be big enough to cause problems. At the moment the solution is to use separate processes but this is inconvenient to the user. A 64 bit Delphi would make this problem vanish. – David Heffernan Apr 15 '11 at 08:22
  • 2
    I wonder what is really multicore about that. Essentially you say "sometimes you need more memory" It doesn't matter if it is a medium sized one multiplied by a bunch of cores, or one big one handled by one core, and such statements only cloud the overall picture. – Marco van de Voort Apr 15 '11 at 11:59
  • @Marco The models that each thread processes are the same size. So, if you have more threads then you need more memory. – David Heffernan Apr 15 '11 at 12:09
  • Yes, and there are umpteen other reasons why one could need more memory. This is a bit too much buzzword dropping for me. And moreover, with more threads/cores all sizable data could be shared, and thus not significantly add memory – Marco van de Voort Apr 18 '11 at 14:06
  • 1
    @Marco How would you shared the data? Data-parallel means that each core operates on different data. It seems to me that everyone who has questioned the validity of my assertions has done so with a lack of appreciation for this type of problem. That's understandable because I suspect that few of the SO Delphi experts have much experience in this field. – David Heffernan Apr 18 '11 at 14:14
  • Well, the need for such artificial restrictions only strengthens my point. Parallelism is either on processor level (each processor having his own QP/HT links to own mem), or not at all. I don't know a machine with data parallellism on core level. – Marco van de Voort Apr 18 '11 at 20:48
  • 1
    @Marco You don't know anything about the application I am talking about. How can you make such judgements. The restrictions are not artificial. They are natural. – David Heffernan Apr 18 '11 at 20:50
  • Your app is just a special case of eating memory. There are zillion ways to do that, and IMHO the special circumstances of your application aren't terribly relevant for this threads subject. The rest is just a reply to your remarks that it is a special case distinct from eating memory. I still think it is just buzzword namedropping – Marco van de Voort Apr 20 '11 at 19:37
  • 1
    @Marco Well, you may be right, but the engineers around the world who choose to use it to design their offshore structures disagree – David Heffernan Apr 20 '11 at 19:50
3

No, keep your application 32 bit.

"My customers are also asking me about a x64 version of my app, but I really do not understand why they are asking for it"

What your users want is for your application to work perfectly on a 64 bit version of Windows. You should test this and tell them you have tested it and that it runs correctly on 64 bit Windows.

soid
  • 541
  • 8
  • 15
  • Although I don't agree that it's unnecessary to create a 64 bit version of your software, I give you +1 because you are perfectly correct in saying that "what your users want is for your application to work perfectly on a 64 bit version of Windows". – lkessler May 20 '11 at 04:36
3

I have this problem with some of my clients. It largely happens because the IT departments in their respective companies have a check-list of things that need to be 'considered' when the company purchases new software (or approves updates, etc). From time to time these check-lists get updated to better reflect the modern IT landscape but that doesn't always mean that the new elements make sense in the context of your own application software.

At some point, people started saying 'as we have 64bit Windows XP/Vista/7 etc, we need to make sure any new software is 64bit too'. As developers we know that this isn't necessarily the case but if you try to explain this to non-technical people it usually comes over as you trying to cover-up the fact that your app isn't actually 64bit. When you're a small bespoke vendor in cut-throat competition with other vendors, you can't let your work lose out because of a largely irrelevant/unimportant 'feature' on someone's check-list.

My approach thus far has been to tell clients that the software has been thoroughly tested and validated on 64bit Windows but has developed so that the same exact version can run on either 32bit or 64bit Windows. It's perfectly true because my apps are largely Delphi 2007 based, and in the last year or so I've started doing all of my testing on 64bit Win7 as a first resort (and then performing a subset of tests again under 32bit XP, at key milestones).

As an aside, both in the small business environment and (more surprisingly) the home one, I've seen far more 64bit Win7 installs than 32bit ones. Most new machines I've seen in the last 6 months seem to have come with 64bit Win7, which I find quite interesting.

I also like The_Fox's comment to the original question - I may have to update my splash screens accordingly. Especially if I can detect that the program is running on a 64bit version of Windows...

robsoft
  • 5,525
  • 4
  • 35
  • 47