2020-06-15 14:18:57 +00:00
|
|
|
/*-*- mode:c;indent-tabs-mode:nil;c-basic-offset:2;tab-width:8;coding:utf-8 -*-│
|
2023-12-08 03:11:56 +00:00
|
|
|
│ vi: set et ft=c ts=2 sts=2 sw=2 fenc=utf-8 :vi │
|
2020-06-15 14:18:57 +00:00
|
|
|
╞══════════════════════════════════════════════════════════════════════════════╡
|
|
|
|
│ Copyright 2020 Justine Alexandra Roberts Tunney │
|
|
|
|
│ │
|
2020-12-28 01:18:44 +00:00
|
|
|
│ Permission to use, copy, modify, and/or distribute this software for │
|
|
|
|
│ any purpose with or without fee is hereby granted, provided that the │
|
|
|
|
│ above copyright notice and this permission notice appear in all copies. │
|
2020-06-15 14:18:57 +00:00
|
|
|
│ │
|
2020-12-28 01:18:44 +00:00
|
|
|
│ THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL │
|
|
|
|
│ WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED │
|
|
|
|
│ WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE │
|
|
|
|
│ AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL │
|
|
|
|
│ DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR │
|
|
|
|
│ PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER │
|
|
|
|
│ TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR │
|
|
|
|
│ PERFORMANCE OF THIS SOFTWARE. │
|
2020-06-15 14:18:57 +00:00
|
|
|
╚─────────────────────────────────────────────────────────────────────────────*/
|
2021-03-01 07:42:35 +00:00
|
|
|
#include "libc/macros.internal.h"
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
#include "libc/mem/alg.h"
|
2022-09-13 06:10:38 +00:00
|
|
|
#include "libc/mem/gc.h"
|
2024-01-08 18:07:35 +00:00
|
|
|
#include "libc/mem/gc.h"
|
2021-02-01 11:33:13 +00:00
|
|
|
#include "libc/mem/mem.h"
|
2022-09-08 13:06:22 +00:00
|
|
|
#include "libc/runtime/runtime.h"
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
#include "libc/stdio/rand.h"
|
|
|
|
#include "libc/stdio/stdio.h"
|
2020-06-15 14:18:57 +00:00
|
|
|
#include "libc/str/str.h"
|
2021-10-04 10:23:31 +00:00
|
|
|
#include "libc/testlib/ezbench.h"
|
2020-06-15 14:18:57 +00:00
|
|
|
#include "libc/testlib/testlib.h"
|
|
|
|
|
2023-07-10 11:29:46 +00:00
|
|
|
int CompareLow(const void *a, const void *b) {
|
|
|
|
const int *x = a;
|
|
|
|
const int *y = b;
|
Apply clang-format update to repo (#1154)
Commit bc6c183 introduced a bunch of discrepancies between what files
look like in the repo and what clang-format says they should look like.
However, there were already a few discrepancies prior to that. Most of
these discrepancies seemed to be unintentional, but a few of them were
load-bearing (e.g., a #include that violated header ordering needing
something to have been #defined by a 'later' #include.)
I opted to take what I hope is a relatively smooth-brained approach: I
reverted the .clang-format change, ran clang-format on the whole repo,
reapplied the .clang-format change, reran clang-format again, and then
reverted the commit that contained the first run. Thus the full effect
of this PR should only be to apply the changed formatting rules to the
repo, and from skimming the results, this seems to be the case.
My work can be checked by applying the short, manual commits, and then
rerunning the command listed in the autogenerated commits (those whose
messages I have prefixed auto:) and seeing if your results agree.
It might be that the other diffs should be fixed at some point but I'm
leaving that aside for now.
fd '\.c(c|pp)?$' --print0| xargs -0 clang-format -i
2024-04-25 17:38:00 +00:00
|
|
|
if ((char)*x < (char)*y)
|
|
|
|
return -1;
|
|
|
|
if ((char)*x > (char)*y)
|
|
|
|
return +1;
|
2023-07-10 11:29:46 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void InsertionSortLow(int *A, int n) {
|
|
|
|
int i, j, t;
|
|
|
|
for (i = 1; i < n; i++) {
|
|
|
|
t = A[i];
|
|
|
|
j = i - 1;
|
|
|
|
while (j >= 0 && (char)A[j] > (char)t) {
|
|
|
|
A[j + 1] = A[j];
|
|
|
|
j = j - 1;
|
|
|
|
}
|
|
|
|
A[j + 1] = t;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool IsStableSort(void sort(void *, size_t, size_t,
|
|
|
|
int (*)(const void *, const void *))) {
|
|
|
|
int n = 256;
|
|
|
|
int *A = gc(malloc(n * sizeof(int)));
|
|
|
|
int *B = gc(malloc(n * sizeof(int)));
|
|
|
|
rngset(A, n * sizeof(int), 0, 0);
|
|
|
|
memcpy(B, A, n * sizeof(int));
|
|
|
|
InsertionSortLow(A, n);
|
|
|
|
sort(B, n, sizeof(int), CompareLow);
|
|
|
|
return !memcmp(A, B, n * sizeof(int));
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(sort, stability) {
|
|
|
|
ASSERT_FALSE(IsStableSort(qsort));
|
|
|
|
ASSERT_FALSE(IsStableSort(smoothsort));
|
|
|
|
ASSERT_FALSE(IsStableSort((void *)qsort_r));
|
|
|
|
ASSERT_FALSE(IsStableSort((void *)heapsort));
|
|
|
|
ASSERT_TRUE(IsStableSort((void *)mergesort));
|
|
|
|
}
|
|
|
|
|
2022-09-13 06:10:38 +00:00
|
|
|
int CompareInt(const void *a, const void *b) {
|
|
|
|
const int *x = a;
|
|
|
|
const int *y = b;
|
Apply clang-format update to repo (#1154)
Commit bc6c183 introduced a bunch of discrepancies between what files
look like in the repo and what clang-format says they should look like.
However, there were already a few discrepancies prior to that. Most of
these discrepancies seemed to be unintentional, but a few of them were
load-bearing (e.g., a #include that violated header ordering needing
something to have been #defined by a 'later' #include.)
I opted to take what I hope is a relatively smooth-brained approach: I
reverted the .clang-format change, ran clang-format on the whole repo,
reapplied the .clang-format change, reran clang-format again, and then
reverted the commit that contained the first run. Thus the full effect
of this PR should only be to apply the changed formatting rules to the
repo, and from skimming the results, this seems to be the case.
My work can be checked by applying the short, manual commits, and then
rerunning the command listed in the autogenerated commits (those whose
messages I have prefixed auto:) and seeing if your results agree.
It might be that the other diffs should be fixed at some point but I'm
leaving that aside for now.
fd '\.c(c|pp)?$' --print0| xargs -0 clang-format -i
2024-04-25 17:38:00 +00:00
|
|
|
if (*x < *y)
|
|
|
|
return -1;
|
|
|
|
if (*x > *y)
|
|
|
|
return +1;
|
2022-09-13 06:10:38 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-10-04 10:23:31 +00:00
|
|
|
int CompareLong(const void *a, const void *b) {
|
|
|
|
const long *x = a;
|
|
|
|
const long *y = b;
|
Apply clang-format update to repo (#1154)
Commit bc6c183 introduced a bunch of discrepancies between what files
look like in the repo and what clang-format says they should look like.
However, there were already a few discrepancies prior to that. Most of
these discrepancies seemed to be unintentional, but a few of them were
load-bearing (e.g., a #include that violated header ordering needing
something to have been #defined by a 'later' #include.)
I opted to take what I hope is a relatively smooth-brained approach: I
reverted the .clang-format change, ran clang-format on the whole repo,
reapplied the .clang-format change, reran clang-format again, and then
reverted the commit that contained the first run. Thus the full effect
of this PR should only be to apply the changed formatting rules to the
repo, and from skimming the results, this seems to be the case.
My work can be checked by applying the short, manual commits, and then
rerunning the command listed in the autogenerated commits (those whose
messages I have prefixed auto:) and seeing if your results agree.
It might be that the other diffs should be fixed at some point but I'm
leaving that aside for now.
fd '\.c(c|pp)?$' --print0| xargs -0 clang-format -i
2024-04-25 17:38:00 +00:00
|
|
|
if (*x < *y)
|
|
|
|
return -1;
|
|
|
|
if (*x > *y)
|
|
|
|
return +1;
|
2021-10-04 10:23:31 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-07-10 11:29:46 +00:00
|
|
|
TEST(qsort, words) {
|
2020-06-15 14:18:57 +00:00
|
|
|
const int32_t A[][2] = {{4, 'a'}, {65, 'b'}, {2, 'c'}, {-31, 'd'},
|
|
|
|
{0, 'e'}, {99, 'f'}, {2, 'g'}, {83, 'h'},
|
|
|
|
{782, 'i'}, {1, 'j'}};
|
|
|
|
const int32_t B[][2] = {{-31, 'd'}, {0, 'e'}, {1, 'j'}, {2, 'c'},
|
|
|
|
{2, 'g'}, {4, 'a'}, {65, 'b'}, {83, 'h'},
|
|
|
|
{99, 'f'}, {782, 'i'}};
|
2021-02-01 11:33:13 +00:00
|
|
|
int32_t(*M)[2] = malloc(sizeof(A));
|
2020-06-15 14:18:57 +00:00
|
|
|
memcpy(M, B, sizeof(A));
|
2022-09-13 06:10:38 +00:00
|
|
|
qsort(M, ARRAYLEN(A), sizeof(*M), CompareInt);
|
2020-06-15 14:18:57 +00:00
|
|
|
EXPECT_EQ(0, memcmp(M, B, sizeof(B)));
|
2021-02-01 11:33:13 +00:00
|
|
|
free(M);
|
2020-06-15 14:18:57 +00:00
|
|
|
}
|
2021-10-04 10:23:31 +00:00
|
|
|
|
2023-07-10 11:29:46 +00:00
|
|
|
struct Record {
|
|
|
|
int x;
|
|
|
|
int y;
|
|
|
|
int z;
|
|
|
|
int a[2];
|
|
|
|
int b;
|
|
|
|
};
|
|
|
|
|
|
|
|
int CompareRecord(const void *a, const void *b) {
|
|
|
|
const struct Record *x = a;
|
|
|
|
const struct Record *y = b;
|
Apply clang-format update to repo (#1154)
Commit bc6c183 introduced a bunch of discrepancies between what files
look like in the repo and what clang-format says they should look like.
However, there were already a few discrepancies prior to that. Most of
these discrepancies seemed to be unintentional, but a few of them were
load-bearing (e.g., a #include that violated header ordering needing
something to have been #defined by a 'later' #include.)
I opted to take what I hope is a relatively smooth-brained approach: I
reverted the .clang-format change, ran clang-format on the whole repo,
reapplied the .clang-format change, reran clang-format again, and then
reverted the commit that contained the first run. Thus the full effect
of this PR should only be to apply the changed formatting rules to the
repo, and from skimming the results, this seems to be the case.
My work can be checked by applying the short, manual commits, and then
rerunning the command listed in the autogenerated commits (those whose
messages I have prefixed auto:) and seeing if your results agree.
It might be that the other diffs should be fixed at some point but I'm
leaving that aside for now.
fd '\.c(c|pp)?$' --print0| xargs -0 clang-format -i
2024-04-25 17:38:00 +00:00
|
|
|
if (x->z > y->z)
|
|
|
|
return -1;
|
|
|
|
if (x->z < y->z)
|
|
|
|
return +1;
|
2023-07-10 11:29:46 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(qsort, records) {
|
|
|
|
int i, n = 256;
|
|
|
|
struct Record *A = gc(calloc(n, sizeof(struct Record)));
|
|
|
|
struct Record *B = gc(calloc(n, sizeof(struct Record)));
|
Apply clang-format update to repo (#1154)
Commit bc6c183 introduced a bunch of discrepancies between what files
look like in the repo and what clang-format says they should look like.
However, there were already a few discrepancies prior to that. Most of
these discrepancies seemed to be unintentional, but a few of them were
load-bearing (e.g., a #include that violated header ordering needing
something to have been #defined by a 'later' #include.)
I opted to take what I hope is a relatively smooth-brained approach: I
reverted the .clang-format change, ran clang-format on the whole repo,
reapplied the .clang-format change, reran clang-format again, and then
reverted the commit that contained the first run. Thus the full effect
of this PR should only be to apply the changed formatting rules to the
repo, and from skimming the results, this seems to be the case.
My work can be checked by applying the short, manual commits, and then
rerunning the command listed in the autogenerated commits (those whose
messages I have prefixed auto:) and seeing if your results agree.
It might be that the other diffs should be fixed at some point but I'm
leaving that aside for now.
fd '\.c(c|pp)?$' --print0| xargs -0 clang-format -i
2024-04-25 17:38:00 +00:00
|
|
|
for (i = 0; i < n; ++i)
|
|
|
|
A[i].z = B[i].z = lemur64();
|
2023-07-10 11:29:46 +00:00
|
|
|
qsort(A, n, sizeof(struct Record), CompareRecord);
|
|
|
|
mergesort(B, n, sizeof(struct Record), CompareRecord);
|
|
|
|
ASSERT_EQ(0, memcmp(A, B, n * sizeof(struct Record)));
|
|
|
|
}
|
|
|
|
|
2022-09-07 12:23:44 +00:00
|
|
|
TEST(qsort, equivalence_random) {
|
2022-09-07 00:52:26 +00:00
|
|
|
size_t i;
|
|
|
|
size_t n = 1000;
|
2023-07-10 11:29:46 +00:00
|
|
|
long *a = gc(malloc(n * sizeof(long)));
|
|
|
|
long *b = gc(malloc(n * sizeof(long)));
|
|
|
|
long *c = gc(malloc(n * sizeof(long)));
|
Apply clang-format update to repo (#1154)
Commit bc6c183 introduced a bunch of discrepancies between what files
look like in the repo and what clang-format says they should look like.
However, there were already a few discrepancies prior to that. Most of
these discrepancies seemed to be unintentional, but a few of them were
load-bearing (e.g., a #include that violated header ordering needing
something to have been #defined by a 'later' #include.)
I opted to take what I hope is a relatively smooth-brained approach: I
reverted the .clang-format change, ran clang-format on the whole repo,
reapplied the .clang-format change, reran clang-format again, and then
reverted the commit that contained the first run. Thus the full effect
of this PR should only be to apply the changed formatting rules to the
repo, and from skimming the results, this seems to be the case.
My work can be checked by applying the short, manual commits, and then
rerunning the command listed in the autogenerated commits (those whose
messages I have prefixed auto:) and seeing if your results agree.
It might be that the other diffs should be fixed at some point but I'm
leaving that aside for now.
fd '\.c(c|pp)?$' --print0| xargs -0 clang-format -i
2024-04-25 17:38:00 +00:00
|
|
|
for (i = 0; i < n; ++i)
|
|
|
|
a[i] = lemur64();
|
2022-09-07 00:52:26 +00:00
|
|
|
memcpy(b, a, n * sizeof(long));
|
|
|
|
memcpy(c, a, n * sizeof(long));
|
|
|
|
qsort(b, n, sizeof(long), CompareLong);
|
|
|
|
heapsort(c, n, sizeof(long), CompareLong);
|
|
|
|
ASSERT_EQ(0, memcmp(b, c, n * sizeof(long)));
|
2022-09-08 13:06:22 +00:00
|
|
|
memcpy(c, a, n * sizeof(long));
|
2022-09-07 00:52:26 +00:00
|
|
|
mergesort(c, n, sizeof(long), CompareLong);
|
|
|
|
ASSERT_EQ(0, memcmp(b, c, n * sizeof(long)));
|
2022-09-08 13:06:22 +00:00
|
|
|
memcpy(c, a, n * sizeof(long));
|
2022-09-07 00:52:26 +00:00
|
|
|
smoothsort(c, n, sizeof(long), CompareLong);
|
|
|
|
ASSERT_EQ(0, memcmp(b, c, n * sizeof(long)));
|
2022-09-08 13:06:22 +00:00
|
|
|
memcpy(c, a, n * sizeof(long));
|
2022-09-13 06:10:38 +00:00
|
|
|
_longsort(c, n);
|
2022-09-08 13:06:22 +00:00
|
|
|
ASSERT_EQ(0, memcmp(b, c, n * sizeof(long)));
|
2022-09-07 00:52:26 +00:00
|
|
|
}
|
|
|
|
|
2022-09-07 12:23:44 +00:00
|
|
|
TEST(qsort, equivalence_reverse) {
|
2022-09-07 00:52:26 +00:00
|
|
|
size_t i;
|
|
|
|
size_t n = 1000;
|
2023-07-10 11:29:46 +00:00
|
|
|
long *a = gc(malloc(n * sizeof(long)));
|
|
|
|
long *b = gc(malloc(n * sizeof(long)));
|
|
|
|
long *c = gc(malloc(n * sizeof(long)));
|
Apply clang-format update to repo (#1154)
Commit bc6c183 introduced a bunch of discrepancies between what files
look like in the repo and what clang-format says they should look like.
However, there were already a few discrepancies prior to that. Most of
these discrepancies seemed to be unintentional, but a few of them were
load-bearing (e.g., a #include that violated header ordering needing
something to have been #defined by a 'later' #include.)
I opted to take what I hope is a relatively smooth-brained approach: I
reverted the .clang-format change, ran clang-format on the whole repo,
reapplied the .clang-format change, reran clang-format again, and then
reverted the commit that contained the first run. Thus the full effect
of this PR should only be to apply the changed formatting rules to the
repo, and from skimming the results, this seems to be the case.
My work can be checked by applying the short, manual commits, and then
rerunning the command listed in the autogenerated commits (those whose
messages I have prefixed auto:) and seeing if your results agree.
It might be that the other diffs should be fixed at some point but I'm
leaving that aside for now.
fd '\.c(c|pp)?$' --print0| xargs -0 clang-format -i
2024-04-25 17:38:00 +00:00
|
|
|
for (i = 0; i < n; ++i)
|
|
|
|
a[n - i - 1] = i;
|
2022-09-07 00:52:26 +00:00
|
|
|
memcpy(b, a, n * sizeof(long));
|
|
|
|
memcpy(c, a, n * sizeof(long));
|
|
|
|
qsort(b, n, sizeof(long), CompareLong);
|
|
|
|
heapsort(c, n, sizeof(long), CompareLong);
|
|
|
|
ASSERT_EQ(0, memcmp(b, c, n * sizeof(long)));
|
2022-09-08 13:06:22 +00:00
|
|
|
memcpy(c, a, n * sizeof(long));
|
2022-09-07 00:52:26 +00:00
|
|
|
mergesort(c, n, sizeof(long), CompareLong);
|
|
|
|
ASSERT_EQ(0, memcmp(b, c, n * sizeof(long)));
|
2022-09-08 13:06:22 +00:00
|
|
|
memcpy(c, a, n * sizeof(long));
|
2022-09-07 00:52:26 +00:00
|
|
|
smoothsort(c, n, sizeof(long), CompareLong);
|
|
|
|
ASSERT_EQ(0, memcmp(b, c, n * sizeof(long)));
|
2022-09-08 13:06:22 +00:00
|
|
|
memcpy(c, a, n * sizeof(long));
|
2022-09-13 06:10:38 +00:00
|
|
|
_longsort(c, n);
|
2022-09-08 13:06:22 +00:00
|
|
|
ASSERT_EQ(0, memcmp(b, c, n * sizeof(long)));
|
2022-09-07 00:52:26 +00:00
|
|
|
}
|
|
|
|
|
2021-10-04 10:23:31 +00:00
|
|
|
BENCH(qsort, bench) {
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
size_t i;
|
2021-10-04 10:23:31 +00:00
|
|
|
size_t n = 1000;
|
2023-07-10 11:29:46 +00:00
|
|
|
long *p1 = gc(malloc(n * sizeof(long)));
|
|
|
|
long *p2 = gc(malloc(n * sizeof(long)));
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
|
|
|
|
printf("\n");
|
Apply clang-format update to repo (#1154)
Commit bc6c183 introduced a bunch of discrepancies between what files
look like in the repo and what clang-format says they should look like.
However, there were already a few discrepancies prior to that. Most of
these discrepancies seemed to be unintentional, but a few of them were
load-bearing (e.g., a #include that violated header ordering needing
something to have been #defined by a 'later' #include.)
I opted to take what I hope is a relatively smooth-brained approach: I
reverted the .clang-format change, ran clang-format on the whole repo,
reapplied the .clang-format change, reran clang-format again, and then
reverted the commit that contained the first run. Thus the full effect
of this PR should only be to apply the changed formatting rules to the
repo, and from skimming the results, this seems to be the case.
My work can be checked by applying the short, manual commits, and then
rerunning the command listed in the autogenerated commits (those whose
messages I have prefixed auto:) and seeing if your results agree.
It might be that the other diffs should be fixed at some point but I'm
leaving that aside for now.
fd '\.c(c|pp)?$' --print0| xargs -0 clang-format -i
2024-04-25 17:38:00 +00:00
|
|
|
for (i = 0; i < n; ++i)
|
|
|
|
p1[i] = i + ((lemur64() % 3) - 1);
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
EZBENCH2("qsort nearly", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
qsort(p2, n, sizeof(long), CompareLong));
|
2023-07-10 11:29:46 +00:00
|
|
|
EZBENCH2("qsort_r nearly", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
qsort_r(p2, n, sizeof(long), (void *)CompareLong, 0));
|
2022-09-07 00:52:26 +00:00
|
|
|
EZBENCH2("heapsort nearly", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
heapsort(p2, n, sizeof(long), CompareLong));
|
|
|
|
EZBENCH2("mergesort nearly", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
mergesort(p2, n, sizeof(long), CompareLong));
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
EZBENCH2("smoothsort nearly", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
smoothsort(p2, n, sizeof(long), CompareLong));
|
2022-09-13 06:10:38 +00:00
|
|
|
EZBENCH2("_longsort nearly", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
_longsort(p2, n));
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
|
|
|
|
printf("\n");
|
Apply clang-format update to repo (#1154)
Commit bc6c183 introduced a bunch of discrepancies between what files
look like in the repo and what clang-format says they should look like.
However, there were already a few discrepancies prior to that. Most of
these discrepancies seemed to be unintentional, but a few of them were
load-bearing (e.g., a #include that violated header ordering needing
something to have been #defined by a 'later' #include.)
I opted to take what I hope is a relatively smooth-brained approach: I
reverted the .clang-format change, ran clang-format on the whole repo,
reapplied the .clang-format change, reran clang-format again, and then
reverted the commit that contained the first run. Thus the full effect
of this PR should only be to apply the changed formatting rules to the
repo, and from skimming the results, this seems to be the case.
My work can be checked by applying the short, manual commits, and then
rerunning the command listed in the autogenerated commits (those whose
messages I have prefixed auto:) and seeing if your results agree.
It might be that the other diffs should be fixed at some point but I'm
leaving that aside for now.
fd '\.c(c|pp)?$' --print0| xargs -0 clang-format -i
2024-04-25 17:38:00 +00:00
|
|
|
for (i = 0; i < n; ++i)
|
|
|
|
p1[i] = n - i;
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
EZBENCH2("qsort reverse", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
qsort(p2, n, sizeof(long), CompareLong));
|
2023-07-10 11:29:46 +00:00
|
|
|
EZBENCH2("qsort_r reverse", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
qsort_r(p2, n, sizeof(long), (void *)CompareLong, 0));
|
2022-09-07 00:52:26 +00:00
|
|
|
EZBENCH2("heapsort reverse", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
heapsort(p2, n, sizeof(long), CompareLong));
|
|
|
|
EZBENCH2("mergesort reverse", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
mergesort(p2, n, sizeof(long), CompareLong));
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
EZBENCH2("smoothsort reverse", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
smoothsort(p2, n, sizeof(long), CompareLong));
|
2022-09-13 06:10:38 +00:00
|
|
|
EZBENCH2("_longsort reverse", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
_longsort(p2, n));
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
|
|
|
|
printf("\n");
|
2021-10-04 10:23:31 +00:00
|
|
|
rngset(p1, n * sizeof(long), 0, 0);
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
EZBENCH2("qsort random", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
qsort(p2, n, sizeof(long), CompareLong));
|
2023-07-10 11:29:46 +00:00
|
|
|
EZBENCH2("qsort_r random", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
qsort_r(p2, n, sizeof(long), (void *)CompareLong, 0));
|
2022-09-07 00:52:26 +00:00
|
|
|
EZBENCH2("heapsort random", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
heapsort(p2, n, sizeof(long), CompareLong));
|
|
|
|
EZBENCH2("mergesort random", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
mergesort(p2, n, sizeof(long), CompareLong));
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
EZBENCH2("smoothsort random", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
smoothsort(p2, n, sizeof(long), CompareLong));
|
2022-09-13 06:10:38 +00:00
|
|
|
EZBENCH2("_longsort random", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
_longsort(p2, n));
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
|
|
|
|
printf("\n");
|
|
|
|
for (i = 0; i < n / 2; ++i) {
|
|
|
|
p1[i] = i;
|
|
|
|
p1[n - i - 1] = i;
|
|
|
|
}
|
|
|
|
EZBENCH2("qsort 2n", memcpy(p2, p1, n * sizeof(long)),
|
2021-10-04 10:23:31 +00:00
|
|
|
qsort(p2, n, sizeof(long), CompareLong));
|
2023-07-10 11:29:46 +00:00
|
|
|
EZBENCH2("qsort_r 2n", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
qsort_r(p2, n, sizeof(long), (void *)CompareLong, 0));
|
2022-09-07 00:52:26 +00:00
|
|
|
EZBENCH2("heapsort 2n", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
heapsort(p2, n, sizeof(long), CompareLong));
|
|
|
|
EZBENCH2("mergesort 2n", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
mergesort(p2, n, sizeof(long), CompareLong));
|
Use a better sorting algorithm
This change changes qsort() to use the same code as NetBSD and MacOS
because it goes 6x faster than Musl's SmoothSort function. Smoothsort
can still be used if you need something that's provenly linearithmic.
This change also improves GNU Make performance on whole by 7 percent!
netbsd nearly l: 70,196c 22,673ns m: 68,428c 22,102ns
musl nearly l: 53,844c 17,391ns m: 58,726c 18,968ns
unixv6 nearly l: 65,885c 21,280ns m: 63,082c 20,375ns
netbsd reverse l: 120,290c 38,853ns m: 122,619c 39,605ns
musl reverse l: 801,826c 258,985ns m: 794,689c 256,680ns
unixv6 reverse l: 58,977c 19,049ns m: 59,764c 19,303ns
netbsd random l: 146,745c 47,398ns m: 145,782c 47,087ns
musl random l: 855,804c 276,420ns m: 850,912c 274,840ns
unixv6 random l: 214,325c 69,226ns m: 213,906c 69,090ns
netbsd 2n l: 77,299c 24,967ns m: 76,773c 24,797ns
musl 2n l: 818,012c 264,213ns m: 818,282c 264,301ns
unixv6 2n l: 3,967,009c 1,281,322ns m: 3,941,792c 1,273,177ns
https://justine.lol/dox/sort.pdf
2022-09-06 18:04:29 +00:00
|
|
|
EZBENCH2("smoothsort 2n", memcpy(p2, p1, n * sizeof(long)),
|
|
|
|
smoothsort(p2, n, sizeof(long), CompareLong));
|
2022-09-13 06:10:38 +00:00
|
|
|
EZBENCH2("_longsort 2n", memcpy(p2, p1, n * sizeof(long)), _longsort(p2, n));
|
2021-10-04 10:23:31 +00:00
|
|
|
}
|