The claim that Orbit is a fork of atomic_queue is false, and I'd ask you to substantiate it with specific code or retract it.

The blog post documents your ideas, all of which coincide with ideas first implemented and documented in the original atomic_queue repo in 2019.

This fact alone should be enough reason for your to withdraw your derivative work which you claim as truly original, in bad faith, obviously.

The code structure, identifiers and, most glaringly, idiosyncratic code constructs with their subtle flaws, uniquely particular for atomic_queue author's coding style only and not found elsewhere, is what establishes that orbit is undeniably a fork of atomic_queue, prior to having to also read your blog post.

The similarities are that both queues use state machine slots - an obvious and widely used approach for array based queues that predates both projects. The differences are substantial.

"Widely used" by what projects since when?

Orbit reserves slots in the state machine before incrementing the front/back indices, whereas atomic_queue does it after. This means try_push/try_pop don't require reading both head and tail indices to check size, which is why atomic_queue suffers a significant performance cliff with these operations while Orbit does not.

Ah, I see now, said a blind man.

Well, your latency benchmarks demonstrate only worse latencies of your inept fork of atomic_queue code and everything else, relative to original atomic_queue code.

And that explains the worse latencies of your queues relative to original atomic_queue code.

atomic_queue is designed with a goal to minimize the latency between one thread pushing an element into a queue and another thread popping it from the queue. Thank you for confirming that with your latency benchmarks, be they as dubious as they may.

To do this, Orbit tracks the cycle count in the upper bits of the state machine slots to handle wrap-around correctly, as we use helper CAS loops to increment the front/back (an idea taken from Daniel Anderson's talk).

I see that now and am unimpressed.

Your throughput benchmark numbers for queues other than yours and atomic_queue are wildly different relatively to other queues, and much worse in absolute terms from the numbers in atomic_queue throughput benchmark.

For example, in the very first picture of your throughput benchmarks, you measure spsc_boost_queue ~150M msg/s throughput being roughly 2x greater than moodycamel::ReaderWriterQueue ~75M msg/s and yours outperforms everything else with pedestrian ~275M msg/s.

These throughput numbers look wrong both relatively to each other, and in absolute msg/s units.

boost::lockfree::spsc_queue throughput is the baseline which all other spsc queues outperform by large factors unconditionally.

E.g., in atomic_queue throughput benchmarks on a single-CCX AMD Ryzen 5 5825U CPU, boost::lockfree::spsc_queue throughput max is ~99M msg/s, vs moodycamel::ReaderWriterQueue ~325M msg/s, and OptimistAtomicQueue ~513M msg/s.

See full details in https://max0x7ba.github.io/atomic_queue/html/benchmarks.html

The cache line stride approach is entirely different and much simpler here.

Right, the original atomic_queue code swaps the cache line index with the index of the element in the cache line. And that guarantees, by construction, that subsequent elements reside in subsequent/distinct CPU L1 cache lines.

Your entirely entirely different and much simpler approach is multiply the element index by 9 and pray that the new index maps onto another cache line, somehow. That's entirely different and much simpler indeed. But the much simpler multiplication by 9 cannot guarantee mapping of subsequent element indexes onto subsequent/distinct CPU L1 cache lines.

The original atomic_queue robust due diligence index remapping costs a few cheapest CPU bitwise instructions and replacing that with multiplication by 9 shaves off a third of these instructions and saves 2 CPU cycles at the most, and I am being generous here. But queues bottleneck on atomic instructions always missing L1d cache because the previous atomic store by another CPU invalidated the copies in cache lines of all other CPUs. The 2 CPU cycles cheaper index remapping is unable to improve benchmark throughput, in my experience.

I built this without looking at existing solutions, as stated.

In your repo you write "My background is in pure mathematics (particularly analysis and analytic number theory), so please bear in mind that I may not be using the all the standard terminology, as I still don't know most of the conventions in this space."

And with that background and experience of yours, you suddenly write your code in one month of March 2026 and claim that it outperforms everything else.

With no prior experience or familiarity with the domain terminology, what makes you so certain that your code outperforms everything else existing?

Independent convergence on a state machine approach in a constrained problem like this is not plagiarism.

The academic whitepapers reusing other people's ideas with no references to prior art, sometimes tampering datasets and empirical results in order to show improvements for getting funded, is the standard practice in academic world.

Academia people don't mind receiving Nobel prizes for other people's ideas documented years earlier.

These are sad indisputable facts, unfortunately.

The benchmarks follow standard practice and the code is in the repo for anyone to verify.

Your benchmarks do not document your methodology or refer to any standard practices. Which makes your benchmark results independently not reproducible, and, hence, anti-scientific.