Weekly Head Voices #153: pH < 7 dreams.

Looking back at the week from Monday September 3 to Sunday September 9, I present to you the following memories and after-effects.

Aphex Twin never left us

I serendipitously ran into T69 Collapse, the brand new track and video by Aphex Twin.

In the grand tradition of WHV intro art, I have embedded the video above.

Whether you’re a fan or not, I think it’s worth sitting through this one, preferably with the headphones and the video in full screen.

Pro-tip: This is not one of those tracks where the whole thing can be more or less predicted by viewing the first minute. There’s a thing at 1:55 and a second thing at 3:14.

I had to wonder whether the 3:14 was intentional. We’re not much into our biblical references over here as you might know, but you have to recall that Aphex Twin is the guy who, already back in 1999, hid his face in the spectrogram of a music track called:


\[\Delta M_i^{-1} = -\alpha \sum\limits_{n=1}^N D_i [n] \left[\sum\limits_{j \in C[i]} F_{ji} [n-1] + Fext_i [n^{-1}]\right]\]

That’s the actual name of the track (#2 on the famous Windowlicker EP), although most people (plebs!) refer  to it as just Function or Equation. I got sucked down that rabbit hole last night, but no-one on the internet seems to know the true meaning of the equation. Please ask RDJ if you ever run into him.

Anyways, I have embedded \(\Delta M_i^{-1} = -\alpha \sum\limits_{n=1}^N D_i [n] \left[\sum\limits_{j \in C[i]} F_{ji} [n-1] + Fext_i [n^{-1}]\right]\) below for your listening and viewing pleasure. Aphex Twin’s face appears at 5:30.

APFS encryption vs Samsung hardware encryption effective SSD speed

I ran benchmarks on my external Samsung T3 SSD comparing the speed of encrypted APFS to unencrypted APFS with Samsung’s hardware-based full disk encryption.

I used AmorphousDiskMark, BlackMagic Disk Speed Test and plain old iostat whilst copying 30GB of files to and from the disk.

There will probably soon be a detailed blog post over on vxlabs.com about this, but I’ll give you the skinny here:

  • It’s hard to get benchmarks right. BlackMagic gave wildly varying results depending on how many times I let it run its benchmark for example.
  • APFS’s software encryption looks like it causes a performance hit ranging from 5 to about 10%, with outliers in both directions.
  • Emacs can calculate over columns of data, for example from iostat’s standard out, using a simple M-x calc-grab-from-rectangle and M-x calc-vector-mean.

Brave browser and the Basic Attention Token (BAT): This could be big. Or not. It’s at least interesting.

Brave is a new(ish) browser also based on the Chrome engine.

I knew they were doing something with cryptocurrency, and paying or getting paid for the consumption of content and/or advertising, but I was, as you can see, quite vague on the details.

What I learned last week taking it for a quick spin is the following:

Brave out of the box is massively privacy-focused. Without installing any plugins, it blocks every single advertisement and tracking cookie known to humankind. It also automatically switches to secure SSL wherever that’s possible.

More interestingly, in Brave you can opt in to “Brave Payments“, which looks like it might soon be renamed to Brave Rewards, but don’t quote me on that.

One part of this system, is that you as a user contribute a set amount of BAT tokens (these are tokens on the ethereum chain) per month. At the end of each month, Brave will pay out your tokens to the websites that you visited, based on the amount of time you spend on each site.

In this way, publishers can get recompensed for their content in hard cash, without having to resort to advertising. (It does look like Brave also supports the model where advertisers can pay, in BAT tokens of course, for your eyeball time.)

Brave already has 4 million monthly active users (MAU).

If they’re able to grow this user base, and get a significant portion to participate in the payment system, this could be a game changer. Imagine being able to pay your favourite content creators in this seamless way, and being able to switch off ads in  the process!

RunAlyze where have you been all my life?

I publish my runs to Strava, as I have a bunch of friends there, and I like the idea of a social network where you have pay with a bucket of sweat before you’re allowed to say anything.

However, I was also relying on Strava to keep track of my shoe mileage. Recently, it started losing the miles I put on my Xero Genesis sandals (the most unforgiving shoes in the universe), and I was not able to coax the system into correctly tracking those terrible, terrible kilometres.

Because I use HealthFit to push my data to Strava, I took a look at some of its other endpoints and then, again extremely serendipitously, ran into:

RUNALYZE

It’s a site made by two running nerds (and it really shows) from Germany.

It keeps track of my shoes (the goal of this… exercise, bad pun, sorry) but the authors have also implemented a bunch of metrics from academic papers, some metrics of their own, and they show tables of your data sliced and diced in many different ways ON ALL FOUR WALLS of their website.

<Dr Evil voice>It’s breathtaking.</Dr Evil voice>

Anyways, if you’re a running nerd too, you should probably take a peek.

Fin

See you soon brothers and sisters. I am grateful for our time together.

 

Android vs iPhone performance: A quick note.

I’ve been spending some time doing research on the relative (perceived) performance of flagship Android phones compared to iPhones. I will probably not write the extended post I was planning to, as it seems that it’s hard to answer this question scientifically, and, perhaps more importantly, it makes people Very Very Angry.

I would still like to leave you with some interesting reading material. Hence this quick note.

From this discussion post (December 2016) by CodingHorror, aka Jeff Atwood, one of the two founders of the whole StackOverflow empire, where he measures the relative performance of his discourse web-app, the following choice quote:

Some Android users report up to about 29 score on very new late
2016 Android devices, depending on the vagaries of the browser
used. Still below the 2013 iPhone 5s which can be purchased used for about $150 these days.

That’s pretty amazing: Based on the browserbench speedtest, which is supposed to reflect quite realistically real-world web-browsing performance, the 2013 iPhone 5s outperforms 2016 Android flagships. Ouch.

My Snapdragon 808 does a measly 14.7 on browserbench. The iPhone 5s which is a year or two older does more than double that.

There are more sites where this discussion / flamewar is being continued. Google is your friend.

The core argument is that Apple long ago made the call that fewer, more high performance CPU cores would give the best subjective performance. In other words, to a user the phone would feel more responsive.

This does make sense: As a user, when I tap a button, I would like to see an instantaneous response. A single really fast core is going to help more with this than a higher number of slower cores.

Furthermore, programming single-threaded apps is significantly easier than programming robust and efficient multi-threaded apps. You can guess what the apps in the various stores look like in this regard.

The iPhone 6s had only two cores, whereas most mid- to high-range Androids had 6 or more cores when the 6s was released.

The iPhone 7 A10 chip has finally made the jump to 4 cores, two of which are lower power cores. Still, it turns out this chip again crushes all of its Android (read: Qualcomm) competition.

Here’s another relevant demo on YouTube where the same set of apps are started up in the same sequence, which is repeated, on both the iPhone 7 and the Samsung S7. All in all, the iPhone manages to get through the exercise more than twice as fast as the S7. This is definitely some indication of how users will perceive the responsivity of these devices.

The argument that multi-core was not a good choice for Android is weakened to an extent by this recent AnandTech analysis showing that these phones are actually pretty good at utilising all of their cores:

In the end what we should take away from this analysis is that
Android devices can make much better use of multi-threading than initially expected. There’s very solid evidence that not only are 4.4 big.LITTLE designs validated, but we also find practical
benefits of using 8-core “little” designs over similar single-cluster 4-core SoCs.

My personal experience with the Snapdragon 808 (6 core big.LITTLE) in my BlackBerry PRIV (late 2015 flagship) has been less than stellar. I love the phone for its screen, physical keyboard and other little idiosyncrasies, but the fact that I often have to wait more than a second after tapping an icon or a button before it responds, combined with the terrible Android security story (where the PRIV paradoxically does quite well), makes me wonder about the future smartphone landscape for Android enthusiasts.