Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #103061
| From | mathog <dmathog@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | language changes to optimize for speed in qsort? |
| Date | 2017-02-03 10:36 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <o72ij4$448$1@dont-email.me> (permalink) |
ANSI C provides the qsort() function which is very general and
convenient. Unfortunately the generality part comes from passing in a
comparison function, and for large sorts it is often factors of 2 or 3
slower than one's own quicksort with the comparison operations coded
directly in the function (so that no comparison function is passed or
called). It would be nice to have the speed of the specifically coded
qsorts - without having to code them specifically.
qsort() is also single threaded (presumably, probably that is an
implementation dependent choice, but there is no way to specify the
number of threads if more than 1 is used). When pretty much every
machine where a huge sort must run is likely to have many threads
available this seems kind of archaic. It would be much more convenient
to just paste N into a standard function to split the work across N
threads, rather than having to pull in some nonstandard code. Even if
the sort does not scale linearly for large N.
Have the language developers given any thought to providing souped up
qsorts that would resolve either of these two issues?
C doesn't have templates, unless it is in one of the newer language
standards, and this is one of the few places in C where something like
that might be really useful. (This despite my loathing of C++ templates
because of the agony they can induce when one needs to debug inside a
template.)
This is what we have now (for discussion sake,
C2_DATA has c1,c2 which are both int, array is an array of C2_DATA
structs):
int c2_compare(const void *a, const void *b){
C2_DATA *sa = (C2_DATA *)a;
C2_DATA *sb = (C2_DATA *)b;
int ret = sa->c1 - sb->c1;
if(!ret){
ret = sa->c2 - sb->c2;
}
return(ret);
}
qsort(array, members, sizeof(C2_DATA), c2_compare);
For this very specific template case one would still have the same
compare function code but in the some compilation module one would
invoke a slightly different qsort
qsort_type_specific((C2_DATA *)array, size_t members,
sizeof(C2_DATA), c2_compare,"qsort_C2");
which would take the innards of c2_compare(), paste it into
the quicksort source code everywhere *c2_compare was employed before,
compile that, to produce a function
void qsort_C2((C2_DATA *)array, size_t members);
which could then be called or used like any other function.
While this would be a way to easily produce a type optimized qsort for
the end user, even I don't at all like the syntax described above for
qsort_type_specific() because it does something completely unexpected
compared to usual C code. Something similar could be done now using
defines and include files, however that isn't the most convenient of
methods and code like that is often a pain to read and maintain.
As for parallel quicksort, there a solution need not require a new C
syntax, just a new function or two, for instance:
void tqsort(void *base, size_t nmemb, size_t size,
int(*compar)(const void *, const void *),
int threads);
int threads_available(void);
and the details of how the thread count is obtained, and how many
threads tqsort actually uses, even which parallel quicksort algorithm is
used, is entirely up to the compiler. Except it must always run, even
if it must do so with one thread.
Are there any other standard functions which would benefit from threads?
The same argument might apply there too. The thing is,
while it might be useful for memcpy() or memset() it isn't clear to me
that the performance gain would be worth the effort. Sorts, on the
other hand, are often rate limiting in real world code.
Regards,
David Mathog
Back to comp.lang.c | Previous | Next — Next in thread | Find similar | Unroll thread
language changes to optimize for speed in qsort? mathog <dmathog@gmail.com> - 2017-02-03 10:36 -0800
Re: language changes to optimize for speed in qsort? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 17:15 -0600
Re: language changes to optimize for speed in qsort? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 16:26 -0800
Re: language changes to optimize for speed in qsort? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-05 02:58 -0600
Re: language changes to optimize for speed in qsort? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 03:01 -0800
Re: language changes to optimize for speed in qsort? Gareth Owen <gwowen@gmail.com> - 2017-02-05 13:03 +0000
Re: language changes to optimize for speed in qsort? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-06 04:30 -0600
Re: language changes to optimize for speed in qsort? supercat@casperkitty.com - 2017-02-05 10:07 -0800
Re: language changes to optimize for speed in qsort? supercat@casperkitty.com - 2017-02-03 16:42 -0800
Re: language changes to optimize for speed in qsort? Ian Collins <ian-news@hotmail.com> - 2017-02-04 13:46 +1300
Re: language changes to optimize for speed in qsort? supercat@casperkitty.com - 2017-02-03 16:57 -0800
Re: language changes to optimize for speed in qsort? Keith Thompson <kst-u@mib.org> - 2017-02-03 18:39 -0800
Re: language changes to optimize for speed in qsort? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 11:28 -0800
csiph-web