How many of you still actively develop 32 bit versions of your programs?

[BBasile]

probably 90% of programs run slightly better in 32 bits than in 64 bits version.

Curiously it should be the opposite. More memory is a thing but also the 64 bit ABI is better

• more sratch registers (theorically less usage of temporaries)
• loading memory to xmm register is easier

But of course the compiler must take advantage of that.

[Thaddy]

32 bit machines seem to me more equilibrated.
64 bits are a waste of memory in many (not all) cases; probably 90% of programs run slightly better in 32 bits than in 64 bits version. And furthermore, a 32 bit program runs everywhere. So I stick to 32 bits as much as I can.

But soon all the machines and all the software will be 64 bits. Ok, the transition will be very smooth.

That's not the case (that 32bit runs better). That depends hugely on application and you should test.
Furthermore I see more and more clients that do not accept 32 bit code on Windows platforms because the security model is hugely different. Or they don't want to maintain a 32bit sub-system.
I myself work mostly on server systems. In that case - and this is not supposed (as your 32bit) but a fact - 99% is 64bit code. Some client code is delivered in 32bit, though
Note that from Windows 10, the speed penalty is often the other way around, so 64 bit is better because by now it is better optimized. Most benchmarks still refer to older windows versions.

Under Linux I solely use 64bit if available so I can't comment on that. I use 32 bit on Raspbian, though, but that is hobby.

There are also the inevitables: shell extensions and drivers and services

[marcov]

probably 90% of programs run slightly better in 32 bits than in 64 bits version.

Curiously it should be the opposite. More memory is a thing but also the 64 bit ABI is better

• more sratch registers (theorically less usage of temporaries)
• loading memory to xmm register is easier

But of course the compiler must take advantage of that.

True, but the average size of data increases due larger pointer and the alignment issues resulting from that. Also, on windows there is no red zone which makes leaf procedures have more overhead.

From work I know that floating point gets slower in x64 on Delphi (which uses sse fpu), up to 40% and more in some routines.  Those routines use goniometric and other special functions though. IIRC I checked with FPC, and there was the same pattern

[Thaddy]

True, but the average size of data increases due larger pointer and the alignment issues resulting from that. Also, on windows there is no red zone which makes leaf procedures have more overhead.

From work I know that floating point gets slower in x64 on Delphi (which uses sse fpu), up to 40% and more in some routines.  Those routines use goniometric and other special functions though. IIRC I checked with FPC, and there was the same pattern

I noticed that too with intensive floating point math. I still use 32 bit code for some applications, also because of precision issues..
What I doubt is that on current processors alignment is still an issue. AVX+ is advertised as alignment agnostic. As far as I can see that seems indeed the case.

What I can measure, however, is that on modern Intels 64 bit code has much higher memory throughput than 32 bit code when correctly optimized. For non- float computation intensive code that is much more important.

[marcov]

What I can measure, however, is that on modern Intels 64 bit code has much higher memory throughput than 32 bit code when correctly optimized. For non- float computation intensive code that is much more important.

Could you explain that? The memory bandwidth is between cache and memory, so I don't know what 32 vs 64-bit apps have to do with it.   I would expect avx code to have the same speed.

Moreover, only the size of the load and stores matter, and general purpose code won't suddenly start using 64-bit loads except for pointer loads (which are only 64-bit because of 64-bit anyway, so no netto gain).

The only exception that I know is int64 using encryption code like AES  where the algorithm is specified in 64-bit.

[rick2691]

I use Windows XP Pro (32 bit). I program for my personal business use. I quit marketing my software many years ago. All of my personal software is designed for XP. I build ActiveX systems that do special things with that software.

For myself, later Windows versions are only offering an expense to me. I don't want to spend the money. I only want to work and earn money.

I haven't investigated it, but I expect that there is a large populace outside of the US that are operating as I am. They can't afford the Windows, and I am told that Windows XP is being pirated for sale in 3rd World areas. Moreover, among common people that are here in the US, I don't know anyone that is happy with the new Windows versions.

It will be a long time, if ever, before I will abandon XP and 32 bit. It's a work horse.

