views:

598

answers:

4

Is sqrt still slow in Delphi 2009?

Are the old tricks (lookup table, approx functions) still useful?

+3  A: 

Many moons ago I had an app that computed distance to sort vectors. I realized sorting by the un-sqrt-ed values was the same so I skipped it altogether. Sorted by distance^2 and saved some time.

n8wrl
Yes, I've done this sort of thing more than once. Very often you can work with distance^2 instead of distance.
Loren Pechtel
exactly. comparing dot products are just as good as comparing magnitudes. (sadly, it doesn't work with ratios.)
iCE-9
+1  A: 

My answer to questions of efficiency is to just apply the simplest method first, then optimize later. Making an operation faster when there's no need for it to be all that fast in the first place seems silly.

I digress, however, since my answer is about efficiency, not the historical aspects of your question.

Soviut
So, basically, this isn't an answer at all.
Argalatyr
There are two parts to his question, one is about efficiency and the other is about the historical nature of the function. He obviously isn't looking to optimize an existing implementation, so why not try it first then see if the performance is tolerable.
Soviut
+5  A: 

If you are dealing with a small set of really large numbers then a lookup table will most always be faster. While if you are dealing with a large set of small numbers then even a slow routine may be faster then maintaining a large table.

I looked in System.pas (where SQRT is located) and while there are a number of blocks marked as licensed from the Fastcode project, SQRT is not. In fact, it just makes an assembly call to FSQRT, so it most likely hasn't changed. So if it was comparatively slow at one point then it most likely still is as slow (although your CPU may be a lot faster and optimized for that now . . . .)

My recommendation is to look at your usage and test.

Jim McKeeth
FWIW, Fastcode doesn't have a SQRT version that I can find.
Marshall Fryman
Right. I don't believe there are any optimizations over using FSQRT or a look-up table.
Jim McKeeth
My usage is a physic simulation game
Mykelyk
You are really going to need to optimize it for your usage. If you see that you are calculating the same large square roots repeatedly then you might consider caching them, but that will probably only be faster if you are dealing with large numbers. Small numbers will probably be faster to just calculate each time. Of course you will need to test and see.
Jim McKeeth
+1  A: 
ulrichb
So one possible solution would be to replace the call to Sqrt with some inline assembly to avoid the call into System.pas but I'm wondering how much time the call takes compared to actually running the fsqrt
Bing