Comments on: Sorting (in) embedded systems

By: Nigel Jones

Nigel Jones — Tue, 16 Jun 2009 01:08:08 +0000

Looking over some of the comments it's interesting to see how many people claim to know what the best algorithm is – with a strong emphasis on bubble sorting. I went ahead and added the bubble and cocktail sorts – and as expected they had nothing to commend them. Gregory's additional comment that a radix sort can be performed in linear time prompted me to take a look at it. Maybe it's just the Wikipedia implementation but it appears to require dynamic memory allocation, random number generation and integer divide by 10 and integer modulo 10 arithmetic. In short it looks like a complete non starter on an embedded system.

By: Gregory

Gregory — Mon, 15 Jun 2009 19:55:57 +0000

First off, any recursive algorithm can be made iterative by keeping an explicit state stack instead of relying on the call stack to preserve state (and if you know the stack size at compile time, as you often do, you can allocate that data structure on the stack; at worst, there's calloc).Second, I would have liked to see bubblesort/cocktail sort in your analysis. They perform very well for small n.Third, integers of a known width (e.g. 32-bit) can be sorted in linear time. See radix sort.

By: Anonymous

Anonymous — Sat, 11 Apr 2009 07:12:00 +0000

void shellsort(long *a, long n){ /* Sedgewick-Incerpi sequence */ long step[16] = {1, 3, 7, 21, 48, 112, 336, 861, 1968, 4592, 13776, 33936, 86961, 198768, 463792, 1391376}; long i, j, k, s, t; k = (n < 256) ? 6 : 15; do { for (s=step[k], i=s-1; i < n; i++) { t = a[i]; for (j=i; j >= s && t > a[j-s]; a[j] = a[j-s], j -= s); a[j] = t; } } while (k–);}

By: dyork

dyork — Fri, 10 Apr 2009 00:43:00 +0000

Bubble sort was the right answer 30 years ago, with insertion sort a close second. It’s still the right answer. Glad you saw the light.

By: Anonymous

Anonymous — Fri, 10 Apr 2009 00:30:00 +0000

shell sort has long been my “favorite”, since it’s easy enough to mostly remember (it’s just a modified bubble sort) and is very predictable. Michael Langford: yes, brute force bubble sort works well for a VERY small number of items, but.. shell only has maybe 10-20% more code, and it works well for a MUCH larger range of items.We had a project where someone had coded a bubble sort for a small number of items, because it was quick. Then, we ended up putting in a few hundred or thousand items later. And it took MINUTES to run on a fast machine. Moral of the story is: don’t use an algorithm which degrades horribly unless you have no choice..

By: Harold Fowler

Harold Fowler — Thu, 09 Apr 2009 21:42:00 +0000

Very fascinating!RTwww.anon-tools.cz.tc

By: Anonymous

Anonymous — Thu, 09 Apr 2009 20:42:00 +0000

“I’m not sure how a highly optimized qsort leads to lots of code overhead”I think he is talking about the qsort implementing special cases. Robust implementations of algorithms can have a lot more code than a basic implementation.

By: Nigel Jones

Nigel Jones — Thu, 09 Apr 2009 19:09:00 +0000

What you suggest would of course work admirably for a specific case. However I’m trying to generalize the solution for embedded systems, since different things come in to play when compared to sorting data in your typical database application. In many cases, the code footprint is important (as it was when I found that qsort was very large compared to my available memory). In other cases the running time is the most important. Depending upon the application, it could be the worst case running time or it might be the variability between best and worst case that is of interest. Finally the issues of dynamic memory allocation and recursion that I mentioned are also important in many (most?) embedded systems.

By: Michael Langford

Michael Langford — Thu, 09 Apr 2009 18:33:00 +0000

Perhaps I misunderstand.Aren’t you doing a array of known length, where you’re having greater issues with code size then runtime?Just use the sort that has the smallest footprint, then calculate what array data would be the worst case runtime, and run it a thousand times on that data while measuring your timing.If that’s satisfactory, problem solved.

By: Anonymous

Anonymous — Thu, 09 Apr 2009 18:29:00 +0000

>its running time should increase linearly …good luck with that. O(NlogN) is about the best you can do, unless you can constrain the input so that pigeonhole sort will work.http://en.wikipedia.org/wiki/Sorting_algorithm