busybee

I had my release party for Transitions today. It went pretty well! Around a dozen folks attended in VRChat, and another half-dozen tuned in to the stream. Everyone who came enjoyed it and had nice things to say.

I hope that over time I can get more attendance to things, but the time of day for this particular show wasn’t great, as a lot of people wanted to come but had other obligations (such as, you know, sleep). The time I chose was based on trying to split the difference between a lot of peoples' needs. But this is why I also record my shows for posting on YouTube.

This show was also really big and took a lot of work to put on and I am so freaking tired. What I’d like to do is to just start doing more frequent, smaller shows, instead of trying to do these big all-out things on a monthly basis. I should experiment with different times on day on both Saturday and Sunday (which is consistently the least-bad day for everyone) and see if I can get regular attendance going. These shows could just be for funs instead of having to be a big rigmarole.

Right now I’m super tired and I having finished the album I can at least take a break from music production for a while.

I’m also a bit disappointed with the world of indie music and the marketing thereof. I have a whole rant brewing about the asinine way that music marketing works, but tl;dr¹: people only care about stuff that is coming out soon, nobody cares about stuff that’s already out. I hope I’m wrong about this. At least Transitions seems to have a bit more legs than my previous releases. (But my previous releases still exist! They’re still totally viable albums that you can buy and/or listen to!)

Anyway, I’ve submitted Transitions to a few different promo things but I’m not expecting a lot because they only care about stuff that’s upcoming or Brand New, and having been out for a few days it’s no longer Brand New. Which is just… dumb.

As part of the Fediwave Artists Streaming Series, I have a concert scheduled for Tuesday, August 13 at 3 PM Pacific Daylight Time (GMT-0700). To watch, join my personal Owncast server. I’ll be playing acoustic versions of a bunch of my songs, and answering some Q&A as we go! And maybe sharing previews from my upcoming album!

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!

A common pitfall I see programmers run into is putting way too much stock into Big O notation and using it as a rough analog for overall performance. It’s important to understand what the Big O represents, and what it doesn’t, before deciding to optimize an algorithm based purely on the runtime complexity.

After getting in an extended discussion about the supposed performance tradeoff between #pragma once and #ifndef guards vs. the argument of correctness or not (I was taking the side of #pragma once based on some relatively recent indoctrination to that end), I decided to finally test the theory that #pragma once is faster because the compiler doesn’t have to try to re-#include a file that had already been included.

For the test, I automatically generated 500 header files with complex interdependencies, and had a .c file that #includes them all. I ran the test three ways, once with just #ifndef, once with just #pragma once, and once with both. I performed the test on a fairly modern system (a 2014 MacBook Pro running OSX, using XCode’s bundled Clang, with the internal SSD).

Today I got into a discussion regarding embedded programmers and their tendency to avoid exceptions in C++ (even after moving to new-school “embedded” systems such as smartphones, game consoles, and set-top boxes). The argument basically boils down to three things: code size, memory usage, and execution speed. So, rather than continue on without actually putting my beliefs to the test (the discussion basically centered around whether engineers are making assumptions based on how things were 15+ years ago), I decided to construct a minimal test which I think shows where the tradeoffs may be.

Note: The timing and memory analysis has been updated as of May 24, 2018.