spacecadet_

> Very few instructions even allowed interaction between the top and bottom 128 bits

That would be plain AVX, AVX2 has shuffles across the 128-bit boundary. To me that seems like the main hurdle for emulation with 128-bit vectors, in my experience compilers are very eager to emit shuffle instructions if allowed, and emulating a 256-bit shuffle with 128-bit operations would require 2 shuffles and a blend for each half of the emulated register.

EDIT: I just noticed that the benchmark in the article is pure math which probably wouldn't hit this particular issue, so this doesn't explain the performance difference...

In the branchy function, id is only compared if distance is equal, and since distance is a random float, this almost never happens and the corresponding branch is nearly perfectly predicted. The branchless function always compares both id and distance, effectively doing twice the work. It's only part of the reason why there's a 2x performance difference, but I thought it was interesting.

I really don't know how LLVM picks between branches or conditional moves, but my guess is that it doesn't assume that float equality is any less likely than other conditions, and some optimization pass in O3 turns unpredictable branches into conditional moves. I base this on the fact that adding std::hint::unlikely to the "equal" branch produces the same assembly for the function in both modes.

https://godbolt.org/z/erGPKaPcx

Whether it's safe to assume in general that float equality is unlikely for the purpose of program optimization, I'll leave to the compiler engineers. If you know the data your program will be handling, adding hints will avoid these surprises.

You're right that it's not exactly n^2. For the i-th element we perform (n - i - 1) comparisons (indexing from 0). This adds up to a total of (n - 1) * n / 2 comparisons. (see https://en.wikipedia.org/wiki/Triangular_number)

In the end it doesn't make a difference for big-O analysis because it's used to describe the behavior when n approaches infinity, where the quadratic factor takes over.

Is this still the case with recent audio hardware? I was under the impression that a typical instrument's output levels are far too low to cause any damage and that all inputs would be surge protected.

Apps aren't being written _on purpose_ to rely on the allocator doing nothing with freed memory because that's not in its interface, and this change doesn't actually do anything to stop apps from reading freed memory.

There is no behavior that a program could legally rely on when reading freed memory. The assumption behind malloc/free is that freed allocations aren't used by the program anymore, so correct programs don't rely on reading freed memory at all and the allocator implementation is then free to do anything at all with the freed memory, it just turns out that the simplest behavior on the allocator side is to do nothing at all and just leave the freed memory as-is.

The only thing this does when speaking of programs reading freed memory is that it breaks existing incorrect programs that just happened to work because of an implementation detail of the allocator, and then later someone will write another incorrect program that just happens to work because the allocator now zeroes out freed memory. To actually stop the problem of programs reading freed memory, the OS side would have to enforce the use of memory-safe languages which by design cannot access unused memory.

Haven't read the entire post yet, but must say that this was the page that finally made me look into how a webpage works so I could hide the gifs to read the actual content in peace. Why would anyone, much less a cognitive psychologist, think it's a good idea to take a fairly long piece of text and then liberally shower it with attention-grabbing moving images? Must be Twitter brain.