[Thaddy]

Could you explain that? The memory bandwidth is between cache and memory, so I don't know what 32 vs 64-bit apps have to do with it.   I would expect avx code to have the same speed.
The only exception that I know is int64 using encryption code like AES  where the algorithm is specified in 64-bit.

I don't exactly know yet. But I get 20% to up to 30% speed increase on large moves and copy operations. You should see that too, because it is really significant.

[marcov]

Could you explain that? The memory bandwidth is between cache and memory, so I don't know what 32 vs 64-bit apps have to do with it.   I would expect avx code to have the same speed.
The only exception that I know is int64 using encryption code like AES  where the algorithm is specified in 64-bit.

I don't exactly know yet. But I get 20% to up to 30% speed increase on large moves and copy operations. You should see that too, because it is really significant.

That is probably that the runtime routines can use SSE2 by default on x86_64 (as minimal subset)

[abouchez]

Even if more registers are available under x64, in practice x86 may be faster due to the size of pointers.

Under 64-bit, a pointer uses twice as memory as with 32-bit.
All pointers within an object, for instance, will need doubled size in memory.
So it is pretty usual to have the CPU L1 cache been exhausted faster under 64-bit.
And, as a result, 32-bit may be faster.

This is why the x32 architecture was implemented - only under Linux.
See https://en.wikipedia.org/wiki/X32_ABI
Sadly, x32 is not supported by FPC now, AFAIR.

[Akira1364]

Haven't owned a 32-bit machine since late 2007 here, and I'm not sure why anyone would choose to do so (for home use, that is.) Having to maintain a 32-bit application that you've written for legacy hardware is an entirely different issue that I totally understand.

I mean, I can't speak for Mac or Nix/Nux users and I don't know exactly what it is like where you all live but here in Ontario, Canada it hasn't actually been possible to buy a 32-bit (again, Windows) machine since 2009 or so. I personally have always assembled my own PCs from separately purchased parts, but even all mass-produced pre-builts have been 64-bit by default since around that time. They never even bothered to advertise 32-bit versus 64-bit, as the assumption (for anyone who actually thought about it) would always have been that it was 64-bit.

[JuhaManninen]

Haven't owned a 32-bit machine since late 2007 here, and I'm not sure why anyone would choose to do so (for home use, that is.)

Yesterday I ordered a new 32-bit computer for myself:
 https://mqmaker.com/doc/introduction-to-miqi/
Ok, it is not a Windows PC but I will use it as a PC with some Linux desktop system, just like I use my current 64-bit main computer ASRock Beebox.
 http://www.asrock.com/microsite/beebox/
The Beebox still feels like a dream machine. It is fast enough for anything I do. The passive cooling is always sufficient also with an added Crucial SSD (despite the opposite claims by some people). Just amazing!

The MiQi card computer has Rockchip RK3288 and its performance looks impressive, too. I expect it to be nearly as fast as the Intel N3000.
In both the efficiency (computing power / electric power consumption) is super.
I know 64-bit is the future also in ARM world but it will take a little more time.

I may be obsessed of not wanting cooling fans in my computers any more. Cell phones don't have them, tablets don't have them, yet they are very capable computers. Why should a PC have a buzzing propeller?
I also often think how the current buzzing computers will look like in future, say 30 years from now. They will look very primitive!

[Edit]
MiQi board is so good is it recommended for build farms:
 http://wiki.ant-computing.com/Choosing_a_processor_for_a_build_farm#Introducing_a_new_player_-_MiQi_board_-_2016.2F07.2F26
With proper kernel settings it is faster than Odroid-C2 although C2 is a 64-bit system.
One of MiQi's secrets is a dual port 64-bit memory bus. Often the memory bus speed chokes down a multi-core CPU. Not with MiQi!
In a build farm both price and electric power consumption matter. MiQi apparently shines there.
The Rockchip RK3288 has 4 Cortex A17 cores. A17 is the most optimized ARM 32-bit design. It has the same performance as Cortex A15 but with better power efficiency.

[marcov]

Sadly, x32 is not supported by FPC now, AFAIR.

Afaik it simply didn't catch on.