53

In this page, the official RPi3 announcement states:

You’ll need a recent NOOBS or Raspbian image from our downloads page. At launch, we are using the same 32-bit Raspbian userland that we use on other Raspberry Pi devices; over the next few months we will investigate whether there is value in moving to 64-bit mode.

My question is, given that the processor is 64 bits, isn't it obvious that running the OS in 64 bits will be better in every way? What am I missing?

  • 9
    I once worked for a company that ported software from 32bit to 64bit OSF on DEC/Alpha (long time ago). Just a straight recompile, since the codebase was already 64bit compliant. 10% performance hit from the extra memory consumption in integers and pointers. This was back in the days when performance was measured in triple digit mhz and double (maybe low triple) digit memories. Without having 4+GB of ram onboard, not necessarily a good idea. – Chris K Mar 11 '16 at 18:27
  • 6
    64-bit first pays off with more memory than the Pi has. – Thorbjørn Ravn Andersen Mar 11 '16 at 20:50
  • 2
    On x86 based systems the difficulty to decide this has even let to a hybrid abi: en.wikipedia.org/wiki/X32_ABI which uses 32bit pointers and 64bit cpu registers. – PlasmaHH Mar 11 '16 at 21:07
  • 1
    @ChrisKaminski but ARM and x86 are different. When they go from 32 to 64 bits they double the number of registers and redesign some aspects of the instruction set that make the code run faster in most cases. You can see a lot of benchmarks on the internet – phuclv Mar 12 '16 at 3:42
  • @rsaxvc so what does that add to my comment? I said "ARM and x86" to say that in those architectures going 64 bits improves performance of the application unlike other architectures like DEC/Alpha or Sparc, MIPS... – phuclv Jul 12 '16 at 5:44
63

given that the processor is 64 bits, isn't it obvious that running the OS in 64 bits will be better in every way?

No actually, it's not. In some ways, running a 64 bit operating system could deteriorate the Raspberry Pi's performance.

Benefits of 64 bit:

The two primary benefits of using a 64 bit processor/operating system is that the device can handle more than 4 GB of RAM, and natively handle integers larger than 2^32 without the need for a bignum library.

The Raspberry Pi doesn't have more than 4 GB of RAM. At a 1 GB of RAM, you've completely lost the first of the two primary benefits. As for the second benefit, what percentage of people are actually using enough giant numbers that it makes sense for the foundation to support a whole second operating system? As is, the RPi can use huge numbers through software methods, but it seems like if you're going to be consistently in that realm, you need to be using better hardware anyway.

Problems with 64 bit:

The ability to store a larger number isn't granted by magic. Rather, the size of memory objects needs to be increased. In C (and C++) this means changing an int to int64_t. This isn't done automatically, hence the comments about the foundation not wanting to maintain two branches.

Additionally, many applications simply don't provide a benefit (for most users) when run in 64 bit mode. Notice that most web browsers, MS Office, and a whole host of other popular software is all still shipped and maintained in a 32 bit manner. Sure you can get your hands on an 64 bit release of MS Office, but it's rarely used.

If the application/operating system is written to take advantage of a 64 bit architecture, your application is going to use more memory, simply because variables and pointers are taking up more space. Usually this is a relatively small trade off for machines that will benefit from the perks. In our case, we have very few perks, and very little RAM.

Also of note:

Just because you're running on a 64 bit machine, doesn't mean the application isn't running as 32 bit. Windows makes this very clear by having two different install paths, C:\Program Files and C:\Program Files (x86).

So, will the foundation likely provide 64 bit support?:

