Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
4  
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 Kaminski Mar 11 at 18:27
3  
64-bit first pays off with more memory than the Pi has. – Thorbjørn Ravn Andersen Mar 11 at 20:50
    
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 at 21:07
    
@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 – Lưu Vĩnh Phúc Mar 12 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... – Lưu Vĩnh Phúc Jul 12 at 5:44
up vote 36 down vote accepted

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.

share|improve this answer
5  
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 at 16:36
1  
I don't know why I would bother mentioning virtual addressing in this post. I feel it may be a little advanced. Anyway, virtual addressing doesn't change the fact that the applications will fundamentally take more space to run. I also feel that the C and friends assumption is fairly safe given the topic. – Jacobm001 Mar 11 at 16:39
2  
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 at 16:43
8  
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 at 17:31
4  

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.)

share|improve this answer
2  
Even though AArch32 already has more registers than x86, AArch64 does it better because now there's separate SP and PC. Before you have at most 14 general purpose registers. You also have a better designed instruction set Is there performance advantage to ARM64, 64-bit ARM (Aarch64) Instructions Boost Performance by 15 to 30% Compared to 32-bit ARM (Aarch32) Instructions – Lưu Vĩnh Phúc Mar 12 at 3:54
1  
    
It'll be interesting to see benchmarks on the Pi3 (particularly with real-world tasks). – mattdm Mar 12 at 16:10

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.


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.

share|improve this answer
    
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 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 at 19:10
1  
..."armel" is the non-hf Debian that was used before Raspbian. – goldilocks Mar 11 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 at 23:19

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.

share|improve this answer
    
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 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 at 15:21
    
None in particular, just wanting to max out the performance the RPi3 is capable of. – zundi Mar 11 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 at 18:40

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.

share|improve this answer
    
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 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 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 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 at 15:34

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.

share|improve this answer
    
Perhaps we need an x32 ABI for ARM. Then we can have small pointers and all the registers. – rsaxvc Jul 12 at 5:16

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) 
    } 
}
share|improve this answer
4  
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 at 23:54
    
I don't think i=- is valid. – rsaxvc Jul 12 at 5:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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