Raspbian Jessie (64bit) for RPi3?

[Bosse_B]

Is there going to be a 64 bit version of Raspbian Jessie so that one can build 64 bit programs and run them on this hardware?
If so is there a timeline for it?
Building the 64 bit programs would probably not be a problem using FreePascal cross compiler on current hardware but running them on a 32 bit operating system might be difficult...

[ShiftPlusOne]

Before there's a 64bit distro (raspbian or otherwise), there needs to be a 64 bit kernel. Eben said the CPU core was picked because it's a great 32 bit processor, it just happens to also work in 64bit mode. Whether it's worth the engineering effort to switch to 64 bits remains to be seen. However, if the community wants to get a 64 bit kernel running and do some benchmarks, that would probably be very helpful.

[Milliways]

There seems little point when the RAM is limited to 1GB.

[jamesh]

There seems little point when the RAM is limited to 1GB.

Why do people think this? In my opinion, it's WRONG.

Going to 64bits does double integers. But that's all, and not even all integers (int32_t anyone?). It doesn't double for example a video buffer. So if you have a 2MB video buffer and a pointer to it, the added memory impact is 2 BYTES!!!!!

Of course, there are memory impacts, but no-where near what people seem to think. Databuffers are the big memory hogs, especially graphics, and those buffers DONT CHANGE SIZE when moving from 32 to 64 bits.

[Bosse_B]

There seems little point when the RAM is limited to 1GB.

Good point!
I saw reference to the Pi3 having a 64 bit CPU and people there figuring the platform would be a good testing ground for 64 bit.
So I asked this question in order to see if there would be a case for running 64 bit apps on an RPi3.
But of course having that "low" amount of memory makes things moot. Nothing to address with 64 bits.
Just run in 32 bit mode for now...

[fanoush]

There seems little point when the RAM is limited to 1GB.

There seems little point in saying things like that

There are many advantages even with 1GB RAM. The major one is speed.
There is also disadvantage - possible higher memory requirements for 64bit code.

However for many cases 1GB is more than enough so trading more speed for possible higher memory requirements makes sense (e.g. media center). Also 64bit kernel can run unmodified 32bit userspace so memory requirements and application compatibility may be the same as now and still 64bit kernel code can be faster and can run some 64bit binaries next to 32 bit ones where it makes sense.

[Milliways]

There seems little point when the RAM is limited to 1GB.

There are many advantages even with 1GB RAM. The major one is speed.
There is also disadvantage - possible higher memory requirements for 64bit code.

I concede that I have not made a detailed study of 64 bit ARM code, but on other platforms there is no speed advantage in 64 bit code, and as you have noted size impacts.

Depending on the width of the bus accessing RAM (Unknown?) there can be minor speed gains in accessing data, but any impact would be minimal and irrelevant given the other bottlenecks on the Pi.

A 64 bit kernel can speed up (by minimising swaps) 32 bit code, but only if there is virtual memory to make this worthwhile.
I stand by my original comment, there is little point when the RAM is limited to 1GB.

[RaTTuS]

AIUI the 64bit arm core in the Pi3 has more and bigger registers - they will mean that stuff compiled for it will be faster as more == better [YMMV]

[fanoush]

on other platforms there is no speed advantage in 64 bit code

Oh, never mind. Then I must live in some parallel universe

Anyway, just found article relevant to this topic
http://www.cnx-software.com/2016/03/01/ ... tructions/

[azbest]

For first step it would be enought to let the user enable the 64bit mode. On the other thread JamesH said something about config.txt, but there is nothing about 64bit in the documentation, yet.

[plugwash]

AIUI the main performance advantages of 64-bit mode are the ability to work with 64-bit integers in a single step rather than two (an obvious advantage for any code that works with 64-bit integers) and more and larger registers (if you start trying to work with 64-bit numbers on 32-bit arm the supply of registers starts looking pretty low).

The disadvantage is that any variables of type size_t, long or pointer just doubled in size.That means more memory consumption and potentially more data flowing on the memory bus.

[plugwash]

raspbian is fundamentally a project to rebuild Debian with lowered minimum CPU requirements. A 64-bit system would be Debian arm64 not raspbian.

As to getting a 64-bit system I would think the first step would be to work out how to get some 64-bit bare metal "hello world" code running. Once that is done work on a kernel port could start.

[jahboater]

