Why moving to 64bit?

[jdonald]

Good to know about OpenMW.

The Dolphin package is provided on Debian aarch64, so Pi 4 users could try this today without building from source.
1. Grab Sakaki's 64-bit kernel Raspbian image at https://isshoni.org/downloads/ and write it to an SD card.
2. Execute debootstrap and schroot commands (about 15 minutes to build the container?)
3. sudo apt install dolphin-emu

Edit:
4. sudo chmod a+w /dev/shm
5. LIBGL_ALWAYS_SOFTWARE=1 dolphin-emu # V3D doesn't support required OpenGL 3.0 so use llvmpipe

If any games can run today,Wii games run today and that would make for a more interesting screenshot in the next 64-bit OS announcement, but it's slow.

[bomblord]

Good to know about OpenMW.

The Dolphin package is provided on Debian aarch64, so Pi 4 users could try this today without building from source.
1. Grab Sakaki's 64-bit kernel Raspbian image at https://isshoni.org/downloads/ and write it to an SD card.
2. Execute debootstrap and schroot commands (about 15 minutes to build the container?)
3. sudo apt install dolphin-emu

If any games can run today, that would make for a more interesting screenshot in the next 64-bit OS announcement.

I've actually set up Sakaki's setup and installed the dolphin-emu package it throws an error about not being able to create a window after installing.

[jdonald]

Okay this might take some debugging, which I guess I could try now even on a Pi 3B+.

First thing that comes to mind is that I'm not sure if environment variables automatically propagate into the chroot, so if $DISPLAY is blank, try:

Code: Select all

export DISPLAY=:0

before launching Dolphin.

Other times it's something more involved, like in that similar thread I had to run strace to rootcause the issue with Firefox launching.

[pagenotfound]

What I'm getting out of this thread is that some people think it would totally justified that the RPF spend an additional 1.5 million a year so they can keep playing a f...ing RPG and maybe fool around with some database system that belongs on a Google-sized server farm, not on a Pi.

