Why moving to 64bit?

[webbsmurfen]

I've been thinking about this thing for a while, and I’m failing to see the advantage moving to a 64 bit OS. What’s the point to have a 64 bit OS in a SoC Raspberry PI? Yeah you have a 64 bit processor, forced at it is today to work as a 32bit. But in a comparison between a 64 bit and 32 bit it’s a very small advantage or almost to none difference between them. RPI doesn’t have more than 4Gb ram, so in a way it’s a Waiste of time really to rewrite part of the drivers/code just because people want it?! Or is it?

How do you look at this? Do you guys see some advantages? Am I the only one who thinks the trend towards 64 bit is a bit unnecessary?

[Gavinmc42]

It helps to have virtual memory bigger than actual memory.
Useful for big databases etc
A 64bit address is much bigger than 32bit.
32bits is not enough to have a unique ID for everyone on the planet.

For Pi's not much value for their Mission, but you see the big guys Google, Mozilla saying we will support only 64bit cpu's in the future.
It will be a pain then to support 32bit.

When we talk about Pi4 being used as a Desktop with a 1TB or more USB3 drives then 64bit is much more useful.
There exists ways around 32bit address limits just like there was for the 1MB limit for the IBM PC.
But if you were writing the code would you not like to worry about things like 32bit limits?

[webbsmurfen]

It helps to have virtual memory bigger than actual memory.
Useful for big databases etc
A 64bit address is much bigger than 32bit.
32bits is not enough to have a unique ID for everyone on the planet.

For Pi's not much value for their Mission, but you see the big guys Google, Mozilla saying we will support only 64bit cpu's in the future.
It will be a pain then to support 32bit.

When we talk about Pi4 being used as a Desktop with a 1TB or more USB3 drives then 64bit is much more useful.
There exists ways around 32bit address limits just like there was for the 1MB limit for the IBM PC.
But if you were writing the code would you not like to worry about things like 32bit limits?

Still .. 32bit should support disks up to 2.19TB . at least it does that in 32 bit Windows. Even if its a low budget desktop (RPI) that would be enugh to meet most ppls demand on storing space

[rpdom]

Still .. 32bit should support disks up to 2.19TB

Even on 32 Bit ARM, the ext4 file system will support 16TB. Often it's the USB-SATA adapters that fail over 2-3TB.

Just because the register size is 32 bits, doesn't mean that data storage is limited to 32 bits (the 8-bit BBC micro used 32-bit integers for most things, just needed a few simple routines to handle them). Ok, using more instructions for large numbers may be a bit slower, but most operations don't need numbers that large. Using 64 bits to store a 1 or 0 seems a bit wasteful.

[jamesh]

It helps to have virtual memory bigger than actual memory.

Using LPAE means this isn't problem.

Useful for big databases etc

True

A 64bit address is much bigger than 32bit.

And this is a bad thing as every pointer in your code now takes up more bytes, double pointer memory requirements.

32bits is not enough to have a unique ID for everyone on the planet.

Irrelevant

For Pi's not much value for their Mission, but you see the big guys Google, Mozilla saying we will support only 64bit cpu's in the future.
It will be a pain then to support 32bit.

This is a big reason for moving to 64, sadly. If people wrote decent code in the first place, the code would compile and work for either without problem.

When we talk about Pi4 being used as a Desktop with a 1TB or more USB3 drives then 64bit is much more useful.
There exists ways around 32bit address limits just like there was for the 1MB limit for the IBM PC.
But if you were writing the code would you not like to worry about things like 32bit limits?

Write better code, then you don't need to worry about 32 or 64 because it works on both.

[B.Goode]

I've been thinking about this thing for a while, and I’m failing to see the advantage moving to a 64 bit OS.

The developers, managers and strategists at Raspberry Pi seem to agree with you.

Am I the only one who thinks the trend towards 64 bit is a bit unnecessary?

See above: you are not alone.



(But given that the above information is in the public domain this seems to be a 'strawman' debate... )

