Skip to main content
gamedev.net
🔒 Locked

fast trig functions

Started by ashade 9 replies 1.6k views
Original Post
ashade
ashade
has anyone realized that calculating sine, cosine, tangent, etc..., is stupdily slow and can be very improved using sse, 3dnow or simply the fpu? My question is, has anyone already made a fast trig function to work on floats? if so, could you please post here and, if not, let's make here a library of fast trig/exponential functions to work on floats so we can use in programs that time is critical...
Mercury
Mercury
Make an array for a lookup table and fill it in at load time.
ashade
ashade
it's not precise and can get a little slow beacause of range reduction..
ashade
ashade
and how about the exponential function... there's no way to make a lookup table for it....
Extrarius
Extrarius
Have you actually timed the functions and found them too slow in places you couldn't optimize algorithms? I could see it on a P1 166 maybe, but on modern computers it seems unlikely that they'd be a bottleneck.

As far as float versions, in c: sinf, cosf, sqrtf, expf, logf, powf, etcf
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
smart_idiot
smart_idiot
I imagine your compiler will use SSE if you compile for a CPU that supports it. Most will assume a 386 unless you tell it otherwise.
Chess is played by three people. Two people play the game; the third provides moral support for the pawns. The object of the game is to kill your opponent by flinging captured pieces at his head. Since the only piece that can be killed is a pawn, the two armies agree to meet in a pawn-infested area (or even a pawn shop) and kill as many pawns as possible in the crossfire. If the game goes on for an hour, one player may legally attempt to gouge out the other
arm
arm
One thing you have to watch out for when using LU tables for these functions is a huge L2 cache miss - now that does cost a fair few cycles. If you're doing your trig in batches this probably won't be a problem. Personally, I've never had any problems with the built-in functions or the ones built onto the x87 fpu.

Profiling is key here.
markr
markr
It seems to me, that if (with gcc) you use -ffast-math and -O, the compiler just compiles floating point trig instructions rather than calling into the C library.

This is of course likely to be pretty fast.

I need not remind you that you don't need a Pentium4 to have floating point trig instructions.

Mark
ashade
ashade
take vc++ 2003, make 10 milion calls for cos or cosf and then make your on function and do the same ten milion calls... i'm sure you will be surprized...
Palidine
Palidine
Quote:
Original post by ashade
take vc++ 2003, make 10 milion calls for cos or cosf and then make your on function and do the same ten milion calls... i'm sure you will be surprized...


right, but the point is that in an _actual_ application trig functions are not likely to be your bottleneck. In a typical game/app you aren't making 10 million calls to trig functions in a tight loop, at least i hope you're not. The key is to profile your actual app. Then if, and only if, it turns out that the trig functions are a bottleneck should you consider something like a lookup table. 99% of the time, something else entirely will be your bottleneck (like you chose a bad algroithm).

-me

[Edited by - Palidine on March 14, 2005 2:20:18 PM]
chollida1
chollida1
I'd have to agree with Paladine.

In the old days you would use a look up table as in relative terms, memory looks ups were fast and heavy computations were slow.

Now adays the most commonly occuring bottle neck is memory access. So the tables have turned now and if you want fast code then prefer computations to memory access.

I'd be very surprised if a look up table was faster than the computation.

Cheers
Chris
CheersChris

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.