Vectorized and performance-portable Quicksort · HackerPapers discussions

Vectorized and performance-portable Quicksort — mentioned by jhalstead

Fri, 01 Mar 2024 19:38:33 GMT

[0] for those interested in Highway. It's also mentioned in [1], which starts off > Today we're sharing open source code that can sort arrays of numbers about ten times as fast as the C++ std::sort, and outperforms state of the art architecture-specific algorithms, while being portable across all modern CPU architectures. Below we discuss how we achieved this. [0] https://github.com/google/highway [1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., which has an associated paper at https://arxiv.org/pdf/2205.05982.pdf.

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

Vectorized and performance-portable Quicksort — HN submission

Mon, 12 Feb 2024 22:17:30 GMT

Vectorized and performance-portable Quicksort (2022)

2 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Vectorized and performance-portable Quicksort — mentioned by nisa

Wed, 11 Jan 2023 18:18:41 GMT

That linked quicksort paper is pretty cool: https://arxiv.org/abs/2205.05982 - for sorting floats/integers the speedup against std::qsort is around 10x. Considering climate change more focus should be put on making fast and efficient software. Every watt not wasted on bad algorithms/code is good.

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

Vectorized and performance-portable Quicksort — mentioned by janwas

Sun, 18 Dec 2022 07:48:05 GMT

Yes indeed. IIRC std::sort's sorting network is only 3-7 elements wide. With SIMD we can handle 256. The trick is to minimize shuffling by reshaping 1D input to 2D and first sorting the columns. Previously one would then transpose (expensive) and then again sort columns. We instead fuse those two steps, see https://arxiv.org/abs/2205.05982.

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

Vectorized and performance-portable Quicksort — mentioned by inkyoto

Sat, 11 Jun 2022 05:23:38 GMT

> Stuff like SVE2 is really marginal when looking at whole system performance. It is not. A recent paper (https://arxiv.org/pdf/2205.05982.pdf) from Google engineering has compared performance of a vectorised (SIMD) vs non-vectorised implementation of the quick sort in the Highway library as well as the performance difference of the AVX-512 vs NEON/SVE1 implementations. By switching to the SIMD processing alone, the 9-19x speedup has been reported, depending on the SIMD unit size (32/64/128-bit numbers have been sampled and measured up). Even the smallest of the two, the 9x perfomance gain…

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

Vectorized and performance-portable Quicksort — mentioned by janwas

Wed, 08 Jun 2022 05:16:57 GMT

Yes, this is discussed in section 4.2 of our paper: https://arxiv.org/pdf/2205.05982.pdf In short, it turns out not to help for single core with vectors, but a few initial passes of ips4o (with 64..256-way partitioning) is faster for parallel sorts.

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

Vectorized and performance-portable Quicksort — mentioned by slackerIII

Sat, 04 Jun 2022 17:12:32 GMT

The paper goes into a lot more details: https://arxiv.org/pdf/2205.05982.pdf

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