these additions were made by scanning git log since the last major
update in commit 1366b3c5e6.
as before my aim was adding everyone with either substantial code
contributions or a pattern of ongoing simple patch submission; any
omissions are unintentional.
Rewrote the AVL tree implementation:
- It is now non-recursive with fixed stack usage (large enough for
worst case tree height). twalk and tdestroy are still recursive as
that's smaller/simpler.
- Moved unrelated interfaces into separate translation units.
- The node structure is changed to use indexed children instead of
left/right pointers, this simplifies the balancing logic.
- Using void * pointers instead of struct node * in various places,
because this better fits the api (node address is passed in a void**
argument, so it is tempting to incorrectly cast it to struct node **).
- As a further performance improvement the rebalancing now stops
when it is not needed (subtree height is unchanged). Otherwise
the behaviour should be the same as before (checked over generated
random inputs that the resulting tree shape is equivalent).
- Removed the old copyright notice (including prng related one: it
should be licensed under the same terms as the rest of the project).
.text size of pic tsearch + tfind + tdelete + twalk:
x86_64 i386 aarch64 arm mips powerpc ppc64le sh4 m68k s390x
old 941 899 1220 1068 1852 1400 1600 1008 1008 1488
new 857 881 1040 976 1564 1192 1360 736 820 1408
these additions were made by scanning git log since the last major
update in commit 790580b2fc. in addition
to git-level commit authorship, "patch by" text in the commit message
was also scanned. this idiom was used in the past for patches that
underwent substantial edits when merging or where the author did not
provide a commit message. going forward, my intent is to use commit
authorship consistently for attribution.
as before my aim was adding everyone with either substantial code
contributions or a pattern of ongoing simple patch submission; any
omissions are unintentional.
these changes are the outcome of a long mailing list thread that took
place March 2016, "musl licensing". among minor other issues,
prospective users were not confident that the whole-project MIT
license would grant permission for files to which the COPYRIGHT file
expressed a belief that copyright not apply, if it turned out that
these files were actually subject to copyright.
in accordance with the original intent of applying a permissive
license to the project, which was that license issues not be an
obstacle to use, the text which was causing confusion is removed. no
new claims of copyright are made, but new text is added to clarify
that the grant of permissions applies to all files, and an explicit
grant of permission to use public headers and crt files without
attribution has been made.
this patch was reviewed and approved by all substantial contributors
to the affected files: Bobby Bingham, John Spencer (rofl0r), Nicholas
J. Kain, Rich Felker, Richard Pennington, Stefan Kristiansson, and
Szabolcs Nagy.
these additions were made based on scanning commit authors since the
last update, at the time of the 1.1.7 release, and adding everyone
with either substantial code contributions or a pattern of ongoing
simple patch submission.
the approach of this implementation was heavily investigated prior to
adopting it. attempts to obtain similar performance with pure C code
were capping out at about 75% of the performance of the asm, with
considerably larger code size, and were fragile in that the compiler
would sometimes compile part of memcpy into a call to itself.
therefore, just using the asm seems to be the best option.
this commit is the first to make use of the new subarch-specific asm
framework. the new armel directory is the location for arm asm that
should not be used for all arm subarchs, only the default one. armhf
is the name of the little-endian hardfloat-ABI subarch, which can use
the exact same asm. in both cases, the build system finds the asm by
following a memcpy.sub file.
the other two subarchs, armeb and armebhf, would need a big-endian
variant of this code. it would not be hard to adapt the code to big
endian, but I will hold off on doing so until there is demand for it.
these changes are based on the following communication via email:
"I hereby grant that all of the code I have contributed to musl on or
before April 23, 2012 may be licensed under the terms of the following
MIT license:
Copyright (c) 2011-2012 Nicholas J. Kain
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
Smoothsort is an adaptive variant of heapsort. This version was
written by Valentin Ochs (apo) specifically for inclusion in musl. I
worked with him to get it working in O(1) memory usage even with giant
array element widths, and to optimize it heavily for size and speed.
It's still roughly 4 times as large as the old heap sort
implementation, but roughly 20 times faster given an almost-sorted
array of 1M elements (20 being the base-2 log of 1M), i.e. it really
does reduce O(n log n) to O(n) in the mostly-sorted case. It's still
somewhat slower than glibc's Introsort for random input, but now
considerably faster than glibc when the input is already sorted, or
mostly sorted.