We're back at the same point of, "Some people may see benefit, but most will not.". You'll certainly see other projects offering 64 bit builds, but unless the foundation gets a lot of undeserved (imo) flack, they probably won't and shouldn't (imo). Creating and maintaining a separate 64 bit branch isn't a small endeavor, and honestly, just doesn't seem worth it.

  • 7
    Assuming you talk about C and friends, the size of any type <= int remains the same. size_t and pointers increase in size, as may long under Linux's address model. You also completely miss out of the points of virtual address space, which matters when you do memory mapped I/O. – user42969 Mar 11 '16 at 16:36
  • 3
    It's not advanced to make a distinction between physical memory amounts and virtual memory. It is also not advanced to not propagate misinformation. sizeof(char) is always one. Under Linux, sizeof(short), sizeof(int), sizeof(float), sizeof(double) do not vary with bitness. That has a major difference in your claims. – user42969 Mar 11 '16 at 16:43
  • 11
    I have problems with the use of x64 in this answer. x64 is an abbreviation of x86-64. This is NOT synonymous with "64 bit". 64 bit ARM CPUs are AArch64. – Oli Mar 11 '16 at 17:31
  • 6
    There are more 64-bit pros than you listed. Is there performance advantage to ARM64, en.wikipedia.org/wiki/64-bit_computing#Pros_and_cons – phuclv Mar 12 '16 at 3:59
  • 3
    You missed the biggest reason to move to a 64 bit OS. January 19, 2038. 32 bit Linux can't handle dates past this time. The fix has been 64 bit Linux (and upgrading any software based on the 32 bit unix time) for quite some time. 2038 is 20 years away now, but Raspberry Pi, being a small embedded machine has some potential to be used this far in the future. Nobody really took the Y2K problem seriously in 1980 either. – Steve Sether Dec 9 '17 at 4:24
20

It's worth noting that the situation is different for ARM and Intel/AMD. That's because the switch to x86_64 was also used as an opportunity to update the badly-aging architecture, basically crippled by only having 8 general-purpose registers — and doubled in 64-bit mode. So, switching an Intel/AMD system to 64-bit mode also means enabling real features which make a significant difference in performance.

ARM doesn't have this problem to begin with (although AArch64 adds registers, the 32-bit architectures weren't starved for them), so the benefits are basically more directly-addressable memory and native big integer support — way less of a big deal, and perhaps counteracted by the downside (more memory used for everything).

(As an aside, for this reason, there has been some work in creating an "x32" abi for Intel/AMD Linux, keeping the CPU enhancements but using 32-bit pointers.)

6

I am sure there are already people running Debian Aarch64 (ARMv8) on the Pi 3; it certainly would not be that hard for many people (see here for some clues about that might work)1 although for most users it is probably a bit of a stretch.

However, if Raspbian and/or the Foundation don't come out with a 64-bit version, you will increasingly see people with blogs, etc., explaining how to run one and still get the goodies you need.


There is now a Fedora aarch64 release for the Pi 3.


1. There will be some complications with the 32-bit /opt/vc stuff, I am not sure how surmountable that is; there used to be 32-bit compat libs for x86-64 but Aarch64...maybe not.

  • 1
    raspbian.org/RaspbianFAQ#What_is_Raspbian.3F states (talking about Raspbian): The port is necessary because the official Debian wheezy armhf release is compatible only with versions of the ARM architecture later than the one used on the Raspberry Pi (ARMv7-A CPUs and higher, vs the Raspberry Pi's ARMv6 CPU). Is this still true with the RPi3? – zundi Mar 11 '16 at 18:48
  • @sandy I think that is 1) Relatively ancient; 2) Confused and/or uncorrected since then, since Debian armhf is compiled with hard float, that's what the hf is for, vs. there's another debian for ARMv4/5 that I think was the first one used on the and that ISA did not have hard floats (I think neither did 6 until a certain point, but it has been that way for most of the time, aka ARM1176JZ(F)-S). So there's only one version of Raspbian, period, ARMv6 with hardware floating point support, the only difference between the A/B/+/0 models and the 2 is the kernel used, presumably so also with the 3. – goldilocks Mar 11 '16 at 19:10
  • 2
    ..."armel" is the non-hf Debian that was used before Raspbian. – goldilocks Mar 11 '16 at 19:12
  • @sandy that sentance was written in the days of the pi1, so when it says pi it means what we would now call pi1. There are third parties releasing debian armhf images for the pi2 (and presumablly pi3) but the rpf have decided to stick with one image for all boards for now. – Peter Green Mar 12 '16 at 23:19
