Re: sorting floats by casting to integer

On 6 Jul 2009, at 21:51, Steven Ross wrote:

> On Mon, Jul 6, 2009 at 1:48 PM, Steven Ross <spreadsort <at> gmail.com>  
> wrote:
>
>>
>>
>> On Mon, Jul 6, 2009 at 11:07 AM, Vladimir Prus <vladimir <at> codesourcery.com 
>> >wrote:
>>
>>>> Yes, I guess I was using denormalized numbers for the 23-bit  
>>>> case, but
>>> it's
>>>> interesting that there is such a huge speed difference, and I  
>>>> doubt it's
>>>> because they're denormalized; there is no reason to special-case
>>>> denormalized sorting.
>>>
>>> It is well possible that comparing denormalized numbers is slow.
>>
>>
>> Taking 10M elements with my 23 bits of randomness case, and making  
>> the top
>> exponent bit 1, so that the data is normalized:
>>     if(!(float_mem_cast<float, int>(array[v]) & 0x7f800000)) {
>>       //Make the top exponent bit high
>>       CAST_TYPE temp = 0x80000000 | float_mem_cast<float,  
>> int>(array[v]);
>>       memcpy(&(array[v]), &temp, sizeof(DATATYPE));
>>       //printf("new %e\n", array[v]);
>>     }
>>
>> I see std::sort take 83.527s, as compared to 1.226s when sorted as
>> integers.  denormalized numbers are not the problem.
>>
> That was the sign bit.  Sorry.  With that fixed (0x40000000), the  
> change
> does appear to be an issue with denormalized numbers.
> Instead, I'm seeing 3X speedups on modest-sized tests.
>
> I still have a problem: what's a good floating-point benchmark?

Possibly a stupid thing to say -- rather than trying to massage bits  
like this, why not just generate floats directly, something like  
rand() * pow((float)10, rand()%20) for example?
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost