>>11
while keeping precision
No. If you have a very specific set of values you need the sin/cos/tan of, then a lookup table maybe faster, but if you want the same precision, then doing it in software is going to be MUCH slower --- I don't know if anyone here was around to remember when x87s were optional and the immense speedup they provided for FP when installed compared to software emulation.
Implementing an approximation algorithm in software may also slow down other parts of the program, as tens or hundreds of extra bytes of instructions compete with other pieces for cache. The other point which isn't as obvious is the fact that the x87 operates in parallel with the other EUs, so the CPU can still execute other instructions while one x87 op is executing.
I should mention here that doing some operation in software will, if it's not currently slower than the hardware, become so in the future. Case in point: the ARM SoC in the iPhone 5
finally added a divide instruction. The fastest software division routine (32-bit by 32-bit) for ARM was between 10 ~ 120 cycles, while the hardware divide is 2-12 cycles. Sandy Bridge takes 11-18, although its clockspeed is several times higher and much of that is pipelining cost. Unfortunately for the ARM, all existing software that uses software division will have no benefit from the added instructions, since they didn't follow the x87 model of reserving opcode space, excepting when the instruction isn't supported, and handling it in emulation. They'll continue to use the slower, bloatier routine, while x86 apps compiled with x87 instructions work slower under emulation, but automatically benefit when the FPU is present.
tl;dr: Functionality implemented in software cannot improve. Functionality implemented in hardware improves with the hardware.