5

As part of the launch publicity I saw it mentioned that one concern is the effort required to maintain two separate code bases (32 and 64 bit). the Adafruit PI3 Launch video also mentioned that the move to a 64bit processor was more about the clock speed increase the new chip provided than about using 64bit mode.

  • I thought the code would be the same, but the compiler would be in charge to optimize the final code to take advantage of the architecture. Is it relatively easy to make a new build? Say, to run Debian in 64 bits? – zundi Mar 11 '16 at 15:19
  • @sandy Easy would depend on your skill level and experience. What is the use case that needs this now? – Steve Robillard Mar 11 '16 at 15:21
  • None in particular, just wanting to max out the performance the RPi3 is capable of. – zundi Mar 11 '16 at 18:35
  • @sandy The foundation has said that the replacement for the Pi3 will not come as quickly as the Pi3 followed the Pi2 (approx. 1 year). They may use the switch to 64bit for a performance bump without requiring new hardware - Note this is all speculation on my part. – Steve Robillard Mar 11 '16 at 18:40
4

Addressing the assertion that the 64 bit native programs are larger (more memory for data and pointers), and that there are no noticeable benefits to a 64 vs. 32 bit OS on ARMv8 with less than 4GB of RAM, I wish to raise a few points.

There are some significant differences in how things are done in ARMv7 (and before) and ARMv8, architecturally, that make the ARMv8 execution more efficient. Some of this is from the wider internal data paths, some is the elimination of special cases, and a much deeper pipeline). These same changes make the ARMv8 better at running ARMv7 (32 bit) code.

Native 64 bit applications do use 64 bit pointers and 'size_t' is 64 bits, so elements using those do get larger. The remainder of data will tend to stay the same size. The significance of this is minor, however, to the size of the executable images.

Where 64 bit native really shines (if you don't care about large integer and floating point stuff) is having a bigger virtual address space:

  • The OS is able to divide the virtual address space into more and larger sections, allowing easier management of shared resources, more streamlined context switches between different levels of privilege, and so on.
  • If you've enabled swapping, you can run more and larger processes, exceeding physical memory limits (this is actually true in 32 bit as well, but you're less limited in 64 bit)

Whether the OS currently takes advantage of this or not, it's going to make a difference as the mainstream moves away from 32 bit.

I think the best argument for moving to a native 64 bit AArch64 kernel is portability: The mainstream desktop has moved to mostly 64 bit processors, and I'm seeing more packages that assume 64 bits, and porting such code back to 32 bits is harder than porting from 32 to 64 bits. In user-space, you're able to run 32 bit applications and 64 bit applications side-by-side, assuming you have installed the multi-arch libraries, so it is not required to port 32 to 64 bit where it doesn't matter. A 64 bit OS is simply going to give you the larger selection of software.

I'm not saying that producing a 64 bit kernel for the Raspberry PI 3 is easy - there are significant differences that require changes at the low level, not all device drivers are 64 bit clean (especially drivers for ARM specific GPUs). It may be that Raspberian will remain a 32 bit OS, but I believe that (in the long range) it is short-sighted.

A single boot media (SD card, for example) can contain both 64 and 32 bit versions of the OS, and the secondary boot software (u-boot, arm-boot, and others) can determine which one to load. The tougher part is userland -- the file system would have to be multi-arch, even on 32 bit systems where the 64 bit stuff will be useless. I would address this with a script or utility that could be run after the initial boot to remove the unneeded libraries and program executables on 32 bit only systems.

  • Perhaps we need an x32 ABI for ARM. Then we can have small pointers and all the registers. – rsaxvc Jul 12 '16 at 5:16
4

