I recently bought one with 8 GB RAM pictured above. I haven’t got an SSD for it yet so am still pottering about with an SD Card.

I’ve installed VS Code, clang. and Rust along with the VS Code extensions Rust-Analyzer and codelldb.

Out of curiosity I compiled and ran a Rust program that reads in a text file of 1,000 lines of text with each line holding 7 random cards like this: AH 6D 2C 4S JD QH QC.

The idea is to load the file into RAM then process each line and determine the best poker hand.

On my PC 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz (which runs Windows 11), I compared running the Rust program in Windows 11, on Ubuntu 24.04 LTS running in a Hyper-V VM on the same PC and on the Raspberry Pi 5 using it’s own Debian (Bookworm) version.

Here are the times per hand.

• Windows: 175 ns.
• Ubuntu on Hyper-V 125 ns
• Raspberry Pi 5: 175 ns.

You can download the project with the test cards from GitHub. This link is a zip file containing the project file.

To run it in release in VS Code, in the terminal type in

cargo run --release 1000_card_hands.txt

Or you can view the test cards which include the results with commemts in the test file. No need to run it release.

cargo run --features=show_cards test_card_hands.txt

What is so suprising is that the time on Windows and Rapberry Pi 5 are the same. Windows is running a virus checker (Windows Defender) and I guess that might slow it a bit.

There were 1,000 lines of these and the program loaded the file into memory, holding the cards in a Vec<Vec<Card>>. Then it loops through the 1,000 elements and figures out the best hand for each set.  The bit that was timed was the loop not the loading the file into memory.

The source file is on GitHub. It has the project files plus some test cards. You can try it yourself. Note at the bottom of this article is a link to a much faster version.

https://github.com/David-H-Bolton/Projects/blob/main/rust_pokerhand.zip

On my PC, the Windows one average time per hand is 768 ns. On Ubuntu is 540ns. Mad eh! The same program runs in 70% of the time on Linux compared to Windows. Both are run with this command from a terminal/command line.

cargo run --release 1000_card_hads.txt

You can also try the test_card_hands.txt but you need to enable the show_cards feature. That shows the cards but doesn’t do timing. The default is do the timing but don’t show the cards or the evaluation.

cargo run --release --features show_card test_card_hands.txt

The test cards say what each hand is and the output at the bottom is the program working out each hand.
The file

https://github.com/David-H-Bolton/Projects/blob/main/rust_pokerhand_faster.zip

contains a much faster version. On Linux it takes about 127 ns per hand. On Windows it’s about 190 ns.

Update: This is now obsolete as Visual Studio 2022 which appeared in November 2021 is 64-bit.  D’oh!

It’s quite surprising that in this day and age, that there is still 32-bit software in use. Visual Studio is a prime example.   Windows has been 64-bit for quite a while now.

If you look in Task Manager, you’ll probably notice that programs with a (32 bit) after their name are few and far between.

On the screenshot, only one out of 11 is 32-bit and that’s pretty typical.  Linux and Mac are probably similar.  Here’s a stackexchange question on how to tell if a process is 32 or 64 bit.

In Visual Studio, it’s very easy to switch between 32-bit or 64-bit compile target. Unless I have a real need, I go for 32-bit for programs I write because they are typically not going to need over 4 GB of RAM. And 32-bit code usually runs faster than 64-bit because instructions are typically shorter which means more instructions in the execution cache etc.

However some systems have a lot of code and there are people who want a 64-bit version of Visual Studio.  You can read some of their requests here.

I’m still on a Linux laptop BTW. My new cooler has turned up and tomorrow I hope to install it. The Windows screenshot came from my work laptop which I emailed to myself!

I’ve got both 32-bit Raspbian and 64-bit Raspberry Pi OS on two sd cards and intend to run both and compare benchmarks just to see the difference.

Another benchmark utility that looks interesting is sysbench (sudo apt install sysbench to install). It runs from the terminal and lets you run benchmarks against file io, cpu, memory threads, mutex and oltp.  Just type sysbench and you’ll get a list of commands.

It was very easy.  This was onto my Pi 4 running 64-bit Raspberry Pi OS.

Go to the releases page on the vsCodium website, it’s on GitHub.  If you are running 32-bit Pi OS then you need the codium_1.46.0-1591900344_armhf.deb file (the number will most likely have changed).  For the 64-bit one, you need the codium_1.46.0-1591900344_arm64.deb.

When you click on the link it will download and ask if you want to keep it. It will then give you the option of opening it and select the archiver. That will install it for you.

After that, to run it from the command line just type codium.

Or as I just discovered. Look on the pull down menu, go onto accessories and you should see (probably near the bottom) VSCodium. Move the mouse over and right-click.You’ll see a popup menu with Add to Desktop and Properties. If you click the former, you get an icon on your desktop.

Screenshots were captured with the Flameshot utility. It’s installed with sudo apt install flameshot. That’s the VSCodium and Flameshot icons.

So after deciding I was going to wait until the 64-bit Pi OS was tested and ready for use, I changed my mind and downloaded the beta and installed it.

It ran ok, though as with any Beta there are bound to be little glitches. There’s a survey where they are interested in what the PI is being used for and it showed UNDEFINED for my Pi’s serial number, though

cat /proc/cpuinfo

worked fine and displayed it.

The display utility let me change my display to 75 HZ at 1920 x 1080 and then promptly crashed. After reboot though it was at 75 HZ.

My main reason for trying it out though, I was curious about development tools, particularly IDES. I had forgotten that code.headmelted.com, the alternative source for Visual Studio Code (my favourite) supported arm64 which is what the 64-bit runs.  I was able to install VS Code from there without any problems.

64-bit vs 32-bit

32-bit has the memory limitation of 3 GB (in both Windows and Linux)  whereas 64-bit offers any amount of RAM up to what’s available. It’s not that big  thing with a 4 GB PI but with 8 GB it can make a big difference.  This article (Sorry that the link is to an article on Medium.com which offers a few free articles then paid) suggests that 64-bit Debian (which Raspberry Pi OS is) is quite a bit faster than 32-bit.  My impression is that it feels a bit snappier but that could be wishful thinking n my part!

I’ll put Asteroids on and see what fps I can get though that may not be a great way to compare them as the GPU plays a big part and I can’t see it making any difference, but I could be completely wrong on that. More as I investigate further.

I won’t be buying one for the moment but I mention it for another reason. 4 GB is the maximum RAM that a 32-bit OS can use, and on the PI like on Windows it’s actually 3 GB. To be fair you can have two processes each with 3 GB on the 8 GB Pi.

The announcement did mention that a beta 64-bit Raspbian OS is available for download and it’s here. This article shows that the 64-bit Os they tested is faster on the Pi than 32-bit.  This link to the DietPi forum tells you how to boot dietpi into 64-bit.

It’s to be hoped that 64-bit ARM development software will become available. Clang and gcc should be but I’m thinking of the code.headmelted.com version of Visual Studio Code.

As always if you are buying a Raspberry Pi 4B, I strongly suggest you get a case with a fan. They are not expensive and do make a difference. Despite running the Asteroids game, which is pretty intense, I have never got my 4B temperature above 51C. THat said I’ve ordered a touchscreen with a case for a 4B on the back and it doesn’t seem to take a fan. So it will be interesting to see what its like fanless. More on that when the touchscreen arrives.