[Gavinmc42]

jamesh, I flattered you addressed every point
Ok 64bit - is for big databases and the big bloated pieces of software called browsers.

And things like Blender? Is 2.80 only 64 bit?
Maybe the game engines like Unity if it ever runs on Arm?
I suppose Android will be only 64bit?

Progress - most 32bit cpu's are older and run slower?
Most new ones are 64bit multicore.
Waste that pointer code space or waste those extra 32bit transistors?

Just easier to support newer 64bit as they can run that bloaty code faster?
Perhaps supporting 32 and 64bits means twice as much testing is needed, testing = $$$$
Compile for two versions = time = $$$$

Come to think of it, RPF has 4 OS's? x86 Desktop, Raspbian Lite, normal and full kitchen sink.
That takes up storage on the servers etc = $$

No real advantage unless you are thinking 5-10years time and want to learn 64bit coding now not then.

[Heater]

What about the minor detail that code can be twice as fast in 64 bit mode on the same Pi ?

[RaTTuS]

...
And things like Blender? Is 2.80 only 64 bit?
Maybe the game engines like Unity if it ever runs on Arm?
I suppose Android will be only 64bit?...

see https://community.arm.com/developer/too ... -available

[jamesh]

What about the minor detail that code can be twice as fast in 64 bit mode on the same Pi ?

And can you prove that in general usage, or is that in a contrived and useless benchmark?

[LTolledo]

Will GPIO inputs be read faster with 64bit?

will GPIO outputs switch faster on 64bit?

[webbsmurfen]

The current bug that you need to restrict one megabyte of the four existing megabytes on the RPI 4B if you want to use 64 bit OS is concerning as well. Surly the RPI will run just as fine on 3Gb, but that’s not the point.

Is this something that’s doable to fix without major overhauling of the Kernel/DMA. (not that I will need the last gigabyte or so, just curious )

[Heater]

jamesh,

And can you prove that in general usage, or is that in a contrived and useless benchmark?

No, of course not. What is "general usage" anyway?

Just pointing out that sometimes 64 bits has an advantage that may be significant to ones application.

As an example try my Fast Fourier Transform: https://github.com/ZiCog/fftbench/blob/ ... fftbench.c

Presented in that repo as a benchmark of sorts but originally "contrived" for use on 32 bit MCU's that lack hardware floating point multiply.

As with any such comparisons, take anything I or anyone else says as merely advisory. It's best to do the measurements for your own application yourself.

[rpdom]

Will GPIO inputs be read faster with 64bit?

will GPIO outputs switch faster on 64bit?

No, because unless things have changed a lot, the GPIOs are 32 bit based and are in banks of 32 bits.

[fruitoftheloom]

I've been thinking about this thing for a while, and I’m failing to see the advantage moving to a 64 bit OS. What’s the point to have a 64 bit OS in a SoC Raspberry PI? Yeah you have a 64 bit processor, forced at it is today to work as a 32bit. But in a comparison between a 64 bit and 32 bit it’s a very small advantage or almost to none difference between them. RPI doesn’t have more than 4Gb ram, so in a way it’s a Waiste of time really to rewrite part of the drivers/code just because people want it?! Or is it?

How do you look at this? Do you guys see some advantages? Am I the only one who thinks the trend towards 64 bit is a bit unnecessary?

You really need to search previous posts as this subject has been extensively regurgitated in various diatribes.....

[Gavinmc42]

Unity will run on Pi4
Hmm, dual HDMI VR one step closer?
Unity only make APK files for Android on Arm?

I have some other reasons why I want to run in 64 bit mode.
On the ARM site is a statement that says AArch64 is a bit more power efficient than AArch32.
That is a consideration for the thermals on the Pi4.

Running AI stuff may mean hand tuning code in assembler, AArch64 assembler is a bit nicer than 32bit.
Will it make any difference to my code?
Probably not for a few years yet, got lots to learn still.

