32bit vs 64bit

[chkaufmann 17]

We are in the discussion if we should switch our application from 32bit to 64bit. Basically it seems to work fine under 64bit, however I'm not sure, if there may be some problems regarding resource usage.

 

Our main customer runs the application on an RDP Terminal Server. So my concern is, if this is relevant because a 64bit application always uses more RAM compared to the 32bit version.

 

Christian

[Uwe Raabe 2064]

JM2C, if your application runs fine as 32-Bit I would leave it as is. At least the development in the Delphi IDE will give you a better experience. It doesn't hinder you to provide a 64-Bit version on top.

[FPiette 385]

Why do you think you need 64-bit application? Do you have memory size issue (Like very large images to process)?

As Uwe said, developing in 32 bits will give you a better experience.

Latest Delphi 11.2 support ALSR for 64 bit. This could be a reason to move to 64 bit. Using ALSR result in a slightly more secure application.

[shineworld 73]

I could easily be proven wrong; I haven't looked into this very deeply, but from what I make of the 32- and 64-bit versions of the applications, it seems to me that the 64-bit version gains a few percent in performance.
The projects are complex and use a lot of memory and graphics, including 3D, but running both exe's, the 64-bit one gives me a better time log.

Debugging in 64-bit, however, is more difficult because of constant IDE crashes (10.4.1 at the moment).

 

Edited September 12, 2022 by shineworld

[David Heffernan 2353]

It's true that the 64 bit Windows debugger is a disaster zone. But I just debug with the 32 bit debugger. You can have a project with both 32 and 64 bit targets. You can then ship just the 64 bit if you prefer. But you can still use the 32 bit debugger during development, because it's the one that is actually useful.

[chkaufmann 17]

2 hours ago, FPiette said:

Why do you think you need 64-bit application? Do you have memory size issue (Like very large images to process)?

I have no memory issues anymore since I solved these with other changes in the code.

 

Maybe I'm too old, but personally I think, because there is need to change I would stay with 32bit.

 

But others in our team think we should change to 64bit because this is the technology of today. Therefore I try to collect objective arguments (pros and cons).

 

Christian

[Fons N 17]

3 hours ago, David Heffernan said:

You can have a project with both 32 and 64 bit targets.

True, but... the Extended type, for example, are different in 32 and 64 bit - at least in Windows. I don't know if there are other differences between 32 and 64 bit that affects the generated code. There probably are. My knowledge is limited compared to Delphi experts.

 

For me 32 bit is fine... however, for alle purchased components and libraries I do not only want the source code, but also checks if it works in both 32 and 64 bit. Just in case Windows drops 32 bit and I need to compile in 64 bit. Just recently I was looking for a good PDF component (to create PDF files) and came across one that only worked in 32 bit, so that was a no-go.

 

[FPiette 385]

Quote

I have no memory issues anymore since I solved these with other changes in the code.

By memory issue, I meant not enough memory to handle large data in memory, not memory leaks.

Quote

Maybe I'm too old, but personally I think, because there is need to change I would stay with 32bit.

Agreed.

Quote

But others in our team think we should change to 64bit because this is the technology of today.

That is not a good idea at all. And I would not classify 64 bit as a technology that matters for computer software. It has been invented to overcome the 32 bit memory space which begins to become to small for some kind of data. Beside memory only some computation is faster with a 64 bit CPU. Mainly computation requiring 64 bit integers.

 

It is also beneficial to have a 64 bit OPERATING SYSTEM that is able to run 32 bit software natively. No need to have a 64 bit APPLICATION to get benefit of a 64 bit OPERATING SYSTEM.

 

I have a 64 bit CPU running Win10. I have installed 64GB of memory which would not be possible with a 32 bit computer. I benefit of the 64 bit memory space even with 64 bit applications. I can run more large 32 applications side by side without impacting performances.

[FPiette 385]

Quote

for all purchased components and libraries I do not only want the source code, but also checks if it works in both 32 and 64 bit. Just in case Windows drops 32 bit and I need to compile in 64 bit.

That is a good decision.

[Clément 148]

I also do not required 64 bit, but there's no point in fighting network administrators wanting to keep a 64 bit machine running only 64 bit processes over a few extra MBytes.
While I agree there's technically no reason to upgrade, there's a "keep your life simpler" and "don't pick a fight you won't win" factors.

If you work with 3rd party applications sharing the same machine then you might keep your life simpler when everything is the same bitness.
I had to configure Oracle to work with both 32 and 64 bits, as my application required 32 bit dlls to work with (OCI and the like).
Not hard, but it requires some tweaking.
When I upgrade, I must make sure every 64 bit applications are running, but when they upgrade they don't give a squat about mine. I never understood how some application installation was able to damage my dual Oracle Client Setup. BUT....it's my phone that rings.
I got tired to listen to "Every other application is modern and works in 64bits, why can't yours" arguments.

I compiled/debugged/released 64 bits. It uses more RAM, from 27MB it went to 35MB. But no more 32 bit installation tweaking, and no more messed setup after upgrades.

 

Clément

[David Heffernan 2353]

24 minutes ago, Fons N said:

Extended type, for example, are different in 32 and 64 bit - at least in Windows

True, but nobody should be using that type anyway. I speak as a developer of mathematical software.

[Stefan Glienke 2019]

2 hours ago, David Heffernan said:

nobody should be using that type anyway

