Thread: Beginner level issue: next prime number

Originally Posted by flp1969

Code:

$ gcc -O2 -ffast-math -o sqrt-test sqrt-test.c
$ ./sqrt-test 1000000000
 sqrt( 1000000000 ) = 31622 (109 cycles)
isqrt( 1000000000 ) = 31622 (553 cycles)

So, without the proper optimizations, isqrt() is, indeed, faster.

Very interesting. I compiled without -ffast-math and I tested using no optimisations, -O2 and -O3. And for each option and 1073741822 iterations and timing using the time command (time ./a.out) and valgrind both showed sqrt() to be significantly faster on my i7-8700K. Just one of those things I guess.

Originally Posted by flp1969

So, without the proper optimizations, isqrt() is, indeed, faster.

Ok, I was bored so I decided to repeat my tests.

For 1 call of each function (sqrt() and isqrt()), isqrt() is indeed faster than calling sqrt() (about twice as fast on my CPU and according to valgrind). So, you're correct.

The big difference in speed happens when I make hundreds of thousands of calls to each (this is when, on my computer, the sqrt() method is significantly faster overall -- for all the calculations). I'm testing in a loop and the calls are not being optimised away (I have the variables as volatile and also checked the asm), so that doesn't explain it. I /am/ however calculating, in the loop, the square root of consecutive numbers (for (i = 0; i < ITERATIONS; i++)). I assume that because of this oversight on my part (using consecutive parameters) that the CPU is caching... something... explaining the huge discrepancy. I could probably try calculating the square root of a random number for each iteration and perhaps that would give different results but is it worth it?