[ODE] Sweep-and-Prune space for ODE

[Graham Fyffe]

Oops, I forgot to Reply All :P  Here it is again:

This is exactly the source code I tried that was 2.5 times slower than
std::sort.  This was pretty consistent over all the sizes I tested.

- Graham


On Thu, 25 Nov 2004 16:11:09 -0000, Brian Marshall
<brianmarshall at blueyonder.co.uk> wrote:
> A good place to look would be here:
> 
> http://www.codercorner.com/RadixSortRevisited.htm
> 
> A page on it by Pierre Terdiman - the guy who wrote Opcode where the sort
> has been borrowed from.
> 
> One thing I don't think that article covers is caching behaviour. On modern
> computers caching behaviour can dominate sorting performance - a sort with a
> better algorithm in theory can be beaten by one with better cache behaviour
> depending on the data set.
> 
> Still doesn't mean people shouldn't test it - see what works for your data.
> I'd have thought the potentially bigger issue would be floats vrs doubles,
> rather than IEEE float or not. After all some people will run ODE in double
> precision - so a version for doubles could be needed too.
> 
> -Brian. 
> 
> 
> 
> -----Original Message-----
> From: ode-bounces at q12.org [mailto:ode-bounces at q12.org] On Behalf Of Graham
> Fyffe
> Sent: 25 November 2004 14:51
> To: Aras Pranckevicius
> Cc: ode
> Subject: Re: [ODE] Sweep-and-Prune space for ODE
> 
> 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 was pretty consistent for input sizes from 10,000 to
> 100,000,000.  Was I just using a crappy radix sort implementaiton?
> 
> - Graham
> 
> 
> _______________________________________________
> 
> 
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>