The 64-bit addressing can be useful even if you don't have more than 1GB of memory.

It allows you to memory-map large files, so you have a pointer and let the OS do the I/O transparently. Just another way of doing I/O. You need a 64-bit addressing to do this on large files.

Another example where I see it can be useful is to allow processes to have more than 2GB of address space, using swap space. I recently had an issue on a 32-bit NAS with lots of storage, and a damaged filesystem. The fsck process ran out of memory, even with the caching options turned on. Adding swap space could not solve the problem, the 32-bit address space was the hard limit there. So there was just no way to run fsck on this large damaged filesystem with a 32-bit binary. With a 64-bit binary and some swap space, it would have run.

2

The existing answers cover the problems of a 64-bit arch very well, but I am not seeing many stated advantages of upgrading. So, here's two I have recently discovered:

  • When PHP handles Unix timestamps, the integer size in a 32-bit arch sets an upper limit on dates, such that they cannot go beyond a particular day in 2038. I expect this is an issue for all languages that handle timestamps. (Thankfully, most date handling subsystems that do not use Unix timestamps, such as PHP's DateTime, are designed specifically not to be limited by this problem even on older CPUs).
  • Mongo is limited to databases under 2G in size on this arch, and 32-bit builds are soon to be deprecated. From the manual:

    Starting in MongoDB 3.2, 32-bit binaries are deprecated and will be unavailable in future releases.

    Although the 32-bit builds exist for Linux and Windows, they are unsuitable for production deployments. 32-bit builds also do not support the WiredTiger storage engine.

  • Weirdly, this depends on your platform. It's not usually the integer size, but the size of time_t in the 'C' library. Even on 32-bit platforms, it's possible to use a 64-bit time_t with some CPU time overhead, but many 32-bit platforms do not yet do so, as there's a binary compatibility problem in doing so. – rsaxvc Jul 12 '16 at 5:13
  • @rsaxvc, interesting, thanks. So could I obtain 64-bit time-handling by recompiling PHP, or would it require modification of underlying C libraries as well? The former would be within my ability, but not sure about the latter - I was pondering recompiling the whole of Ras[bian myself too, but there don't seem to be any simple instructions to do so (yet, anyway). – halfer Jul 12 '16 at 7:00
  • for Linux, you'd need to patch the kernel, libc, and your application. It's probably not worth it. After some reading, OpenBSD(no on RPi) time_t is 64-bit since 5.5. On 32-bit Windows using Visual Studio 2005 or newer time_t is 64-bit. – rsaxvc Jul 12 '16 at 12:17
  • @rsaxvc: alright, thank you. I wonder if it makes sense for me to wait for a 64-bit OS is available - it sounded imminent on a few news articles from a few months ago.... :-) – halfer Jul 12 '16 at 15:34
-4

My thoughts on this: Although I don't know exactly how an ARM processor addresses memory, I can tell you this from previous multiple CPU architectures I programmed on (SPARC/Alpha/i386/AMD64/X86_64): when using shared memory and addressing by its "real" virtual address pointer, the move to 64bit is not trivial. Although memcpy does what it's supposed to do, you need to take into consideration that in 64 bits the data is stored like this (bit backwards):

HGFEDCBA
HGFEDCBA
HGFEDCBA

yet in 32 bits it looks like this:

ABCD
ABCD
ABCD

So, in 32bits when you store say a jpeg in RAM, you can read its header bytes, or do edge detection, without any problem in a linear fashion *say by going byte by byte forwards. But in a 64bit architecture this changes:

32bit:

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64bit:

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}
  • 5
    Endianness has nothing to do with the word size. Heck, many architectures allow the programmer to select the endianness, including ARM! Also, "64-bit" can have entirely different consequences depending on the architecture in question, and it's difficult to compare across architectures or try to draw similarities between them. – Bob Mar 31 '16 at 23:54
  • 1
    I don't think i=- is valid. – rsaxvc Jul 12 '16 at 5:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.