Too bad it's the implicit default type in many places - be it float literals or parameter types.

[Leif Uneus 43]

2 hours ago, David Heffernan said:

True, but nobody should be using that type anyway. I speak as a developer of mathematical software.

I'm nobody. I still use the extended type, and I'm a developer of mathematical software. 

The algorithm was the only one that could be executed fast enough (and with the precision needed) in the days of Turbo Pascal.

Sure, there are other algorithms today that has better performance without the extended types, but why invest time when it's still fully functional.

Edited September 12, 2022 by Leif Uneus

[Stefan Glienke 2019]

7 minutes ago, Leif Uneus said:

Sure, there are other algorithms today that has better performance without the extended types, but why invest time when it's still fully functional.

Carriages also once were the fastest way to travel - yet nobody today complains that he can't go onto the highway with one.

 

On topic:

If the 64bit Delphi compiler(s) (and significant parts of the RTL) would not be even worse than the 32bit compilers and the debugging experience would not be an absolute nightmare I would switch instantly - it's proven that even though a 64bit application might use a bit more memory because the pointers are double the size due to architectural differences it simply can perform better. Simply having more registers is already a huge gain.

Edited September 12, 2022 by Stefan Glienke

[Leif Uneus 43]

2 minutes ago, Stefan Glienke said:

Carriages also once were the fastest way to travel - yet nobody today complains that he can't go onto the highway with one.

At the time it was like a Concorde. Name a mean of travel that is faster for the public today. 

[Stefan Glienke 2019]

2 minutes ago, Leif Uneus said:

At the time it was like a Concorde. Name a mean of travel that is faster for the public today. 

I can tell you from experience that traveling with an airplane has significant overhead if you live approx 100km from an airport that has flights going to your destination.

You missed the point - when David mentioned that nobody should be using Extended he most likely stated a well-meant suggestion and did not include the "I started using Extended like decades ago and don't wanna change it" case.

[pcoder 4]

3 hours ago, David Heffernan said:

True, but nobody should be using that type anyway. I speak as a developer of mathematical software.

With 80bit float you have less error and larger numeric range. Your statement is helpful only if you have an alternative (library) for larger precision.

[Leif Uneus 43]

1 hour ago, Stefan Glienke said:

You missed the point - when David mentioned that nobody should be using Extended he most likely stated a well-meant suggestion and did not include the "I started using Extended like decades ago and don't wanna change it" case.

No, I know what he meant. And from a discussion we had a couple of years ago I can only agree. I may have to rewrite the code eventually if I move to another platform, but until then I have a well working application.

[David Heffernan 2353]

1 hour ago, pcoder said:

With 80bit float you have less error and larger numeric range. Your statement is helpful only if you have an alternative (library) for larger precision.

Given that the suppliers of hardware have dropped support for extended I would suggest that you are out of date. 

[David Heffernan 2353]

2 hours ago, Stefan Glienke said:

Too bad it's the implicit default type in many places - be it float literals or parameter types.

Indeed. And too bad you can't specify the type of a literal. 

[pcoder 4]

1 hour ago, David Heffernan said:

Given that the suppliers of hardware have dropped support for extended I would suggest that you are out of date. 

The question was about 32bit Delphi. The modern Intel/AMD FPUs still have the 80bit mode, and if the FPU would not be in hardware,

then in system emulation. Your earlier advice ("nobody should") did not care about the precision drop to 64bit float and developers who need more precision.

That's why I mentioned the possible need for alternatives (large-precision libraries). A developer of mathematical software should know this ...

[David Heffernan 2353]

37 minutes ago, pcoder said:

The question was about 32bit Delphi. The modern Intel/AMD FPUs still have the 80bit mode, and if the FPU would not be in hardware,

then in system emulation. Your earlier advice ("nobody should") did not care about the precision drop to 64bit float and developers who need more precision.

That's why I mentioned the possible need for alternatives (large-precision libraries). A developer of mathematical software should know this ...

80 bit was never for large precision. It was intended for use as intermediate values in calculations for accuracy purposes. But it turned out not to be worthwhile. That's why it has been dropped. 

 

The support in modern hardware for 80 bit is on the 8087 unit only and is horribly slow. It's there for legacy reasons so legacy code still runs. 

 

Perhaps you are doing different type of work from me. But I'm using BLAS type numerical algorithms. You don't find BLAS for 80 bit data. 

 

This is an interesting post https://retrocomputing.stackexchange.com/questions/9751/did-any-compiler-fully-use-intel-x87-80-bit-floating-point

Edited September 12, 2022 by David Heffernan

[Leif Uneus 43]

Just for fun, read this article by W. Kahan and J.D. Darcy about the usefulness of extra precision.

"How Java’s Floating-Point Hurts Everyone Everywhere"

 

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

 

 

[pcoder 4]

Also, not to forget the existing large number of functions with extended precision, most notably amath.pas
They will run as long as Delphi32 apps are supported. Downgrading (to lower precision) would be wrong, in terms of software functionality.

[David Heffernan 2353]

46 minutes ago, pcoder said:

Also, not to forget the existing large number of functions with extended precision, most notably amath.pas

That's an interesting piece of work. And sure, if you need to perform arithmetic to higher than double precision, then double is going to be a problem. My point, poorly stated, is that I believe that the bulk of numerical computing doesn't need more than double. Is that not the case?