Faster Radix Sort via Virtual Memory and Write-Combining · HackerPapers discussions

Faster Radix Sort via Virtual Memory and Write-Combining — mentioned by janwas

Tue, 13 Jun 2023 17:35:52 GMT

> According to the benchmarks in the article, many are also doing better at low-cardinality data. VQSort handles low cardinality quite well. Unfortunately only a few benchmarks in the article (not including that one) were re-run after our performance bug fix. > it's very strange to compare to std::sort which does make some attempt to be adaptive. We chose std::sort mainly because it seems to be widely used. > But we all know why you're doing that. I suppose you'll keep your fingers in your ears regarding 32-bit radix sort huh, I'm curious what's the background or context for this remark? FYI…

Paper and discussion history. A mention is not an endorsement.

Faster Radix Sort via Virtual Memory and Write-Combining — mentioned by janwas

Sun, 05 Jun 2022 05:53:43 GMT

Actually we also support floating-point (32/64 bit, possibly even 16). I've previously also looked into radix sort: https://arxiv.org/abs/1008.2849 Radix sort may actually be faster if you know that only a few bytes are guaranteed to distinguish keys, but that's difficult to guarantee/assume at the library level.

Paper and discussion history. A mention is not an endorsement.

Faster Radix Sort via Virtual Memory and Write-Combining — mentioned by janwas

Sat, 04 Jun 2022 05:37:06 GMT

:) Are you thinking of ips4o (sample sort)? That's about 2-3x std::sort. There's also a pending patch to std::sort that replaces it with BlockQuicksort which would narrow that gap. We integrate vqsort into ips4o, calling it once subarrays fit in L2. That speeds up ips4o by 2.9x (single thread) and 1.6 (parallel - bandwidth limited). More details in the paper. I previously also worked on radix sort: https://arxiv.org/abs/1008.2849 Interestingly, that 12 year old result on dual-socket/8 cores is only about twice as fast as a single AVX-512 core today.

Paper and discussion history. A mention is not an endorsement.

Faster Radix Sort via Virtual Memory and Write-Combining — mentioned by frankmcsherry

Thu, 20 Aug 2015 06:30:01 GMT

There is this cool related work [0] that I wanted to talk about, but couldn't get to show an improvement on my laptop, which uses software write combining to mitigate cache limitations. In particular, they are worried about the fact that 8-way associative L1 doesn't like to hold 256 specific cache lines, so they manually buffer writes into 16k (= 256 cache lines) contiguous bytes, using a non-temporal write when a cache line is full. They report hitting 88% of their system's peak memory bandwidth. You could do the same thing (I think) to avoid TLB limitations, manually staging everything in a…

Paper and discussion history. A mention is not an endorsement.