Comments on: Timing square root

By: Wrong On The Internet! | Rambling Llamas

Wrong On The Internet! | Rambling Llamas — Thu, 03 Nov 2011 21:58:03 +0000

[...] this guy went into it in much more thorough detail if you’re interested!) This entry was posted in [...]

By: Bruce Dawson

Bruce Dawson — Sun, 23 Oct 2011 05:22:12 +0000

One part of the reason that the x87 square root is slower is that it is probably calculating square root to double precision. The x87 hardware defaults to calculating square root to 80-bit precision, the C run-time changes the setting so it calculates it to 64-bit precision, but if you change it to calculate it to 32-bit precision (controlfp) then it will be a bit faster. Square root and float-divide timings on x87 are both affected by the selected precision. I don’t think any other operations are.

Of course, changing a global (well, global per-thread) setting in order to get a local optimization is pretty crazy, so your points stand.

By: jalf

jalf — Thu, 11 Nov 2010 14:18:15 +0000

Did you ever get around to cleaning up the source code?

By: Yuhong Bao

Yuhong Bao — Mon, 20 Sep 2010 07:14:03 +0000

“If your customer’s PC has DirectX 9, it has SSE2.”
Not necessarily, as the graphics card choice is independent of the CPU choice.

By: Bit operations on different datatypes

Bit operations on different datatypes — Wed, 08 Sep 2010 20:20:39 +0000

[...] [...]

By: Gregory

Gregory — Wed, 24 Feb 2010 13:38:22 +0000

Hello Elan,

Thank you for the answer.

Since I posted my comment, I came across http://msdn.microsoft.com/en-us/library/bb173458(VS.85).aspx so I think I’m going to implement my high precision timer using QPC on Windows and gettimeofday on Linux and Mac.

Or the easy way seems to be Boost.PTime

By: Elan

Elan — Tue, 23 Feb 2010 04:28:21 +0000

We use rtdsc to implement our cycle counter, since it seems to have the best resolution of any of the timers available. It's best to put target code in a loop for the same reason you would weigh rice by the thousand rather than one grain at a time on your kitchen scale: systematic and random error. First, there is a certain systematic error in querying the cycle counter -- the StartCycleCounter() inline function call and the rtdsc op itself have some latency, and the timer is probably only accurate to within a couple of nanoseconds, measuring a single iteration of an 86ns operation would have a large relative error. On the other hand, a relative error of 10^-8 in 10^-3 seconds is much smaller, and so more accurate. Also, timings in vivo can be messy: any single iteration of the loop might take a little longer than expected because of other threads, memory bus contention, clock variability, operating system intervention, even CPU temperature. Taking multiple measurements, or a single measurement of multiple iterations, improves statistical significance and narrows the error bars.

By: Gregory

Gregory — Wed, 17 Feb 2010 19:14:26 +0000

I’m curious about what’s behind StartClockCycleCounter(); and StopClockCycleCounter();

What’s the best way to benchmark a portion of code on PC? QueryPerformanceCounter (windows only), RTDSC? something else?

And is there a point putting the target code inside a loop?

By: Elan

Elan — Thu, 29 Oct 2009 22:25:49 +0000

Elias: 4096 loops over 4096 floats with x = powf(x, 0.5f) took 1449.538ms, or 86.4ns/float. This is 3.6 times worse than even the compiler's naive x87 sqrt(x), and twenty-seven times worse than rsqrtss with one step of Newton-Rhapson iteration (which is equally accurate). Taking an exponent is a function call, and a very slow function call at that.

By: Elias

Elias — Thu, 29 Oct 2009 20:43:50 +0000

Here is one technique you apparently haven’t tried: taking the number to the 0.5 power. How does that compare?