From: Roland Orre <roland.orre@neurologic.se>
Subject: Sort on vectors slow
Date: Thu, 14 Oct 2004 14:28:31 +0200 [thread overview]
Message-ID: <1097756911.5279.3531.camel@localhost> (raw)
I noticed that the default sort routine on vectors is very
slow. I'm using the restricted-vector-sort! and compared
with a merge sort on vectors instead, the speed difference
is tremendous. In this example foo is a vector with 100000
elements (an often occuring size for me currently), here
with random numbers. Machine is a 2.2 GHz P4. Observe that
the restricted-vector-qsort I'm using takes inclusive endpos
according to the doc (I've mentioned this on guile-devel).
(begin
(define vlen 1000000)
(define foo (make-vector vlen 9999999))
(array-map! foo random foo)
(define bar (copy-vector bar))
)
(verbose 2)
(restricted-vector-qsort! foo < 0 (1- vlen))
;;; 249150 msec (71790 msec in gc)
(array-copy! bar foo)
(restricted-vector-msort! foo < 0 (1- vlen))
;;; 1060 msec (300 msec in gc)
I'm not sure if this huge difference makes sense, or if it indicates
a problem with quicksort, which I took from libc earlier (1998). I've
found in some text though that time complexity of quicksort is O(N^2)
in worst case, only O(N log N) in average, and merge sort is O(N log N)
in all cases. An advantage is that merge sort is stable also, which
quicksort isn't. Anyone knowing anything about memory usage for the
two algorithms?
/Roland
PS. Code to the restricted-vector-msort! below. I suggest that this
should go into the distribution, alternatively we should replace the
current default quicksort for vectors with merge sort.
SCM_DEFINE (scm_restricted_vector_msort_x,
"restricted-vector-msort!", 4, 1, 0,
(SCM vec, SCM less, SCM startpos, SCM endpos, SCM tmpv),
"Sort the sequence @var{items}, which may be a list or a\n"
"vector. @var{less} is used for comparing the sequence elements.\n"
"The sorting is destructive, that means that the input sequence\n"
"is modified to produce the sorted result.\n"
"This is a stable sort.")
#define FUNC_NAME s_scm_restricted_vector_msort_x
{
const scm_t_trampoline_2 cmp = compare_function (less, 2, FUNC_NAME);
size_t vlen, spos, len;
if (SCM_VECTORP (vec))
{
SCM *temp;
vlen = SCM_VECTOR_LENGTH (vec);
SCM_VALIDATE_INUM_MIN_COPY (3, startpos, 0, spos);
SCM_ASSERT_RANGE (3, startpos, spos <= vlen);
SCM_VALIDATE_INUM_RANGE (4, endpos,0, vlen);
len = SCM_INUM (endpos) - spos;
/*
the following array does not contain any new references to
SCM objects, so we can get away with allocing it on the heap.
*/
if (SCM_UNBNDP(tmpv))
temp = scm_malloc (len * sizeof(SCM));
else
if (SCM_VECTORP(tmpv) && (SCM_VECTOR_LENGTH(tmpv) >= vlen))
{
temp = SCM_WRITABLE_VELTS(tmpv);
}
else SCM_WRONG_TYPE_ARG (1, vec);
scm_merge_vector_step (vec, temp, cmp, less, spos, len);
if (SCM_UNBNDP(tmpv))
free(temp);
return SCM_UNSPECIFIED;
}
else
SCM_WRONG_TYPE_ARG (1, vec);
}
#undef FUNC_NAME
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
next reply other threads:[~2004-10-14 12:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-14 12:28 Roland Orre [this message]
2004-10-19 17:52 ` Sort on vectors slow Marius Vollmer
2004-10-19 21:47 ` Marius Vollmer
2004-10-19 22:28 ` Marius Vollmer
-- strict thread matches above, loose matches on Subject: below --
2004-10-14 14:22 Roland Orre
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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1097756911.5279.3531.camel@localhost \
--to=roland.orre@neurologic.se \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).