Perché la velocità di questo risolutore SOR dipende dall'input?

Question

Relativo al mio other question, ora ho modificato il solutore matrice sparse per utilizzare il metodo SOR (Successive Over-Relaxation). Il codice è ora la seguente:

void SORSolver::step() { 
    float const omega = 1.0f; 
    float const 
     *b = &d_b(1, 1), 
     *w = &d_w(1, 1), *e = &d_e(1, 1), *s = &d_s(1, 1), *n = &d_n(1, 1), 
     *xw = &d_x(0, 1), *xe = &d_x(2, 1), *xs = &d_x(1, 0), *xn = &d_x(1, 2); 
    float *xc = &d_x(1, 1); 
    for (size_t y = 1; y < d_ny - 1; ++y) { 
     for (size_t x = 1; x < d_nx - 1; ++x) { 
      float diff = *b 
       - *xc 
       - *e * *xe 
       - *s * *xs - *n * *xn 
       - *w * *xw; 
      *xc += omega * diff; 
      ++b; 
      ++w; ++e; ++s; ++n; 
      ++xw; ++xe; ++xs; ++xn; 
      ++xc; 
     } 
     b += 2; 
     w += 2; e += 2; s += 2; n += 2; 
     xw += 2; xe += 2; xs += 2; xn += 2; 
     xc += 2; 
    } 
} 

Ora la cosa strana è: se io aumento omega (il fattore di rilassamento), la velocità di esecuzione inizia a dipendere drammaticamente sui valori all'interno delle varie matrici!

Per omega = 1.0f, il tempo di esecuzione è più o meno costante. Per omega = 1.8, la prima volta, in genere occorrono, per esempio, 5 millisecondi per eseguire questo step() 10 volte, ma questo gradualmente aumenterà fino a circa 100 ms durante la simulazione. Se imposto lo omega = 1.0001f, vedo un leggero aumento dei tempi di esecuzione; più alto è il omega, più veloce sarà il tempo di esecuzione durante la simulazione.

Poiché tutto questo è incorporato nel solutore di fluidi, è difficile trovare un esempio indipendente. Ma ho salvato lo stato iniziale e rieseguito il risolutore in quello stato ogni volta che passo, oltre a risolvere il passo temporale attuale. Per lo stato iniziale era veloce, per le successive fasi temporali più lentamente. Poiché tutto il resto è uguale, ciò dimostra che la velocità di esecuzione di questo codice dipende dai valori in questi sei array.

Questo è riproducibile su Ubuntu con g ++, così come su Windows 7 a 64 bit durante la compilazione per 32-bit con VS2008.

Ho sentito che i valori NaN e Inf possono essere più lenti per i calcoli in virgola mobile, ma non ci sono né NaN né Infs. È possibile che la velocità dei calcoli mobili dipenda altrimenti dai valori dei numeri di input?

Answer 1

La risposta breve alla tua ultima domanda è "sì" - i numeri denormalizzati (molto vicini allo zero) richiedono una gestione speciale e possono essere molto più lenti. La mia ipotesi è che si stanno insinuando nella simulazione col passare del tempo. Vedere questo post SO correlato: Floating Point Math Execution Time

L'impostazione del controllo a virgola mobile per svuotare i denormali a zero dovrebbe occuparsi di cose con un'imitazione trascurabile sulla qualità della simulazione.

Answer 2

celion's answer risulta essere quello corretto. Il post si collega alla dice per accendere filo a zero dei valori denormalizzati:

#include <float.h> 
_controlfp(_MCW_DN, _DN_FLUSH); 

Tuttavia, questo è solo per Windows. Utilizzando gcc su Linux, ho fatto la stessa cosa con un soffio di assembly inline:

int mxcsr; 
__asm__("stmxcsr %0" : "=m"(mxcsr) : :); 
mxcsr |= (1 << 15); // set bit 15: flush-to-zero mode 
__asm__("ldmxcsr %0" : : "m"(mxcsr) :); 

Questo è il mio primo assembly x86 mai, in modo che possa probabilmente essere migliorato. Ma fa il trucco per me.