From: George Spelvin <lkml@sdf.org>
To: linux-kernel@vger.kernel.org
Cc: George Spelvin <lkml@sdf.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andrey Abramov <st5pub@yandex.ru>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Daniel Wagner <daniel.wagner@siemens.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Don Mullis <don.mullis@gmail.com>,
Dave Chinner <dchinner@redhat.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: [PATCH 2/5] lib/sort: Use more efficient bottom-up heapsort variant
Date: Thu, 21 Feb 2019 08:21:42 +0000 [thread overview]
Message-ID: <dbac34c6052fc973fb55df4966981bae24c7cce9.1552097842.git.lkml@sdf.org> (raw)
In-Reply-To: <cover.1552097842.git.lkml@sdf.org>
This uses fewer comparisons than the previous code (61% as
many for large random inputs), but produces identical results;
it actually performs the exact same series of swap operations.
Standard heapsort, when sifting down, performs two comparisons
per level: One to find the greater child, and a second to see
if the current node should be exchanged with that child.
Bottom-up heapsort observes that it's better to postpone the second
comparison and search for the leaf where -infinity would be sent to,
then search back *up* for the current node's destination.
Since sifting down usually proceeds to the leaf level (that's where
half the nodes are), this does many fewer second comparisons. That
saves a lot of (expensive since Spectre) indirect function calls.
The one time it's worse than the previous code is if there are large
numbers of duplicate keys, when the top-down algorithm is O(n) and
bottom-up is O(n log n). For distinct keys, it's provably always better.
(The code is not significantly more complex. This patch also merges
the heap-building and -extracting sift-down loops, resulting in a
net code size savings.)
x86-64 code size 885 -> 770 bytes (-115)
(I see the checkpatch complaint about "else if (n -= size)".
The alternative is significantly uglier.)
Signed-off-by: George Spelvin <lkml@sdf.org>
---
lib/sort.c | 102 +++++++++++++++++++++++++++++++++++++++--------------
1 file changed, 75 insertions(+), 27 deletions(-)
diff --git a/lib/sort.c b/lib/sort.c
index dff2ab2e196e..2aef4631e7d3 100644
--- a/lib/sort.c
+++ b/lib/sort.c
@@ -117,6 +117,32 @@ static void generic_swap(void *a, void *b, int size)
} while (n);
}
+/**
+ * parent - given the offset of the child, find the offset of the parent.
+ * @i: the offset of the heap element whose parent is sought. Non-zero.
+ * @lsbit: a precomputed 1-bit mask, equal to "size & -size"
+ * @size: size of each element
+ *
+ * In terms of array indexes, the parent of element j = i/size is simply
+ * (j-1)/2. But when working in byte offsets, we can't use implicit
+ * truncation of integer divides.
+ *
+ * Fortunately, we only need one bit of the quotient, not the full divide.
+ * size has a least significant bit. That bit will be clear if i is
+ * an even multiple of size, and set if it's an odd multiple.
+ *
+ * Logically, we're doing "if (i & lsbit) i -= size;", but since the
+ * branch is unpredictable, it's done with a bit of clever branch-free
+ * code instead.
+ */
+__attribute_const__ __always_inline
+static size_t parent(size_t i, unsigned int lsbit, size_t size)
+{
+ i -= size;
+ i -= size & -(i & lsbit);
+ return i / 2;
+}
+
/**
* sort - sort an array of elements
* @base: pointer to data to sort
@@ -125,21 +151,26 @@ static void generic_swap(void *a, void *b, int size)
* @cmp_func: pointer to comparison function
* @swap_func: pointer to swap function or NULL
*
- * This function does a heapsort on the given array. You may provide a
- * swap_func function optimized to your element type.
+ * This function does a heapsort on the given array. You may provide a
+ * swap_func function if you need to do something more than a memory copy
+ * (e.g. fix up pointers or auxiliary data), but the built-in swap isn't
+ * usually a bottleneck.
*
* Sorting time is O(n log n) both on average and worst-case. While
* qsort is about 20% faster on average, it suffers from exploitable
* O(n*n) worst-case behavior and extra memory requirements that make
* it less suitable for kernel use.
*/
-
void sort(void *base, size_t num, size_t size,
int (*cmp_func)(const void *, const void *),
void (*swap_func)(void *, void *, int size))
{
/* pre-scale counters for performance */
- int i = (num/2 - 1) * size, n = num * size, c, r;
+ size_t n = num * size, a = (num/2) * size;
+ unsigned const lsbit = size & -size; /* Used to find parent */
+
+ if (!n)
+ return;
if (!swap_func) {
if (alignment_ok(base, size, 8))
@@ -150,30 +181,47 @@ void sort(void *base, size_t num, size_t size,
swap_func = generic_swap;
}
- /* heapify */
- for ( ; i >= 0; i -= size) {
- for (r = i; r * 2 + size < n; r = c) {
- c = r * 2 + size;
- if (c < n - size &&
- cmp_func(base + c, base + c + size) < 0)
- c += size;
- if (cmp_func(base + r, base + c) >= 0)
- break;
- swap_func(base + r, base + c, size);
- }
- }
+ /*
+ * Loop invariants:
+ * 1. elements [a,n) satisfy the heap property (compare greater than
+ * all of their children),
+ * 2. elements [n,num*size) are sorted, and
+ * 3. a <= b <= c <= d <= n (whenever they are valid).
+ */
+ for (;;) {
+ size_t b, c, d;
- /* sort */
- for (i = n - size; i > 0; i -= size) {
- swap_func(base, base + i, size);
- for (r = 0; r * 2 + size < i; r = c) {
- c = r * 2 + size;
- if (c < i - size &&
- cmp_func(base + c, base + c + size) < 0)
- c += size;
- if (cmp_func(base + r, base + c) >= 0)
- break;
- swap_func(base + r, base + c, size);
+ if (a) /* Building heap: sift down --a */
+ a -= size;
+ else if (n -= size) /* Sorting: Extract root to --n */
+ swap_func(base, base + n, size);
+ else /* Sort complete */
+ break;
+
+ /*
+ * Sift element at "a" down into heap. This is the
+ * "bottom-up" variant, which significantly reduces
+ * calls to cmp_func(): we find the sift-down path all
+ * the way to the leaves (one compare per level), then
+ * backtrack to find where to insert the target element.
+ *
+ * Because elements tend to sift down close to the leaves,
+ * this uses fewer compares than doing two per level
+ * on the way down. (A bit more than half as many on
+ * average, 3/4 worst-case.)
+ */
+ for (b = a; c = 2*b + size, (d = c + size) < n;)
+ b = cmp_func(base + c, base + d) >= 0 ? c : d;
+ if (d == n) /* Special case last leaf with no sibling */
+ b = c;
+
+ /* Now backtrack from "b" to the correct location for "a" */
+ while (b != a && cmp_func(base + a, base + b) >= 0)
+ b = parent(b, lsbit, size);
+ c = b; /* Where "a" belongs */
+ while (b != a) { /* Shift it into place */
+ b = parent(b, lsbit, size);
+ swap_func(base + b, base + c, size);
}
}
}
--
2.20.1
next prev parent reply other threads:[~2019-03-09 3:21 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-09 2:17 [PATCH 0/5] lib/sort & lib/list_sort: faster and smaller George Spelvin
2019-02-21 6:30 ` [PATCH 1/5] lib/sort: Make swap functions more generic George Spelvin
[not found] ` <20190309140653.GO9224@smile.fi.intel.com>
2019-03-09 15:53 ` lkml
2019-03-09 20:19 ` Andrey Abramov
2019-03-14 9:29 ` Andy Shevchenko
2019-03-14 10:09 ` George Spelvin
2019-03-14 10:41 ` Geert Uytterhoeven
2019-03-14 11:53 ` George Spelvin
2019-03-14 12:18 ` Andy Shevchenko
2019-03-14 19:59 ` Andrey Abramov
2019-03-15 3:35 ` George Spelvin
2019-03-15 8:27 ` Geert Uytterhoeven
2019-03-14 10:11 ` George Spelvin
2019-03-09 21:02 ` George Spelvin
2019-03-13 21:23 ` Rasmus Villemoes
2019-03-13 22:02 ` Geert Uytterhoeven
2019-03-13 23:15 ` George Spelvin
2019-02-21 8:21 ` George Spelvin [this message]
2019-03-13 22:29 ` [PATCH 2/5] lib/sort: Use more efficient bottom-up heapsort variant Rasmus Villemoes
2019-03-14 0:03 ` George Spelvin
2019-03-14 0:15 ` Rasmus Villemoes
2019-02-21 8:21 ` [PATCH 3/5] lib/sort: Avoid indirect calls to built-in swap George Spelvin
2019-03-05 3:06 ` [PATCH 4/5] lib/list_sort: Simplify and remove MAX_LIST_LENGTH_BITS George Spelvin
2019-03-10 21:54 ` Rasmus Villemoes
2019-03-10 22:29 ` George Spelvin
2019-03-14 9:10 ` Andy Shevchenko
2019-03-14 9:41 ` George Spelvin
2019-03-15 4:33 ` George Spelvin
2019-03-15 8:20 ` Geert Uytterhoeven
2019-03-15 10:23 ` George Spelvin
2019-03-15 12:57 ` Geert Uytterhoeven
2019-03-15 16:59 ` George Spelvin
2019-03-15 17:47 ` Geert Uytterhoeven
2019-03-15 18:53 ` Andrey Abramov
2019-03-15 19:06 ` Andy Shevchenko
2019-03-15 19:23 ` Andrey Abramov
2019-03-15 19:56 ` Andy Shevchenko
2019-03-16 3:49 ` George Spelvin
2019-03-05 5:58 ` [PATCH 5/5] lib/list_sort: Optimize number of calls to comparison function George Spelvin
2019-03-13 23:28 ` Rasmus Villemoes
2019-03-14 1:58 ` George Spelvin
2019-06-21 23:12 ` Rasmus Villemoes
2019-12-08 8:01 ` George Spelvin
2019-03-15 19:54 ` [PATCH 0/5] lib/sort & lib/list_sort: faster and smaller Andrey Abramov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dbac34c6052fc973fb55df4966981bae24c7cce9.1552097842.git.lkml@sdf.org \
--to=lkml@sdf.org \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=daniel.wagner@siemens.com \
--cc=dchinner@redhat.com \
--cc=don.mullis@gmail.com \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=st5pub@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).