threads / patch / 11903

v2compat: Add simplified merge sort implementation from glibc

Subject: [PATCH v2] compat: Add simplified merge sort implementation from glibc

## tl;dr

17 messages between Feb 5, 2008 and Feb 11, 2008. Diffs are folded; open one to read it.

replies: 16people: 10as markdown or json

Brian Downing· Feb 5, 2008, 21:10 UTC · lore

qsort in Windows 2000 (and various other C libraries) is a Quicksort with the usual O(n^2) worst case. Unfortunately, sorting Git trees seems to get very close to that worst case quite often:

    $ /git/gitbad runstatus
    # On branch master
    qsort, nmemb = 30842
    done, 237838087 comparisons.

This patch adds a simplified version of the merge sort that is glibc's qsort(3). As a merge sort, this needs a temporary array equal in size to the array that is to be sorted, but has a worst-case performance of O(n log n).

The complexity that was removed is:
* Doing direct stores for word-size and -aligned data.
* Falling back to quicksort if the allocation required to perform the
  merge sort would likely push the machine into swap.

Even with these simplifications, this seems to outperform the Windows qsort(3) implementation, even in Windows XP (where it is "fixed" and doesn't trigger O(n^2) complexity on trees).

[jes: moved into compat/qsort.c, as per Johannes Sixt's suggestion]
[bcd: removed gcc-ism, thanks to Edgar Toernig.  renamed make variable
      per Junio's comment.]
Signed-off-by: Brian Downing <bdowning-oU/tDdhfGLReoWH0uzbU5w@public.gmane.org>
Signed-off-by: Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin-Mmb7MZpHnFY@public.gmane.org>
---
    Here it is again.  Sorry about the mail screwup.
    -bcd
 Makefile          |    9 ++++++++
 compat/qsort.c    |   60 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 git-compat-util.h |    6 +++++
 3 files changed, 75 insertions(+), 0 deletions(-)
 create mode 100644 compat/qsort.c
Show changes to 3 files +75 −0

Makefile, compat/qsort.c, git-compat-util.h

diff --git a/Makefile b/Makefile
index 92341c4..a0e5c0c 100644
--- a/Makefile
+++ b/Makefile
@@ -137,6 +137,11 @@ all::
 # Define THREADED_DELTA_SEARCH if you have pthreads and wish to exploit
 # parallel delta searching when packing objects.
 #
+# Define INTERNAL_QSORT to use Git's implementation of qsort(), which
+# is a simplified version of the merge sort used in glibc. This is
+# recommended if Git triggers O(n^2) complexity in your
+# implementation's qsort().
+#
 
 GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
 	@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -722,6 +727,10 @@ ifdef NO_MEMMEM
 	COMPAT_CFLAGS += -DNO_MEMMEM
 	COMPAT_OBJS += compat/memmem.o
 endif
+ifdef INTERNAL_QSORT
+	COMPAT_CFLAGS += -DINTERNAL_QSORT
+	COMPAT_OBJS += compat/qsort.o
+endif
 
 ifdef THREADED_DELTA_SEARCH
 	BASIC_CFLAGS += -DTHREADED_DELTA_SEARCH
diff --git a/compat/qsort.c b/compat/qsort.c
new file mode 100644
index 0000000..8663889
--- /dev/null
+++ b/compat/qsort.c
@@ -0,0 +1,60 @@
+#include "../git-compat-util.h"
+
+/* This merge sort implementation is simplified from glibc's. */
+static void msort_with_tmp(void *b, size_t n, size_t s,
+			   int (*cmp)(const void *, const void *),
+			   char *t)
+{
+	char *tmp;
+	char *b1, *b2;
+	size_t n1, n2;
+
+	if (n <= 1)
+		return;
+
+	n1 = n / 2;
+	n2 = n - n1;
+	b1 = b;
+	b2 = (char *)b + (n1 * s);
+
+	msort_with_tmp(b1, n1, s, cmp, t);
+	msort_with_tmp(b2, n2, s, cmp, t);
+
+	tmp = t;
+
+	while (n1 > 0 && n2 > 0) {
+		if (cmp(b1, b2) <= 0) {
+			memcpy(tmp, b1, s);
+			tmp += s;
+			b1 += s;
+			--n1;
+		} else {
+			memcpy(tmp, b2, s);
+			tmp += s;
+			b2 += s;
+			--n2;
+		}
+	}
+	if (n1 > 0)
+		memcpy(tmp, b1, n1 * s);
+	memcpy(b, t, (n - n2) * s);
+}
+
+void git_qsort(void *b, size_t n, size_t s,
+	       int (*cmp)(const void *, const void *))
+{
+	const size_t size = n * s;
+
+	if (size < 1024) {
+		char buf[1024];
+
+		/* The temporary array is small, so put it on
+		   the stack.  */
+		msort_with_tmp(b, n, s, cmp, buf);
+	} else {
+		/* It's somewhat large, so malloc it.  */
+		char *tmp = malloc(size);
+		msort_with_tmp(b, n, s, cmp, tmp);
+		free(tmp);
+	}
+}
diff --git a/git-compat-util.h b/git-compat-util.h
index 4df90cb..0514604 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -426,4 +426,10 @@ static inline int strtol_i(char const *s, int base, int *result)
 	return 0;
 }
 
+#ifdef INTERNAL_QSORT
+void git_qsort(void *base, size_t nmemb, size_t size,
+	       int(*compar)(const void *, const void *));
+#define qsort git_qsort
+#endif
+
 #endif
-- 
1.5.4.rc3
Junio C Hamano· Feb 7, 2008, 04:14 UTC · re: Brian Downing · lore

Applying patches from gmane can be dangerous.

I picked up the qsort patch from Brian while reading the list via gmane's newsfeed and applied it without realizing that it was one of the articles whose addresses on all the address header fields _and_ all strings that look like e-mail addresses have been mangled by gmane. Sign-offs by Dscho and Steffen Prohaska have also been munged (even though that are not part of headers).

It already is part of 'next', and we have the policy of not rewinding 'next', so the record of this mistake will unfortunately be with us forever. Sorry, Brian, Dscho and Steffen.

For the curious, the message was:
    http://article.gmane.org/gmane.comp.version-control.git/72699/raw

I've added the following in my .git/hooks/applypatch-msg and made it executable, so hopefully it won't happen again.

    #!/bin/sh
    case "$GIT_AUTHOR_EMAIL" in
    *@public.gmane.org)
            echo >&2 "Gmane munged the author's email address, aborting."
            echo >&2 "Pick up the original message from your mbox!"
            exit 1
            ;;
    esac

This is really sad. gmane gives us a clean threaded interface (both in web and newsreader), and it never forgets. Whenever I need to refer somebody to an old discussion, I can give an URL to it and allmost all the discussion messages are there with a single paste and clicking around. It has been an indispensable service to me ever since I started reading the git list with it. It is really a shame that I have to prevent picking up patch messages from it with the above hook.

I am wondering if other development communities had a similar issue already, and if so how they are dealing with it.

Nicolas Pitre· Feb 7, 2008, 04:29 UTC · re: Junio C Hamano · lore

Re: Applying patches from gmane can be dangerous.

On Wed, 6 Feb 2008, Junio C Hamano wrote:
Show 12 quoted lines
> I picked up the qsort patch from Brian while reading the list
> via gmane's newsfeed and applied it without realizing that it
> was one of the articles whose addresses on all the address
> header fields _and_ all strings that look like e-mail addresses
> have been mangled by gmane.  Sign-offs by Dscho and Steffen
> Prohaska have also been munged (even though that are not part of
> headers).
> 
> It already is part of 'next', and we have the policy of not
> rewinding 'next', so the record of this mistake will
> unfortunately be with us forever.  Sorry, Brian, Dscho and
> Steffen.
Maybe you can make an exception for this time?  A single
Nicolas
Junio C Hamano· Feb 7, 2008, 09:08 UTC · re: Nicolas Pitre · lore

Re: Applying patches from gmane can be dangerous.

Nicolas Pitre <nico@cam.org> writes:
Show 9 quoted lines
> On Wed, 6 Feb 2008, Junio C Hamano wrote:
>
>> ...
>> It already is part of 'next', and we have the policy of not
>> rewinding 'next', so the record of this mistake will
>> unfortunately be with us forever.  Sorry, Brian, Dscho and
>> Steffen.
>
> Maybe you can make an exception for this time?  A single
That's very tempting.

There currently are 1176 commits in 'next' that are not in 'master'. Among them, 1100 or so of them will never be. They are merges of topics that have long graduated to 'master', or upmerge of 'master' into 'next'.

If we rebuild an equivalent of 'next', starting with 'master' and merging the still-cooking topics today, the result is only 70 commits ahead of 'master'. Among of them, 16 are merges.

In other words, 'next' will go down from v1.5.4-1200-gXXXXXX to v1.5.4-70-gXXXXXX all of a sudden, if we decide to do so.

People who follow 'next' hopefully know what goes on the list, so perhaps we could revise the "never rewind" rule to read "it will not rewind during the regular cycle, but it will be rebuilt once each feature release, immediately after release."

Hmmmmmmmm...
Junio C Hamano· Feb 10, 2008, 10:51 UTC · re: Junio C Hamano · lore

'next' will be rewound and rebuilt after feature releases.

Junio C Hamano <gitster@pobox.com> writes:
Show 18 quoted lines
> Nicolas Pitre <nico@cam.org> writes:
>
>> On Wed, 6 Feb 2008, Junio C Hamano wrote:
>>
>>> ...
>>> It already is part of 'next', and we have the policy of not
>>> rewinding 'next', so the record of this mistake will
>>> unfortunately be with us forever.  Sorry, Brian, Dscho and
>>> Steffen.
>>
>> Maybe you can make an exception for this time?  A single
>
> That's very tempting.
> ...
> People who follow 'next' hopefully know what goes on the list,
> so perhaps we could revise the "never rewind" rule to read "it
> will not rewind during the regular cycle, but it will be rebuilt
> once each feature release, immediately after release."

I am almost committed to this idea, and this is an advance notice that 'next' will be rebuilt on the tip of 'master' soon.

When that happens, I'll announce the commit object name for the old 'next' and the corresponding new one, to make rebasing easier for people who have been following and building on top of it.

For tonight's tree, the tip of 'next' is at 547b1cb (Merge branch 'master' into next) and its tree matches 26f14cc (Merge branch 'js/reflog-delete' into next) that is part of 'pu'.

Jari Aalto· Feb 7, 2008, 08:01 UTC · re: Junio C Hamano · lore

Re: Applying patches from gmane can be dangerous.

* Wed 2008-02-06 Junio C Hamano <gitster@pobox.com>
* Message-Id: 7vodatqu6w.fsf@gitster.siamese.dyndns.org
Show 5 quoted lines
> I picked up the qsort patch from Brian while reading the list
> via gmane's newsfeed and applied it without realizing that it
> was one of the articles whose addresses on all the address
> header fields _and_ all strings that look like e-mail addresses
> have been mangled by gmane.  Sign-offs by Dscho and Steffen
FYI,

Emacs Gnus + news.gmane.org gives access to raw articles with single command. Suppose cursor is at thread start "!"

! R. [  40: Junio C Hamano         ] Applying patches from gmane can be dangerous.
  R.     [  19: Nicolas Pitre          ]

Pressing "C-u g" will display the unmodified article as seen by mail transport. Running git's apply command can be automated pretty easily from there.

Jari
-- 
Welcome to FOSS revolution: we fix and modify until it shines
Junio C Hamano· Feb 7, 2008, 08:21 UTC · re: Jari Aalto · lore

Re: Applying patches from gmane can be dangerous.

Jari Aalto <jari.aalto@cante.net> writes:
Show 12 quoted lines
> FYI,
>
> Emacs Gnus + news.gmane.org gives access to raw articles with single
> command. Suppose cursor is at thread start "!"
>
> ! R. [  40: Junio C Hamano         ] Applying patches from gmane can be dangerous.
>   R.     [  19: Nicolas Pitre          ]
>
>
> Pressing "C-u g" will display the unmodified article as seen by mail
> transport. Running git's apply command can be automated pretty easily
> from there.

I do not think Gnus demiming (that C-u g helps us with) is not an issue.

Have you tried to look at the article in question? Inside your Gnus + news.gmane.org, try typing this:

	j 7 2 6 9 9 <Enter> C-u g
The last two keystrokes are your "C-u g".
And look at the second line in the buffer, that says:
    From: Brian Downing <bdowning-oU/tDdhfGLReoWH0uzbU5w@public.gmane.org>
and weep X-<.

Then scroll down to find Signed-off-by: lines that are similarly mangled, and weep more.

Maybe you run a much newer Gnus, and Lars taught "C-u g" to unmangle them. After all, gmane and Gnus are both his creations, so it _is_ possible. But somehow I doubt it.

If there weren't gmane address mangling, a quickest way to apply a gmane patch to commit is:

	C-u g | g i t  a m - 3 - s <Enter>
	For Gnus uninitiated, it reads: show as raw as opposed
	to demimed (C-u g), pipe the article to the shell
	command (|) that is "git am -3 -s".

But I usually work in batches, so I first C-o (write to file) the articles to a separate mbox, review and _edit_ them as needed before running "git am". And C-o does not suffer from Gnus demiming, so C-u g is not useful in my workflow.

Mike Hommey· Feb 7, 2008, 09:05 UTC · re: Junio C Hamano · lore

Re: Applying patches from gmane can be dangerous.

On Thu, Feb 07, 2008 at 12:21:36AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Maybe you run a much newer Gnus, and Lars taught "C-u g" to
> unmangle them.  After all, gmane and Gnus are both his
> creations, so it _is_ possible.  But somehow I doubt it.

If that can be unmangled, what would be the purpose of mangling in the first place ? If the mangling is any useful, it can't be unmangled. If it can, it should just be removed.

Mike
Johannes Schindelin· Feb 7, 2008, 12:42 UTC · re: Junio C Hamano · lore

Re: Applying patches from gmane can be dangerous.

Hi,
On Thu, 7 Feb 2008, Junio C Hamano wrote:
Show 8 quoted lines
> Jari Aalto <jari.aalto@cante.net> writes:
> 
> > Emacs Gnus + news.gmane.org gives access to raw articles with single
> > command.
>
> Maybe you run a much newer Gnus, and Lars taught "C-u g" to unmangle 
> them.  After all, gmane and Gnus are both his creations, so it _is_ 
> possible.  But somehow I doubt it.
And because he was culled from the Cc: list, he will miss this discussion.

Thanks, Dscho

Brian Downing· Feb 7, 2008, 13:32 UTC · re: Junio C Hamano · lore

Re: Applying patches from gmane can be dangerous.

On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:
Show 11 quoted lines
> This is really sad.  gmane gives us a clean threaded interface
> (both in web and newsreader), and it never forgets. Whenever I
> need to refer somebody to an old discussion, I can give an URL
> to it and allmost all the discussion messages are there with a
> single paste and clicking around.  It has been an indispensable
> service to me ever since I started reading the git list with it.
> It is really a shame that I have to prevent picking up patch
> messages from it with the above hook.
> 
> I am wondering if other development communities had a similar
> issue already, and if so how they are dealing with it.

Gmane didn't start doing this until recently. Maybe they can stop it on a group-by-group basis? Every post to git@vger is archived elsewhere with unmangled email addresses anyway...

"We understand why you're doing this, but it hurts us greatly. Please stop."

-bcd
Aidan Van Dyk· Feb 7, 2008, 14:50 UTC · re: Brian Downing · lore

Re: Applying patches from gmane can be dangerous.

* Brian Downing <bdowning@lavos.net> [080207 07:32]:
Show 19 quoted lines
> On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:
> > This is really sad.  gmane gives us a clean threaded interface
> > (both in web and newsreader), and it never forgets. Whenever I
> > need to refer somebody to an old discussion, I can give an URL
> > to it and allmost all the discussion messages are there with a
> > single paste and clicking around.  It has been an indispensable
> > service to me ever since I started reading the git list with it.
> > It is really a shame that I have to prevent picking up patch
> > messages from it with the above hook.
> > 
> > I am wondering if other development communities had a similar
> > issue already, and if so how they are dealing with it.
> 
> Gmane didn't start doing this until recently.  Maybe they can stop it on
> a group-by-group basis?  Every post to git@vger is archived elsewhere
> with unmangled email addresses anyway...
> 
> "We understand why you're doing this, but it hurts us greatly.  Please
> stop."

Gmane has always done the "hide the real email" address on groups that request it. The git group does *not* request it, but the msysgit group *has* requested it.

Note that I dont ahve any inner circle knowledge of gmane, but I have used it for ages, and watched the gmane discuss for as long.

One of the "nice" things about gmane is that it follows thread/lines/etc across groups as the discussions move. They do this because the only store a single copy of the message (based on message-id), and link it to the groups (after all, it is a news store). But because of that single copy of a message, if the 1st group/list a message comes in for is set to hide the email addresses, I beleve the stored copy gets its addresses munged.

If you look at the message Junio referenced, it hit gmane first from the msysgit list (@google), not the git list (@vger). So when the git@vger mail came in with the same message-id, it simply linked it to the already stored message

Basically, we have to convince groups that are commonly "overlapping" git@vger on gmane not to choose hiding the emails. In this case, the msysgit group.

a.
-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.
Brian Downing· Feb 7, 2008, 15:03 UTC · re: Aidan Van Dyk · lore

Re: Applying patches from gmane can be dangerous.

On Thu, Feb 07, 2008 at 09:50:36AM -0500, Aidan Van Dyk wrote:
Show 8 quoted lines
> If you look at the message Junio referenced, it hit gmane first from the
> msysgit list (@google), not the git list (@vger).  So when the git@vger
> mail came in with the same message-id, it simply linked it to the
> already stored message
> 
> Basically, we have to convince groups that are commonly "overlapping"
> git@vger on gmane not to choose hiding the emails.  In this case, the
> msysgit group.
Thanks, that clears things up for me.
-bcd
Johannes Schindelin· Feb 7, 2008, 16:10 UTC · re: Aidan Van Dyk · lore

Re: Applying patches from gmane can be dangerous.

Hi,
On Thu, 7 Feb 2008, Aidan Van Dyk wrote:
Show 24 quoted lines
> * Brian Downing <bdowning@lavos.net> [080207 07:32]:
> > On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:
> > > This is really sad.  gmane gives us a clean threaded interface
> > > (both in web and newsreader), and it never forgets. Whenever I
> > > need to refer somebody to an old discussion, I can give an URL
> > > to it and allmost all the discussion messages are there with a
> > > single paste and clicking around.  It has been an indispensable
> > > service to me ever since I started reading the git list with it.
> > > It is really a shame that I have to prevent picking up patch
> > > messages from it with the above hook.
> > > 
> > > I am wondering if other development communities had a similar
> > > issue already, and if so how they are dealing with it.
> > 
> > Gmane didn't start doing this until recently.  Maybe they can stop it on
> > a group-by-group basis?  Every post to git@vger is archived elsewhere
> > with unmangled email addresses anyway...
> > 
> > "We understand why you're doing this, but it hurts us greatly.  Please
> > stop."
> 
> Gmane has always done the "hide the real email" address on groups that
> request it.  The git group does *not* request it, but the msysgit group
> *has* requested it.
I just requested this setting to be changed.  Will keep you posted.

Thanks, Dscho

Johannes Schindelin· Feb 11, 2008, 21:16 UTC · re: Johannes Schindelin · lore

Re: Applying patches from gmane can be dangerous.

Hi,
On Thu, 7 Feb 2008, Johannes Schindelin wrote:
Show 28 quoted lines
> On Thu, 7 Feb 2008, Aidan Van Dyk wrote:
> 
> > * Brian Downing <bdowning@lavos.net> [080207 07:32]:
> > > On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:
> > > > This is really sad.  gmane gives us a clean threaded interface
> > > > (both in web and newsreader), and it never forgets. Whenever I
> > > > need to refer somebody to an old discussion, I can give an URL
> > > > to it and allmost all the discussion messages are there with a
> > > > single paste and clicking around.  It has been an indispensable
> > > > service to me ever since I started reading the git list with it.
> > > > It is really a shame that I have to prevent picking up patch
> > > > messages from it with the above hook.
> > > > 
> > > > I am wondering if other development communities had a similar
> > > > issue already, and if so how they are dealing with it.
> > > 
> > > Gmane didn't start doing this until recently.  Maybe they can stop it on
> > > a group-by-group basis?  Every post to git@vger is archived elsewhere
> > > with unmangled email addresses anyway...
> > > 
> > > "We understand why you're doing this, but it hurts us greatly.  Please
> > > stop."
> > 
> > Gmane has always done the "hide the real email" address on groups that
> > request it.  The git group does *not* request it, but the msysgit group
> > *has* requested it.
> 
> I just requested this setting to be changed.  Will keep you posted.

Okay, this took a while, basically, because I am not registered as a "list admin" at gmane.

But Abdel, who is, sorted out the problems, and we will no longer have this issue.

Thanks for your attention, Dscho

Frank Lichtenheld· Feb 7, 2008, 14:10 UTC · re: Junio C Hamano · lore

Re: Applying patches from gmane can be dangerous.

On Wed, Feb 06, 2008 at 08:14:31PM -0800, Junio C Hamano wrote:
> I am wondering if other development communities had a similar
> issue already, and if so how they are dealing with it.

http://gmane.org/tmda.php suggests that this is a feature that can be turned off or on on a per-list basis. So maybe you just need to request to turn it off?

Gruesse,
-- 
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
Johannes Schindelin· Feb 5, 2008, 22:21 UTC · lore

Re: [PATCH v2] compat: Add simplified merge sort implementation from glibc

Hi,
On Tue, 5 Feb 2008, Brian Downing wrote:
Show 10 quoted lines
> diff --git a/compat/qsort.c b/compat/qsort.c
> new file mode 100644
> index 0000000..8663889
> --- /dev/null
> +++ b/compat/qsort.c
> @@ -0,0 +1,60 @@
> +#include "../git-compat-util.h"
> +
> +/* This merge sort implementation is simplified from glibc's. */
> +static void msort_with_tmp(void *b, size_t n, size_t s,
Didn't you forget to include the original copyright, as well as yours?

BTW if these 60 lines have code that is really faster than Microsoft's implementation of a sort, it is really fascinating to me.

Ciao, Dscho

Brian Downing· Feb 6, 2008, 02:47 UTC · lore

Re: [PATCH v2] compat: Add simplified merge sort implementation from glibc

On Tue, Feb 05, 2008 at 10:21:58PM +0000, Johannes Schindelin wrote:
Show 13 quoted lines
> On Tue, 5 Feb 2008, Brian Downing wrote:
> > diff --git a/compat/qsort.c b/compat/qsort.c
> > new file mode 100644
> > index 0000000..8663889
> > --- /dev/null
> > +++ b/compat/qsort.c
> > @@ -0,0 +1,60 @@
> > +#include "../git-compat-util.h"
> > +
> > +/* This merge sort implementation is simplified from glibc's. */
> > +static void msort_with_tmp(void *b, size_t n, size_t s,
> 
> Didn't you forget to include the original copyright, as well as yours?

I (perhaps naïvely) assumed the "from glibc" would be enough. If not, the original is:

/* An alternative to qsort, with an identical interface.
   This file is part of the GNU C Library.
   Copyright (C) 1992,95-97,99,2000,01,02,04 Free Software Foundation, Inc.
   Written by Mike Haertel, September 1988.
   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.
   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.
   You should have received a copy of the GNU Lesser General Public
   License along with the GNU C Library; if not, write to the Free
   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
   02111-1307 USA.  */

(That was from glibc-2.3.6/stdlib/msort.c. I'm not sure of the exact version I referenced for the implementation, but it was a lot closer to 2.3.6 than the current 2.7.)

As far as my copyleft, I was just planning on it being under Git's blanket copyleft. I really only pruned and reformatted code; there's really nothing substantial to claim ownership of.

> BTW if these 60 lines have code that is really faster than Microsoft's 
> implementation of a sort, it is really fascinating to me.

Well, it's faster for us, but I bet our (usually mostly-sorted) tree input is just better for a sort like a merge sort rather than a quicksort.

-bcd

← back to recent threads