[ODE] Sweep-and-Prune space for ODE
Pierre Terdiman
pierre.terdiman at novodex.com
Fri Nov 26 15:20:26 MST 2004
> Okay, now THAT is a nice implementation of radix sort. For floats, it
> is 2.3 times faster than std::sort! That means it's 5 times faster
> than Pierre's code. Five. I would strongly suggest that anyone using
> Pierre's code should switch to the stereopsis code.
Of course you noticed that Michael's version is not a rank sorter, did you ?
That is, if you use the piece of code on his website "as is", it doesn't
give you anything but a sorted list of floats. This is useless since you
don't have a mapping between this list and the original one.
Now if you rewrote it completely and have something more advanced, we'll be
happy to look at this new version.
>Sorry guys, but I just *have* to ask. Has anybody done any conclusive
>benchmarks on the radix sorting code? I remember a while back I did
>some pretty extensive tests and I found that radix sorting was 2x as
>fast as std::sort for integers, but the floating point version (that
>handled signs) was 2.5x slower!
This is a bit surprising since the code is almost the same for both. In
particular when all floating-point values are positive. I'll be interested
to see a small test app reproducing this.
>One thing I don't think that article covers is caching behaviour. On modern
>computers caching behaviour can dominate sorting performance
Yes. And radix sort is not cache-friendly.
>Alas, I never got time to implement that,
What about using the implementation in OPCODE ?
- Pierre
More information about the ODE
mailing list