[webbsmurfen]

I've been thinking about this thing for a while, and I’m failing to see the advantage moving to a 64 bit OS. What’s the point to have a 64 bit OS in a SoC Raspberry PI? Yeah you have a 64 bit processor, forced at it is today to work as a 32bit. But in a comparison between a 64 bit and 32 bit it’s a very small advantage or almost to none difference between them. RPI doesn’t have more than 4Gb ram, so in a way it’s a Waiste of time really to rewrite part of the drivers/code just because people want it?! Or is it?

How do you look at this? Do you guys see some advantages? Am I the only one who thinks the trend towards 64 bit is a bit unnecessary?

You really need to search previous posts as this subject has been extensively regurgitated in various diatribes.....

Yeah.. I did realize my mistake a couple of posts up.. Sorry abt that

[jahboater]

You really need to search previous posts as this subject has been extensively regurgitated in various diatribes.....

Yes, but things have moved on. The hardware has progressed and the software has not. The gap is widening.

With the Pi3 we had the user space code compiled for ARMv6 and VFP, even though it was an ARMv8 CPU with NEON.
Now we have a fancy new modern out-of-order CPU the Cortex-A72, yet we are still using the old in-order ARMv6 code with the old VFP floating point.

I wonder how many Pi4 programmers know that their code is being compiled for ARMv6 and VFP, which is the default target for the compiler. They need to add

-mcpu=cortex-a72 -mtune=cortex-a72 -mfpu=neon-fp-armv8

to get the full use of their new Pi4. (-mcpu=native should work too).

[hippy]

Am I the only one who thinks the trend towards 64 bit is a bit unnecessary?

No. There are gains which come from having 64-bit registers, 64-bit internal buses, 64-bit processing, and a 64-bit external bus. For some those offer significant improvement in performance but for most people the gains are generally far less, even minimal.

But, with people jumping on the 64-bit bandwagon, choosing to go 64-bit only for software development, one will have to go 64-bit to use such software even if going 64-bit would otherwise be unnecessary.

[jahboater]

Am I the only one who thinks the trend towards 64 bit is a bit unnecessary?

No. There are gains which come from having 64-bit registers, 64-bit internal buses, 64-bit processing, and a 64-bit external bus.

also 31 general purpose registers and 32 floating point registers. That means much less requirement for spilling variables into memory. Much less need to adjust the stack for each function call and so on.

[ShiftPlusOne]

With the Pi3 we had the user space code compiled for ARMv6 and VFP, even though it was an ARMv8 CPU with NEON.
Now we have a fancy new modern out-of-order CPU the Cortex-A72, yet we are still using the old in-order ARMv6 code with the old VFP floating point.

If it makes no difference for the particular application, why does it matter? For libraries where it does matter (usually hand-written NEON routines), we tend to use ld.so's platform-dependant paths to provide a more optimised version.

[dickon]

also 31 general purpose registers and 32 floating point registers. That means much less requirement for spilling variables into memory. Much less need to adjust the stack for each function call and so on.

But each stacked register takes twice the space...

[jahboater]

If it makes no difference for the particular application, why does it matter?

It does work, and my experiments showed quite small performance decrease not being scheduled for the new CPU. It just seems incongruous to me! How wide will the gap get - a Pi6 with an A77 CPU running ARMv6 code?

I don't want Raspbian to end up being frozen in time like RISC-OS (which is hand written ARM 32 assembler, mostly very old).

For libraries where it does matter (usually hand-written NEON routines), we tend to use ld.so's platform-dependant paths to provide a more optimised version.

Impressive. But extra work.

[jahboater]

But each stacked register takes twice the space...

How many functions do you have in your code with more than 30 or so local scalar variables?
60+ if you include floating point.

[dickon]

Vanishingly few, for good and obvious reasons. But that's rather beside the point.

The actual question is how many functions do I have which require local scalar variables to be preserved between function calls, and that's a: a *very* different question, and b: a much, much greater set.