Un fsin più veloce ma meno accurato per Intel asm?

Question

Poiché la funzione per il calcolo della funzione sin(x) in x86 risale all'era Pentium e apparentemente non utilizza nemmeno i registri SSE, mi chiedevo se esistesse un set di istruzioni più nuovo e migliore per il calcolo delle funzioni trigonometriche.

Sono abituato a codificare in C++ e fare alcune ottimizzazioni asm, quindi tutto ciò che si adatta a una pipeline a partire da C++, a C a asm, funzionerà per me.

Grazie.

---

Sono sotto Linux a 64 bit, per ora, con gcc e clang (anche clang dura in realtà non offrono alcuna ottimizzazione legati FPU per quanto ne so).

EDIT

• Ho già implementato una funzione sin, di solito è 2 volte più veloce std::sin anche con sse on.
• La mia funzione non è mai più lento di fsin, anche dura fsin di solito è più accurato, ma considerando che fsin mai sorpassa il mio sin implementazione, terrò il mio sin per ora, anche il mio sin è completamente portatile dove fsin è per solo x86 .
• Ho bisogno di questo per il calcolo in tempo reale, quindi scambierò precisione per velocità, penso che starò bene con 4-5 decimali di precisione.
• no a un approccio basato su tabella, non lo sto utilizzando, svita la cache, rende tutto più lento, nessun algoritmo basato su accesso alla memoria o tabelle di ricerca per favore.

Answer 1

Se stai bene con un'approssimazione (sto assumendo sei, se si sta cercando di battere l'hardware), si dovrebbe dare un'occhiata a sin implementazione di Nick a DevMaster:

http://devmaster.net/posts/9648/fast-and-accurate-sine-cosine

Ha due versioni: un metodo "fast & sloppy" e un metodo "slow & accurato". Una coppia risponde che qualcuno stima gli errori relativi rispettivamente del 12% e dello 0,2%. Ho eseguito personalmente un'implementazione e ho trovato runtime di 1/14 e 1/8 dell'hardware sulla mia macchina.

Spero che questo aiuti!

PS: Se si esegue questa operazione da soli, è possibile refactoring il metodo lento/accurato per evitare una moltiplicazione e lieve miglioramento rispetto alla versione di Nick, ma non mi ricordo esattamente come ...

Answer 2

Se bisogno un'approssimazione sinusoidale ottimizzata per la precisione assoluta oltre -π ... π, uso:

x * (1 + x * x * (-0.1661251158026961831813227851437597220432 + x * x * (8.03943560729777481878247432892823524338e-3 + x * x * -1 .4941402004593877749503989396238510717e-4))

Può essere implementato con:

float xx = x * x; 
float s = x + (x * xx) * (-0.16612511580269618f + xx * (8.0394356072977748e-3f + xx * -1.49414020045938777495e-4f)); 

E forse optimized depending on the characteristics of your target architecture. Inoltre, non annotato nel post del blog collegato, se si sta implementando questo in assembly, utilizzare l'istruzione FMADD. Se si implementa in C o C++, se si utilizza, ad esempio, la funzione standard C99 fmaf(), assicurarsi che sia generato FMADD. La versione emulata è molto più costosa di una moltiplicazione e di un'aggiunta, perché ciò che fa fmaf() non è esattamente equivalente alla moltiplicazione seguita dall'addizione (quindi sarebbe scorretto implementarla semplicemente così).

La differenza tra sin (x) e detti polinomiale tra grafici -π e ¸ così:

Il polinomio è ottimizzato per ridurre la differenza tra questo e sin (x) tra -π e π, non solo qualcosa che qualcuno pensava fosse una buona idea.

Se è necessario solo l'intervallo di definizione [-1 ... 1], il polinomio può essere reso più preciso in tale intervallo ignorando il resto. Esecuzione the optimization algorithm ancora per questo intervallo di definizione produce:

x * (1 + x * x * (-1.666659904470566774477504230733785739156e-1 + x * x * (8.329797530524482484880881032235130379746e-3 + x * x * (- 1.928379009208489415662312713847811393721e-4)))

il grafico errore assoluto:

Se questo è troppo preciso per voi, è possibile optimize a polynomial of lower degree for the same objective Poi l'errore assoluto sarà più grande, ma vi farà risparmiare una moltiplicazione o due..