busybee

Around a year and a half ago I wrote an article on the perils of relying on big-O notation, and in it I focused on a comparison between comparison-based sorting (via std::sort) and radix sort, based on the common bucketing approach.

Recently I came across a video on radix sort which presents an alternate counting-based implementation at the end, and claims that the tradeoff point between radix and comparison sort comes much sooner. My intuition said that even counting-based radix sort would still be slower than a comparison sort for any meaningful input size, but it’s always good to test one’s intuitions.

So, hey, it turns out I was wrong about something. (But my greater point still stands.)

First off, I am a dummy and completely failed to notice that there are in fact two USB-A ports on the Mini itself. The dock was completely unncessary for my initial setup. Oops!

Also, I just played some test content in HDR and holy heck it looks pretty amazing. Conveniently enough, Safari supports HDR in YouTube while Firefox doesn’t, so I was able to play some videos side-by-side to see the difference, and it was pretty immense, especially in the extremes. Which is, of course, the whole point to HDR.

I’ll probably keep using Firefox for usual video stuff, though, because I’m not a fan of not having a decent ad blocker. Hopefully Firefox adds HDR support soon!

EDIT: Oh yeah, I ended up force-quitting the NI installer so that I could finish installing some system updates and the Wacom driver and so on. What’s really cool is that even though the Wacom driver is still x86, Rosetta still emulates it. Holy cow. Also the Silicon Macs use a new driver signing thing that’s a little onerous but also exposes a nicer way of going into the startup disk selector (now you just hold down the power button while booting, no need to remember an awkward keyboard combination that doesn’t always map right to whatever weird keyboard you’re using at the time).

Also, I had meant to do some disk speed tests as well. See below!