memory

tl;dr Raspberry Pi engineers tweaked SDRAM timings and other memory settings on the Pi, resulting in a 10-20% speed boost at the default 2.4 GHz clock. I of course had to test overclocking, which got me a 32% speedup at 3.2 GHz! Changes may roll out in a firmware update for all Pi 5 and Pi 4 users soon.

My quest for the world record Geekbench 6 score on a Pi 5 continues, as a couple months ago Martin Rowan used cooling and NUMA emulation tricks to beat my then-record score.

This is the fastest Arm desktop in the world, yes, even faster than the M2 Ultra Mac Pro. And today, I made it even faster.

I upgraded everything: Faster RAM, 128 core CPU, 40 series GPU, I did it all, and we'll see how much we can obliterate the M2 Mac Pro.

128 cores—that's five times more cores, I'm also going to upgrade this thing from 96 all the way to 384 gigabytes of RAM. The Mac Pro? Sorry, it only goes up to 192.

And we're just in time for the new Cinebench 2024 benchmark, which—yes—this machine dominates.

Edit: There's an even easier way to install PhotoRec now, assuming you have installed Homebrew, and you're comfortable in the command line:

brew install testdisk
sudo photorec

Then follow the prompts to start recovering files.

As a photographer who's taken and processed at least 200,000 photos in the past couple decades, you'd think I have a solid workflow that results in zero lost files... but you'd be wrong. 99% of the time, I follow the workflow:

1. Import photos from memory card.
2. Make sure backup of imported photos completes (so I have two local copies—I also have one copy back up to a cloud storage provider, so two local and one cloud backup).
3. Format the memory card.

A lot of photographers shoot with two memory cards, and have photos written to both—that way the 2nd card would be a double-failsafe. But for most jobs, I don't do that. And one of my digital cameras doesn't even have two memory card slots, so this isn't an option!

Anyways, more often than I'd like to admit, I do something dumb, like:

One one small LEMP VPS I manage, I noticed munin graphs that showed anywhere between 5-50 MB/second of disk IO. Since the VM has an SSD instead of traditional spinning hard drive, performance wasn't too bad, but all that disk I/O definitely slowed things down.

I wanted to figure out what was the source of all the disk I/O, so I used the following techniques to narrow down the culprit (spoilers: it was MySQL, which was using some swap space because it was tuned to use a little too much memory).

iotop

First up was iotop, a handy top-like utility for monitoring disk IO in real-time. Install it via yum or apt, then run it with the command sudo iotop -ao to see an aggregated summary of disk IO over the course of the utility's run. I let it sit for a few minutes, then checked back in to find:

Every year or two, I like to get a good overview of different hosting providers' VPS performance, and from time to time, I move certain websites and services to a new host based on my results.

In the past, I've stuck with Linode for many services (their end-to-end UX, and raw server performance is great!) that weren't intense on disk operations, and Hot Drupal for some sites that required high-performance IO (since Hot Drupal's VPSes use SSDs and are very fast). This year, though, after Digital Ocean jumped into the VPS hosting scene, I decided to give them a look.

Before going further, I thought I'd give a few quick benchmarks from each of the providers; these are all on middle-range plans (1 or 2GB RAM), and with the exception of Linode, the disks are all SSD, so should be super fast:

Disk Performance