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.
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.
To be very explicit, the "...rely" is me being facetious, I'm not really implying anyone actually relies on use after free! More like they lucked out on not catching it and shipped it anyway, hence the "rely" bit.
Writing random values to freed memory would mostly work, at some cost to performance.
The memory could get allocated again before it is re-used, and whatever is put in it might be less trappy than a random value. And, of course, a random value might not trap.
Better is not to do things that result in referring to dead memory: easy in modern C++, apparently difficult in C.
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.
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.