[matthey]

Originally Posted by guy lateur

Well that's what I thought alkis was saying -- quoting thomas, quoting me, talking about the transcendental sine function, and coming to an estimated 10 times speedup. Anyway, here's my understanding:

1. It's 10 times more expensive to do general calculations (add/sub/mul/div) on integers than it is on floats.

There really is *not* a general rule. It depends on the hardware used. Modern CPUs are usually similar but old CPUs can vary significantly.

68030 add.l 2 cycle
68882 fadd 56 cycles

68030 muls.l 44 cycles
68882 fmul 76 cycles

68030 divs.l 90 cycles
68882 fdiv 108 cycles

Add and sub are more frequent so maybe there is an overall 10x speedup by using integer instead of the FPU for the 68030+68882.

68060 add.l 1 cycle
68060 fadd 3 cycles

68060 muls.l 2 cycles
68060 fmul 3 cycles

68060 divs.l 38 cycles
68060 fdiv 37 cycles

The 68060 FPU is not even fully pipelined but we can already see that using integer is not going to be 10x faster than avoiding the FPU, at least with common math.

Originally Posted by guy lateur

2. It's even more expensive (100++ times) to call transcendental functions, like sine, compared to precalculating them into a table. And they require floating arguments, by definition, which makes them even worse.

68882 fsin 394 cycles
68040 no
68060 no

The 68060 should be fewer cycles at finding fsin in software than the 68882 fsin instruction (perhaps half the cycles). I still expect the all integer sin table lookup to be closer to 10x faster than 100x times faster. All of the 68k FPUs can sometimes work in parallel to the integer units reducing the overall cost with mixed code (the 68060 has 2 integer units though too). Floating point args are only a tiny percentage of any difference and can sometimes be avoided by the compiler by using inlined assembler code (default with vbcc).