Il produttore / consumatore potrebbe farlo. Nei "vecchi tempi" veniva chiamato double-buffering, dove la CPU avvia il contenuto di un buffer mentre l'I / O si riempie l'altro.
Quello che devi fare è assicurarti che tutto l'hardware disponibile funzioni il più possibile, mantenendo la CPU e l'I / O occupati il più possibile.
Potrebbe essere che l'I / O memorizzato nel buffer lo faccia già per te.
Indipendentemente da ciò, non ha senso fare in modo che la CPU o l'I / O facciano qualcosa di non necessario.
Quindi, non importa cosa, farei il massimo della messa a punto delle prestazioni, tagliando il grasso.
Il metodo che uso è questo .
AGGIUNTO: solo per mostrare cosa intendo per BLAS, in particolare il DGEMM di routine moltiplicatore di matrice. Di solito si presume che sia alla velocità più vicina o vicina.
Forse è per un piccolo numero di moltiplicazioni di grandi matrici .
Nel mio caso, stavo facendo un gran numero di moltiplicazioni di piccole matrici, come 4x4 o 5x5.
Se prendessi un numero piccolo, come cinque, di campioni di stack a tempo casuale, vedrei qualcosa di simile su tre di essi:
...
in my code: CALL DGEMM ...
in DGEMM: nota = lsame(transa,'N')
...
Ciò significa che il 60% del tempo di esecuzione (molto approssimativamente) è stato speso controllando il flag di carattere transa per vedere se la matrice A doveva essere trasposta.
Sapevo che non lo era, ovviamente.
Come sistemarlo?
Scrivi la mia matrice-multiplo, in cui piccoli casi sono stati srotolati a mano, e casi importanti chiamavano DGEMM.
Se il tempo di esecuzione originale era 100 secondi, ora erano circa 40 secondi.
Questo è un rapporto di accelerazione di 100/40 = 2,5
Quindi lo stesso processo potrebbe essere ripetuto per trovare altro tipo di spreco.
Qualcos'altro avrebbe potuto essere responsabile solo del 20% dei tempi o degli anni '20, ma dopo aver ritagliato gli originali anni '60, è 20 secondi su 40 - facilmente individuabili.
Quindi il fixing che dà un ulteriore rapporto di accelerazione di 2.
Guarda come va?