On 6 Jul 2009, at 21:51, Steven Ross wrote:
On Mon, Jul 6, 2009 at 1:48 PM, Steven Ross <spreadsort@gmail.com> wrote:
On Mon, Jul 6, 2009 at 11:07 AM, Vladimir Prus <vladimir@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?