In a message dated 04-05-98, George White said to David Noon about Hubble,
Bubble, Toil & .
Hi George,
DN>CPU used. For character strings on an Intel I would stick with 8, but
DN>doubles, as I used above, would likely be Ok up to 10.
GW>'tis interesting. I've been playing on that aspect too :-)
GW>For the full standard library qsort() replacements (that use external
GW>compare routines and are passed data item length) the switch point is
GW>7 elements.
That is a reasonable figure, especially for older Intel CPU's that had
poorer microcode for string instructions.
GW>For a routine optimised for char data it was fairly high - I saw
GW>improvements in sort time up to 40, but I suspect it is sensitive to
GW>total sort length.
It would be very sensitive to key length. For short strings you could,
perhaps, get away with more. For longer strings, I would limit Insertion
sort to rather fewer than 40. As above, about 7 or 8.
GW>For short data 13 to 18 gave the same time - so probably 15 would be
GW>optimum.
Very plausible.
GW>For long data 9 to 11 gave the same time - so 10 is optimum in that
GW>case.
Very plausible, again.
On a CPU with very fast FPU hardware, this would likely be good for floating
point numbers, too. With a slower FPU (e.g. 80387 or earlier) I would keep
it down a couple more.
[snip]
GW>I'll put the fully optimised code for integral types I'm working up
GW>from the general qsort() in SNIPPETS up locally (or do you want to
GW>discuss this and play with ideas on Saturday?).
I'll d/l a copy of SNIPPETS tomorrow night (Tuesday) and take a look.
Discussing it Saturday will be fine.
GW>I think it may provide a good basis for a template...
Yes, you can practice your polymorphic coding. ... :-)
Regards
Dave

___
 * MR/2 2.25 #353 * "That explains everything! But it doesn't help at all."
--- Maximus/2 3.01
---------------