That sentence is specifically about composers of methods in change ringing, where the musical possibilities are tightly constrained by the rules and the physics of ringing large bells. Change ringing is based on permutations constructed by swapping adjacent pairs. (Except for the jump changes that the article is about.) For a “triples” peal on 7 bells the ringers are supposed to ring all 5040 possible permutations. It’s called “triples” because you can make up to 3 swaps at a time; one of the challenges (for example) is to construct a triples peal that only uses triple changes.
The problem in the US is that time zone boundaries very frequently do not match state boundaries.
It’s common for major cities to be located on rivers that are state boundaries, the area around the city uses the same timezone, and one of the states has a timezone boundary in the middle. Indiana has many tz database entries because of this kind of thing.
There are other fun cases like the Navajo Nation in Arizona.
I live in South Dakota, which is one of them—the Mountain/Central timezone boundary within the state follows the Missouri river. (Locals refer to "East River" and "West River" to refer to the two halves of the state. The capital, Pierre, is technically East River, but is right on the banks, almost dead-center.)
pure decoder width isn't enough to tell you everything. X86 has some commonly used ridiculously compact instructions (e.g. lea) that would turn into 2-3 instructions on most other architectures.
The whole ModRM addressing encoding (to which LEA is basically a front end) is actually really compact, and compilers have gotten frightently good at exploiting it. Just look at the disassembly for some non-trivial code sometime and see what it's doing.
They care about exact slowdown factors, and they don’t like the instructions that use any of the CPU’s execution resources because the program’s real work interferes with the slowdown factor making it harder to control.
The NOPs in effect use up a small fraction of the instruction decode bandwidth, and if they insert enough NOPs they can reduce the number of real instructions that are issued per cycle and slow down the program with a fine degree of precision.
Many recent CPUs eliminate NOPs without executing them, so using NOP may work on a CPU but be ineffective on another.
A double BSWAP is equivalent with a NOP, but no existing CPU does any special optimization for it and it is very unlikely that any future CPU would do something special with it, as it is mostly obsolete (nowadays MOVBE is preferable instead of it).
NOP cannot ensure a certain slow-down factor, except on exactly the same model of CPU.
> Many recent CPUs eliminate NOPs without executing them
The elimination will still take some amount of time, and the smaller this amount is, the better, because it allows dialing in the slowdown more precisely. Of course how many NOPs you need for a particular basic block needs to be measured on the CPU you're profiling on, but that's also the case if you use a more consistently slow instruction, since the other instructions won't necessarily maintain a consistent speed relative to it.
That's not necessarily true. Many modern CPUs have uop caches, and it's reasonable to assume implementations will eliminate NOPs before placing lines in the uop cache. A hit on the uop cache loses any slowdown you hoped to achieve since now the NOPs are neither fetched nor decoded.
That's an interesting question, because the uop cache is filled early in the pipeline, but zero-idioms are only detected around the rename stage.
They might be able to skip a plain 0x90, but something like mov rax, rax would still emit a uop for the cache, before being eliminated later in rename. So at best it would be a fairly limited optimization.
It's also nice because rename is a very predictable choke point, no matter what the rest of the frontend and the backend are busy doing.
WireGuard can be used to create a virtualised private network, but doesn't do so on its own, or without additional infrastructure. WireGuard tunnels network packages securely, with high throughput, from an arbitrary point A to an arbitrary point B. No more, no less.
Just because it can be used to recreate VPNs traditionally used to remotely dial into a secure network zone doesn't mean it shouldn't be used in far smaller use-cases. WireGuard doesn't constitute anything like a full VPN solution on its own.