Has anybody provided solid statistics that show how much faster Debian and all its applications run on 64 bit? On ARM? On 4 GB RAM or less? (Let's be nice and not ask about the memory consumption)

Without such statistics I'm going to regard all this talk about instruction sets and multitudes of registers as fantasy. I suspect that the benefit of an increasing number of registers rolls off very quickly. What you want is L1 cache and fast RAM.

It seems some people, when they were still young and impressionable, came across an article by a clueless journalist about the wonderful new world of 64 bit. The article was just a couple of press releases fused into one, but our young folks thought "Yesss, more is better, I need this.."

[bomblord]

What I'm getting out of this thread is that some people think it would totally justified that the RPF spend an additional 1.5 million a year so they can keep playing a f...ing RPG and maybe fool around with some database system that belongs on a Google-sized server farm, not on a Pi.

Has anybody provided solid statistics that show how much faster Debian and all its applications run on 64 bit? On ARM? On 4 GB RAM or less? (Let's be nice and not ask about the memory consumption)

Without such statistics I'm going to regard all this talk about instruction sets and multitudes of registers as fantasy. I suspect that the benefit of an increasing number of registers rolls off very quickly. What you want is L1 cache and fast RAM.

It seems some people, when they were still young and impressionable, came across an article by a clueless journalist about the wonderful new world of 64 bit. The article was just a couple of press releases fused into one, but our young folks thought "Yesss, more is better, I need this.."

I have no stake in this other than that I would like to see an official and fully supported 64 bit setup. I have made no arguments about how much money should be spent or anything else. A topic popped up about 64 bit support and if we want it and I threw my hat in the yes category as a few pieces of software I want to use are 64bit arm only. And yes it's mainly to as you put it..... to play an f...ing RPG. What exactly is wrong with wanting to play an RPG on my raspberry pi?

[geev03]

Is this the best case of memory and disc usage achievable on a 64 bit RPi hardware running a 64 bit OS ?

Code: Select all

login as: gv
gv@192.168.1.234's password:
Welcome to Alpine!

The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See <http://wiki.alpinelinux.org/>.

You can setup the system with the command: setup-alpine

You may change this message by editing /etc/motd.

localhost:/$ su
Password:

localhost:/# apk update
fetch http://uk.alpinelinux.org/alpine/v3.10/main/aarch64/APKINDEX.tar.gz
3.10.1 [/media/mmcblk0p1/apks]
v3.10.1-59-g08cb18d753 [http://uk.alpinelinux.org/alpine/v3.10/main]
OK: 5625 distinct packages available
localhost:/# uname -a
Linux localhost 4.19.58-0-rpi #1-Alpine SMP PREEMPT Thu Jul 11 08:47:35 UTC 2019 aarch64 Linux
localhost:/# free -m
              total        used        free      shared  buff/cache   available
Mem:            918          51         787          36          79         833
Swap:             0           0           0
localhost:/# df -m
Filesystem           1M-blocks      Used Available Use% Mounted on
devtmpfs                    10         0        10   0% /dev
shm                        459         0       459   0% /dev/shm
/dev/mmcblk0p1             970        65       905   7% /media/mmcblk0p1
tmpfs                      459        37       423   8% /
tmpfs                       92         0        92   0% /run
/dev/loop0                  24        24         0 100% /.modloop
localhost:/#

[Heater]

No of course not:

Code: Select all

dataplicity@pi64-aalto:/$ uname -a
Linux pi64-aalto 4.11.12-pi64+ #1 SMP PREEMPT Sun Jul 30 20:18:20 CEST 2017 aarch64 GNU/Linux
dataplicity@pi64-aalto:/$ free -m
              total        used        free      shared  buff/cache   available
Mem:            919         163         100          18         655         722
Swap:             0           0           0
dataplicity@pi64-aalto:/$ df -m
Filesystem     1M-blocks  Used Available Use% Mounted on
/dev/root          30011  5020     23756  18% /
devtmpfs             455     0       455   0% /dev
tmpfs                460     0       460   0% /dev/shm
tmpfs                460    19       441   5% /run
tmpfs                  5     0         5   0% /run/lock
tmpfs                460     0       460   0% /sys/fs/cgroup
/dev/mmcblk0p1        63    25        38  40% /boot
tmpfs                 92     0        92   0% /run/user/1000
dataplicity@pi64-aalto:/$ 

That is my Pi 3 running Pi64 with a 32GB SD card.

[geev03]

Alpine Linux , using less than 100 MB memory & disc , is running on a Pi 3 with a 1GB SD Card..

[Heater]

I have no idea what you are getting at. Alpine Linux is designed for creating small systems. Looks like that is exactly what you have there. What is the problem and/or question?

[Gavinmc42]

PiCore will run on 128MB card

[hippy]

What I'm getting out of this thread is that some people think it would totally justified that the RPF spend an additional 1.5 million a year so they can keep playing a f...ing RPG and maybe fool around with some database system that belongs on a Google-sized server farm, not on a Pi.

My concern is none of that. I don't even want 64-bit. But I am required to have it if I want to use the latest version of software like Visual Studio Code which is 64-bit only under Raspbian.

While I can keep running the old 32-bit versions of such software those will not get the latest updates and additions which I may desire, want or need to use, won't get bug or security fixes.

Alternatively I can use some third-party 64-bit OS other than Raspbian which isn't as well supported. Or I can use some other platform entirely.

But, more importantly, where a company provides tools which require the latest 64-bit version of something which does not run on a Pi, then using a Pi and 32-bit Raspbian would not be something they could recommend to customers. That would become something customers would be advised to steer clear of rather than embrace.

I would rather be telling people to buy a Pi than telling them not to, because it is not suited to what they want to do.

[jdonald]

There's a Raspbian 32-bit build of VScode OSS 1.36.1 here: https://github.com/futurejones/code-oss ... 4/releases
It's not 1.37, although I haven't seen a 1.37 arm64 build either (?)

Just now I was able to run Luigi's Mansion in dolphin-emu on sakaki's 64-bit kernel Raspbian Pi 4 image. In addition to making sure to run within an X session, you also need to sudo chmod a+x /dev/shm anytime you start a new chroot session. Same issue with Firefox arm64 or anything that calls shm_open().

As of now it's too slow to be playable (see kernel thread).

[ejolson]

Has anybody provided solid statistics that show how much faster Debian and all its applications run on 64 bit? On ARM? On 4 GB RAM or less? (Let's be nice and not ask about the memory consumption)

For most people it's not so much about how fast but whether a program even runs on 32-bit.

Since it is difficult for many open-source projects to maintain 32-bit compatibility, more and more have become 64-bit only. Even with only 4GB of RAM there is a convenience in having a large virtual address space that favours 64-bit; moreover, almost all desktop computers are 64-bit and those machines are still the development target for most desktop and server applications.

From a limited resource point of view, since it is becoming more and more difficult to make a 32-bit operating system work well, it would simplify things to go 64-bit. Unfortunately, it appears the device drivers for the Raspberry Pi are not quite ready for that. Moreover, while the driver problem is likely to be solved soon, there is still the requirement that Raspbian be compatible across the entire Raspberry Pi line.

[HawaiianPi]

... there is still the requirement that Raspbian be compatible across the entire Raspberry Pi line.

This is the biggest problem. Do you create and maintain separate images that are model specific, or do you try and roll them into one version?

Raspbian images have become popular for their simplicity (just burn-n-boot), but people get confused already with just 3 images (light, desktop and full), and NOOBS vs images only adds to the confusion. This will only get worse with more images.

I think it's time to at least get rid of NOOBS in favor of PINN so there can be a standardized installation method which works regardless of filesystem or card size (burn image to card with Etcher).

Although we might need to come up with a new name, since the acronym won't make sense when NOOBS is no longer around.

As far as images go, I'd still like to have the option, but I don't know how much more work will be required to maintain both 32 & 64 bit images.

[jerrm]

I finally downloaded Sakaki's 64 bit image and did some testing of a rather mundane, un-sexy daily job. Pure Rasbian took 26% longer than the 64 bit config.

The test restores about 103GB of disk images from an unencrypted zbackup datastore from/to a USB3 attached SSD. This is a real world task executed daily.

115 minutes - Pure Raspbian Buster
103 minutes - 64 bit kernel / 32 bit Raspbian userland
91 minutes - 64 bit kernel / 64 bit Debian chroot

Testing was done on the same 2GB Pi4 with the same USB3 adapter and SSD, headless, no gui running. Only the SD card was swapped out between the 32bit and 64bit kernel runs. The SD cards were the same brand/model/size. The test was run 3 times for each config. Results were consistent, within 40 seconds best to worst for any particular config.

The pure Raspbian config being 26% slower than the 64/64 config was a big surprise. The job does not appear to be CPU constrained under Raspbian, the "busy core" rarely exceeding 65%, with the other three cores mostly idle. Under 64/64 the busy core approached 80% utilization. Temperature was never an issue and the CPU never throttled in any of the tests.

I fully expected 64bit to be faster, but not to this degree.

[Gavinmc42]

I fully expected 64bit to be faster, but not to this degree.

I welcome a new member to Sakaki's fan club
I'm waiting to see what she can do with the 4GB Pi4

But I think you just convinced me not to wait and upgrade to a 2GB Pi4 now.
Oh goodie, they have the case and power supply in stock too

[pica200]

There you have it. 64 bit does have advantages even for a few rather normal tasks (not edge cases like a few people think). You would probably see a even bigger difference if that backup would be encrypted since the AArch64 instruction set can cope better with AES

[hippy]

There you have it. 64 bit does have advantages even for a few rather normal tasks (not edge cases like a few people think).

Is this really a "normal task" though ?

No one has disputed that 64-bit can be faster, and for some things there will be more gains than in others, and the longer those things take the more notable the differences may be.

When what one is doing only takes a short time, performance gains are far less noticeable. A web page which takes 'no time at all' to render would seem just as fast as one which takes even less.

And likewise when one isn't particularly worried about the time taken, say one were creating a 100GB backup rather than restoring one and waiting on that completing, an extra 26% probably wouldn't even be noticed.

This is just like any other benchmarking which shows particular things are better for one thing than another, but that doesn't always or necessarily translate to being noticeably better for all one does.

[Heater]

Meanwhile....

My solution to finding all the anagrams in the 650,000 odd words of the british-english-insane dictionary file supplied, as provided by Raspbian package wbritish-insane, is substantially slower on a Pi 3 running a 64 bit Debian than the 32 bit Raspbian:

Code: Select all

pi@pi64-aalto:~/insane-british-anagram-rust$ time ./target/release/iba-3 > anagrams.txt

real    0m1.283s
user    0m0.854s
sys     0m0.135s

pi@pi3-buster-1:~/insane-british-anagram-rust $ time ./target/release/iba-3 > anagrams.txt

real    0m0.921s
user    0m0.827s
sys     0m0.090s

Thus neatly contradicting all my previous statements about 64 bit Pi and conclusively proving that a 64 bit Pi is a waste of time.

All code here for the curious: https://github.com/ZiCog/insane-british-anagram-rust

[hippy]

My solution to finding all the anagrams ... is substantially slower on a Pi 3 running a 64 bit Debian than the 32 bit Raspbian

I guess that goes to show that 64-bit is better if one has code which suits 64-bit but things may be worse when one doesn't.

But I would also suggest that, for many things, being somewhat slower is no more noticeable than being somewhat faster. The overall gain or loss for an individual would all depend on what they were doing.

[pica200]

I'm not saying the opposite either that 64 bit is always better. It isn't but crypto, compression and similar things which are part of day to day use (under the hood since a lot of software uses them) sees better results. Yes, there is a disadvantage in that memory usage increases a bit because of 64 bit pointers and you can see it hurts performance a bit especially on the Pi 2 and 3 (much lower memory bandwidth) but on the Pi 4 i see no reason not to use 64 bit at least for 2 and 4 GB models. And as has been said countless times software is slowly moving to 64 bit. I would like to use Firefox for example because i trust Mozilla more than Google and Chromium is no option if Google eventually makes ad blockers unusable. Then there are emulators a few of which would surely see a benefit. And Dolphin doesn't work at all since it requires 64 bit (and has good reasons to only support 64 bit as you can read in a blog post linked earlier).

And before anyone says "if you want all of this the Pi is not for you" i have a ~5 years old Notebook with 16 GB RAM, i7 and SSD which is perfectly able to do all of it but at multiple times the power usage and heat because x86(_64) is a bloaty and inefficient crap arch. I'm actually impressed how close the Pi 4 is to this machine and the advertisement as desktop computer is justified but then it should be able to run most of the desktop software (minus commercial software which is not coming no chance). I also understand the RPiF has other priorities and i'm not getting my hopes up for an official 64 bit option any time soon but hopefully they consider it in the future. Even 64 bit kernel and 32 bit userland would be ok (since we can add a 64 bit userland easily).

[Heater]

hippy,

I guess that goes to show that 64-bit is better if one has code which suits 64-bit but things may be worse when one doesn't.

Very true.

The dilemma for me with that anagram project is that I have over time evolved a number of different variations of that solution, using the same basic algorithm but varying in my code style.

Now one of those variants is 25% faster than the other on my 32 bits and 64 bits Pi 3. But on my x86-64 PC they are 25% different the other way around!

It's not clear to me why either one of them would be more friendly to 64 bits, or the other way around. But they are very sensitive to ARM vs Intel architecture.

In the face of all this making blanket statements about 32 vs 64 bit performance is pointless unless you know what architecture you are using as well. There are just too many variables.

[jdonald]

OpenMW: Looks like @TotalJustice got it running on a Pi 4: https://www.youtube.com/watch?v=bSxf9afRRyo
Not sure if using an older source snapshot, ran a 64-bit OS, or just managed to make the latest 32-bit build run, but @bomblord you'll probably want to hit em up for the binaries before going through the onerous build procedure yourself.

I would like to use Firefox

Firefox armhf is supported on Buster though. See installation instructions. What happened with Stretch is that we had two years of darkness due to an armhf-specific regression (AAPCS) in gcc 5. Things are hopefully going to be okay on every FF release for the next two years until Debian Bullseye (fingers crossed).

[pica200]

Firefox armhf is supported on Buster though. See installation instructions. What happened with Stretch is that we had two years of darkness due to an armhf-specific regression (AAPCS) in gcc 5. Things are hopefully going to be okay on every FF release for the next two years until Debian Bullseye (fingers crossed).

That seems rather "workaroundish" to me adding Ubuntu repos to Raspbian. If this was really just a
compiler bug preventing it from working we should see builds in the default repos soon?

[jdonald]

Debian stable has never included the firefox package. This aspect isn't an armhf vs aarch64 thing or even an x86 vs ARM thing. The Debian repositories only provide firefox-esr.

For ESR specifically, the problem of it being useless and crashing on startup (armhf only) was also there on Stretch and fixed in Buster.

By "supported" I guess I meant there's some care not to break it, but yeah Firefox proper builds are not supported on Debian.