Can you shed any light on this thing about different comps giving different results for cos and sin.
No. I can only speculate that it is related to different FPU accuracy modes. Running long enough, I could see how accumulated errors can add up over time, to produce significantly different results - particularly if numbers are moved back and fourth between CPU registers / memory (32 or 64 bit precision) and the FPU (80 bit precision). I think that 360 floats for each of the trig functions, is an arbitary amount of memory, and Im very supprised you used it.
It's not really a matter of size, so much as a matter of access speed. When a CPU wants to access a page, it requests it from the L1 data cache (super fast - but small). If it is not avaiable there it tries the L2 Cache (still reasonably fast, and relatively large). If it can't find it there either, it will hit the main memory (this is slow), and eventualy the harddrive (really bad). The more cache misses, the more significant the time penalty.The FPU instruction on the other hand simply needs to have it's registers loaded with the proper values, and told to execute. On a pipelined superscalar CPU (any Pentium Pro or Pentium II class CPU or higher) this instruction can be executed in paraallel with ALU code as can multiple FPU instructions if more than one FPU exists (Pentium 4 and AMD64).
This is not the case for look-up tables which rely on memory access and cannot normally be executed out-of-order.
And the tossup is, an arbitary increase in speed in exchange for an arbitary increase in size/memory.
That's currently the truth for most algorythms. Use memory or use processing power. However processing power and semi-conductor density is increasing exponentialy over time, where as (affordable) memory increases in speed and capacity in a much more linear fashion. Unless, you are saying that it isnt quicker?
I'm saying it depends on the hardware. Specificly it depends on CPU architechture, northbridge bandwidth (and traffic) and memory speed. It also depends in large parts on whether the code in question is cache friendly or not. In those examples the random-calculation take up most of the time, so that "levels" the score quite a bit.
That was the point. The random calculation overhead however is not (or rather should not) be a significant factor, because it executes at a constant speed, so any overhead is applied equally to both tests. would compiler optimization still be an important factor in this test?
Not so much compiler optimizations, as cache optimizations. Computers are very, very good at doing in-order processing, and your look-up tables are just that. However games in particular are generally not very cache friendly programs as very little game logic is executed 'in-order' - or at least 'in-the-same-order' and this is why benchmarking is such a horrible, horrible task.Also keep in mind that for a simple application like this, you pretty much have unrestricted access to close to the full bandwidth of the northbridge. In a game where you're copying vertice lists, texture data and what not back and fourth between system memory and video memory, this would not nessecarilly be the case.
In either case, using Fredborgs example gives me about a 79/99 score (which isn't surprising since our computers are similar) when the computer is idling. However keeping the computer (more specificly the north bridge) busy by watching a film clip, playing some Civilization IV, or defragmenting the harddrive, the array version increases in time to execute much more rapidly than the FPU version does.
There are obviosly reasons not to do it, as you have said, if the range of angles you want is continuos rather than descrete.
Is this a bad time to point out that Sin and Cos aren't discrete functions? And that when you need to get an angle (using ACos, ASin, or ATan) you will not get a discrete number, and the accuracy loss that provides is much more significant than any real or imaginary loss of precision do to IEEE FP accuracy errors. These integer conversion precision loss is much more severe, and will almost certainly give obvious visual artefacting, particularly in high resolutions Even the con-people on the thread admit lookups are faster,
You've been reading this discussion like Satan reads the bible I see. Lookups for simple FPU instructions are only faster if you specificly design your benchmark to prove it, by using compiler or cache optimizations, and/or have an older CPU. This presents a worthless benchmark for any type of program that requires constant interaction and feedback (like say a videogame). If you're filling up your northbridge with other stuff aswell (like say graphica), your lookup tables are going to be even worse off. I don't care ! Faster is faster and I cannot see why I should make "lesser" code just because someone think I should.
No. Quite clearly you're entitled to your opinion, even when it's wrong.