The phenomenon of multiple prey animals swarming larger predators to drive them off is known as mobbing.[0] Crows seem to do it quite readily. Very cool that you got to see it!
See my reply to your sibling comment - I do in fact mean spectral complexity at any given moment, not just over the course of the song. Many species of birds can and do vocalize with complicated timbre, including harmonic stacks, buzzes, clicks, and others harder to characterize.
And it's great that you bring up the possibility that two modes might be engaged. The avian vocal organ, the syrinx, has two sets of membranes which can vibrate as air is passed over them. Many species (particularly, as you'd expect, the ones best at imitation, like corvids, parrots, lyrebirds, etc) are able to control these two sources independently (but even those which generally don't control them separately can produce syllables with rich timbre), layering a harmonic stack with a click or a buzz.
I feel I should reiterate: nothing here is meant to detract from TFA's demonstration of what looks like a nice acoustic analysis tool. But TFA is, unfortunately, just plain wrong in its conclusion that birdsong is mostly pure tones.
I should have been clearer. I am also talking about moment-to-moment spectral complexity or entropy.
I agree that the point TFA is suggesting seems to be about the spectral complexity at any given moment in song - what you might call the timbre - and how nearly pure the tones in their spectrograms are. (They don't specify what species they're showing. Looks like several, but I can't ID them by eye.)
My point is that no, in fact, many bird species produce vocalizations that are indeed spectrally complex (beyond even just harmonic stacks) from moment-to-moment.
Take a look at song from a blue jay (https://www.remoteenvironmentalassessmentlaboratory.com/expl... ; not the best example, or one I produced, but an easy one to hand), particularly the syllables near the end of the clip. That's an example of a complex timbre.
And lots of species produce song and calls with features like this.
I don't want to detract from the images, or the work that went into this, but, er, there are a lot of types of birds. Just among passerines (songbirds), we're talking over 6,000 species.
So any sweeping statement like "birds don’t seem to bother to create a complex multi-layered harmonics pattern" is practically guaranteed to be wrong. And so it is. Lots and lots of birds sing incredibly harmonically complex songs. Browse any of these (https://www.remoteenvironmentalassessmentlaboratory.com/expl...) if you're interested - it's a tiny sample of birds, and many, many of them do in fact have harmonically complex songs.
The concept is interesting, but I'm a little leery of the detail that the benchmark performance reported is in each case "the best run out of 100".
One can claim, thus, only that this sort method's near-best-case performance is better than `std::sort`'s near-best-case performance (at least at the, er, P01 level). That says little to nothing about the modal or reasonably-bad-case (say, P95) performance.
A comparison of median values would lend much more weight to the claim that this method is "faster" than `std::sort`.
But a really good benchmark report would show the entire histogram of performance for each method.
(By "modern" I assume you mean densely-spaced [~10um] multi-pad linear silicon probes, the NeuroPixel being the most celebrated example among the non-specialist public.)
What many pads close together can give you is the potential for the waveform from a spike nearby to register on more than one pad.
In theory this should make spike-sorting easier, because you can distinguish two neurons whose spikes might have the same waveform on pad #1 but different waveforms on pad #2.
In practice, spike sorting improves, but not by as much as you'd think.
Part of this is down to physical factors (which are improving): probe geometry, pad shape, pad material, pad impedance, and so on.
Another part is down to software (which is also improving). Single-channel spike-sorting is by now probably close to as good as it's going to get given the information content of its input, and the algorithms and software to perform it are well-understood and stable.
Algorithmic approaches to multi-channel spike sorting, however, are the subject of active research with multiple promising avenues of progress, and software to perform it is ... well, charitably, let's call it "rough-and-ready." (It's nearly all lab-grown software, which means it's written by enthusiastic amateur programmers [among whom I'd count myself, no shade intended here] who soon move on to new projects because of the structure of academic science. This means the software is buggy, poorly documented, inconsistently supported, and constantly evolving.)
Now, using dense silicon arrays does markedly increase the rate at which I can record well-isolated neurons, but a significant part of this increase is just having more pads in the target brain region - many of the neurons I get from these multi-channel spike-sorting programs only show significant power on one or two pads.
And all of this doesn't even touch on some of the significant challenges that come with using multi-electrode arrays, including higher initial inflammation, later gliosis, and data-collection and storage (a 64-channel array [NB: the NeuroPixel 1 can record from 384 pads] producing 16-bit ints at 20kHz [just about the minimum sampling rate for decent spike-sorting] generates a bit less than 10GB/hour - a volume that real big data people might laugh at, but it sure isn't small!).
And finally, all of this is done off-line. On-line spike-sorting is harder.
So I'm sorry to say that just having a modern multi-electrode array absolutely does not make things "quite a lot simpler."
I don't want to detract from the cleverness here, but I believe your benchmarks could use some work. Here are a few suggestions:
1. Simply testing something 1000 times and (presumably) presenting the arithmetic mean is not very informative. Looking at the detailed reported benchmark times (in the output file in tests), it looks like many of the timing outcomes have high variance. Rather than running the tests 1000 times and taking the mean, you might consider running 10 batches of 100 tests (or 1000, if you can) and presenting the mean and variance of the resulting distribution. In general, k sample groups each of size p will provide more reliable information about the underlying distribution than one sample group of size k*p (for reasonable k and p, obviously).
2. Related to that, the results of the "inserting a number of elements" and "deleting a number of elements" tests are significantly worse for the tiered vector vs the std::vector than the "insert/delete a single element" tests. You don't mention this in the readme, but thinking about why it is might be informative. Thrashing seems like a possible explanation, and one you might be able to mitigate.
3. Are you making sure your cache is warm before starting to measure performance? (Pardon, I didn't look through every line of your tests.) Particularly for std::vector, and likely your intermediate deques too, this will have a big effect on timing.
4. Finally, it looks like you're primarily testing using ints (?). It would probably be a good idea to see if your results hold for a different payload size.
I don't know whether these will improve or worsen your comparison against std::vector, but they will make your claims more robust.
[0] https://en.wikipedia.org/wiki/Mobbing_(animal_behavior)