<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Pattern-defeating Quicksort · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2106.05123/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2106.05123/feed.xml" rel="self" type="application/rss+xml" /><item><title>Pattern-defeating Quicksort — mentioned by mlochbaum</title><link>https://news.ycombinator.com/item?id=36309049</link><guid isPermaLink="false">urn:hackerpapers:mention:2106.05123:36309049</guid><pubDate>Tue, 13 Jun 2023 12:09:34 GMT</pubDate><description>&lt;p&gt;pdqsort paper: https://arxiv.org/abs/2106.05123 fluxsort compiles in C++ just fine. Pre-sorted data is just the simplest example of adaptivity. Partially-sorted input can&amp;#x27;t be tracked easily by the caller and I believe that something like merging a few sorted arrays by concatenating then sorting is pretty common. Fluxsort, glidesort, ipnsort, vergesort all have methods that allow for merging such patterns quickly. According to the benchmarks in the article, many are also doing better at low-cardinality data. If you don&amp;#x27;t consider any of this adaptivity useful, it&amp;#x27;s very strange to compare to…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2106.05123/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item><item><title>Pattern-defeating Quicksort — mentioned by sanxiyn</title><link>https://news.ycombinator.com/item?id=35889886</link><guid isPermaLink="false">urn:hackerpapers:mention:2106.05123:35889886</guid><pubDate>Wed, 10 May 2023 16:44:17 GMT</pubDate><description>&lt;p&gt;Theoretical advances are constant (just check the literature), but two particular advances in the last decade are of practical importance: one for sort and one for hash table. As in: check the implementation you are using, if it doesn&amp;#x27;t incorporate these advances you are leaving substantial performance (2x is not out of the question) on the table. How Branch Mispredictions don&amp;#x27;t affect Quicksort (2016) https://arxiv.org/abs/1604.06697 Quicksort is still the algorithm of choice for general purpose internal unstable sort. In modern hardwares, quicksort spends a lot of time recovering from…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2106.05123/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item><item><title>Pattern-defeating Quicksort — mentioned by nightcracker</title><link>https://news.ycombinator.com/item?id=27874177</link><guid isPermaLink="false">urn:hackerpapers:mention:2106.05123:27874177</guid><pubDate>Sun, 18 Jul 2021 16:23:46 GMT</pubDate><description>&lt;p&gt;This article is missing the important reference to the prior work by Edelkamp and Weiss, on branchless quicksort [1]. I&amp;#x27;ve long since implemented that in pdqsort [2], along with other techniques described by me in [3] which is a drop-in replacement for std::sort that&amp;#x27;s ~twice as fast as std::sort for small data with branchless comparisons. It&amp;#x27;s also available in Boost.sort [4]. [1] https://arxiv.org/abs/1604.06697 [2] https://github.com/orlp/pdqsort [3] https://arxiv.org/abs/2106.05123 [4] https://www.boost.org/doc/libs/1_76_0/libs/sort/doc/html/sor...&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2106.05123/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item></channel></rss>