The quoted article mentioned 15-30%, I have seen somewhere 25-30% improvement (ignoring the extra address space that usually will not be used). Maybe that's just the 31 64-bit registers compared to 15 32-bit registers.

According to ARM a 64-bit kernel can run 32-bit programs, but not vice versa. So it sounds like backwards compatibility is not so much of an issue.

We have a kernel.img and a kernel7.img - perhaps a kernel8.img would be possible.
Perhaps the RPF are waiting to give us a free performance bump in a few months time.

[cpcbegin]

There seems little point when the RAM is limited to 1GB.

Why do people think this? In my opinion, it's WRONG.

Going to 64bits does double integers. But that's all, and not even all integers (int32_t anyone?). It doesn't double for example a video buffer. So if you have a 2MB video buffer and a pointer to it, the added memory impact is 2 BYTES!!!!!

Of course, there are memory impacts, but no-where near what people seem to think. Databuffers are the big memory hogs, especially graphics, and those buffers DONT CHANGE SIZE when moving from 32 to 64 bits.

I've got an old laptop with 2Gb RAM and I finally back to a 32 bit linux, because 64 bits distros run slower than 32 bits ones...
Anyway I think than rpi3 is the most interesting rpi, but with a 32 bits OS (by the moment).

[Cromarty]

There is one perfectly good reason for trying to get a 64-bit kernel/whole distro running...because it's there and it will be fun and educational.

But I have a question, does the boot-loader code need to change? In other words is there any 'bitness' in the other code in /boot?

I have built a cross-compiler toolchain with crosstool-ng and want to have a go at a 64-bit kernel

[mrvn]

It is true that in 64bit mode pointers are bigger so you need more memory and incurr overhead in speed too.

But that's why there is also IP32 ABI, where int and pointers are 32bit and longs are 64bit. Pointers get 0 extended on use which you can usualy do for free. You gain all the extra registers and faster 64bit arithmetic without the overhead of larger pointers. This makes it the ideal mode for userspace for the RPi3 and it's 1 GB.

[jojopi]

But that's why there is also IP32 ABI, where int and pointers are 32bit and longs are 64bit.

Do you mean AArch64 ILP32, which actually uses long long as its 64bit integer type?

Linaro do not appear to think that the performance benefits of ILP32 using AArch64 are very significant. They point instead to the case of porting (broken) 32bit code to 64bit-only systems. https://wiki.linaro.org/Platform/arm64-ilp32

[bust]

Hi
The interesting question is to compare the performance of rpi-2 with rpi-3 when the
two products hosted the similar current system in the 32 mode.
Regards

[Bosse_B]

I think that is already been covered. The RPi3 is a lot faster than RPi2 in identical configurations they say.

What I wanted to know by starting this thread was if there is a timeline for a 64 bit distribution kernel update and possibly a 64 bit firmware update as well.
Apparently there isn't something like that upcoming in the near future at least.
But the RPi3 seems to be otherwise working fine apart from the new built-in WiFi having trouble using high numbered channels...
See the WiFi Issues thread.

I have just received my RPi3 and am imaging the SDcard with the new Jessie from Feb 26.

[Bosse_B]

I have just received my RPi3 and am imaging the SDcard with the new Jessie from Feb 26.

Now up and running including the built-in WiFi! Seems to be working fine.
Just don't know how to benchmark it...

[bust]

Hi
Thank for your answer
(A pragmatic observation instinctive without the placebo effect could
you give a just appreciation of his performance that better than benchmark tests.)
Regards

[ecarter19]

Perhaps the issue of 64bits will be forced on us as software providers cease to support 32bit code - eg Chrome after March16

[knarfboy]

Perhaps a first step would be to use ARMv8 code instead ARMv7 instructions. Some ARMv8 commands are likely to provide more performance.
But one could produce an independent 3 Raspian package for the Raspberry Pi 3.

[fruitoftheloom]

Perhaps the issue of 64bits will be forced on us as software providers cease to support 32bit code - eg Chrome after March16

Google Chrome is for Intel x86-32 & x86-64 CPU so as there is no ARMHF Port it is totally irrelevant to this thread

[fwroller]

64-bit Raspbian optimized for ARMv8 may provide enough of a performance boost to justify the effort of maintaining it but we will not know until it is built and thoroughly benchmarked on a Raspberry Pi 3. Hopefully those with the skills to build that operating system will do so soon.