Does this mean that President Trump is the (unexpected) champion of the remote working crowd? Not the hero we need but the hero we deserve, and all that.

That's because some are Indigenous names phoneticized for English speakers (Yonge and Markham on the other hand are entirely English names):

Etobicoke. From Adobigok [1]

Tecumseh (or Tecumseth). From tecumtha or takhamehse [2]

Mississauga. From Misi-zaagiing [3]

[1] https://www.etobicokehistorical.com/brief-history-of-etobico...

[2] https://en.wikipedia.org/wiki/Tecumseh

[3] https://en.wikipedia.org/wiki/Mississauga

It's a cool talk, but the relevance to the present problem escapes me.

If you're alluding to gcc vs fbstring's performance (circa 15:43), then the performance improvement is not because fbstring is faster/simpler, but due to a foundational gcc design decision to always use the heap for string variables. Also, at around 16:40, the speaker concedes that gcc's simpler size() implementation runs significantly faster (3x faster at 0.3 ns) when the test conditions are different.

> What's the x86-64 opcode for arcsin?

Not required. ATAN and SQRTS(S|D) are sufficient, the half-angle approach in the article is the recommended way.

> People have gotten PhDs for smaller optimizations. I know. I've worked with them.

I understand the can, not sure about the should. Not trying to be snarky, we just seem to be producing PhDs with the slimmest of justifications. The bar needs to be higher.

The 4% improvement doesn't seem like it's worth the effort.

On a general note, instructions like division and square root are roughly equal to trig functions in cycle count on modern CPUs. So, replacing one with the other will not confer much benefit, as evidenced from the results. They're all typically implemented using LUTs, and it's hard to beat the performance of an optimized LUT, which is basically a multiplexer connected to some dedicated memory cells in hardware.