Con quale frequenza le CPU commettono errori di calcolo?

Errori reali / reali a parte il design di una CPU, penso che tu stia cercando questa domanda SO: Raggi cosmici. Qual è la probabilità che influenzeranno un programma . Non riesco a ottenere le virgolette perché SO è di nuovo bloccato al lavoro qui ( sigh ).

Ignorando quanto sopra, mi sembra di ricordare che c'erano alcuni bug di calcolo FPU nei primi Pentium, quindi sicuramente non sono infallibili.

Non ho prove concrete a portata di mano, ma il mio istinto mi dice che probabilmente dovresti essere più preoccupato dei bit di Cache / RAM / Il disco viene corrotto e il calcolo non è corretto.

Un grosso problema nel rispondere a questa domanda in questi giorni è che i produttori di CPU avvolgono l'errata per il chip in un accordo di non divulgazione (NDA). Intel lo faccia, IIRC.

Molti produttori meno riservati emettono correzioni al foglio dati, ma non ti dicono cosa è cambiato, quindi a meno che non ti piaccia confrontare tutte le 300 pagine, ti sarà difficile dirlo.

Ci sono state molte cattive istruzioni nella CPU, guardando un rapporto sul kernel di Linux che quelli che trova all'avvio sono moderatamente interessanti.

Molto correlato è il documento di Google sugli errori di memoria, sono più comuni di quanto si pensi. "Errori di DRAM in the wild: uno studio sul campo su larga scala" Schoeder, Pinheiro e Weber Originariamente pubblicato su ACM SIGMETRICS nel 2009. Ripubblicato in Comunicazioni dell'ACM Febbraio 2011

Che cosa significano tutti questi errori di memoria per te, è che senza la memoria ECC otterrai comunque calcoli errati.

Quando ho lavorato per un fornitore di hardware, è stato affermato che nessuna CPU mai costruita era priva di bug. E questo è solo un bug logico. Di solito il produttore ne trova la maggior parte e rispetta il chip o trova le impostazioni del BIOS che le aggirano. Ma oltre al fatto che cose come i raggi cosmici occasionalmente si girano un po 'in memoria (e la memoria di solito ha bit di parità o circuiti SECDED per salvare il bacon), c'è sempre una possibilità finita che un po' venga letto in modo errato. Si noti che i bit non sono veri e propri zero logici, ma cose rumorose come tensioni e correnti e dato il rumore finito nel sistema c'è sempre la possibilità che un bit sbagliato venga letto. Ai vecchi tempi (come programmatore di app), ho trovato alcuni bug HW - entrambi del tipo di cattiva logica, e l'unità X nella CPU Y mi dava occasionalmente un cattivo risultato, tempo di rimpiazzare i ragazzi HW una varietà di chip. I circuiti effettivi vanno alla deriva con il tempo e l'uso, e se il tuo si sta preparando a fallire, potresti iniziare a raccogliere errori di bit, specialmente se stai overclockando o altrimenti superando il range operativo consigliato.

È un vero problema per il supercomputing, in cui sono contemplati calcoli che invalgano 1e18 o più operazioni in virgola mobile.

Il seguente contenuto potrebbe riguardare errori di calcolo in GPU.

Dato un tempo sufficiente, Intel i7-3610QM e una Nvidia GeForce GTX 660 non saranno d'accordo tra loro date le stesse istruzioni. (cuda 5.5, compute_20, sm_20)

Quindi, uno è lasciato a concludere che uno dei due fa un errore.

Durante un benchmark di studio di fattibilità di simulazione di particelle ho notato che dopo un migliaio di trasformazioni di precisione doppia (trasformazioni tra cui sin, cos, moltiplicazione, divisione, addizione e sottrazione) gli errori hanno iniziato a insinuarsi.

Ti darò un piccolo estratto di numeri da confrontare (il primo numero è sempre CPU, seconda GPU)

-1.4906010142701069
-1.4906010142701074

-161011564.55005690
-161011564.55005693

-0.13829959396003652
-0.13829959396003658

-16925804.720949132
-16925804.720949136

-36.506235247679221
-36.506235247679228

-3.3870884719850887
-3.3870884719850896

(nota che non tutte le sequenze di trasformazione producono un errore)

Mentre l'errore massimo è quasi trascurabile, (0.0000000000000401%) esiste ancora e contribuisce all'errore cumulativo.

Ora questo errore potrebbe essere dovuto a una differenza nell'implementazione di una delle librerie intrinseche. In effetti, sembra che la GPU preferisca arrotondare o troncare il punto in cui la CPU si arrotonda. Stranamente, questo sembra accadere solo sui numeri negativi.

Ma il punto è che le stesse istruzioni non sono necessariamente garantite per restituire risultati identici, anche su macchine digitali.

Spero che questo abbia contribuito.

EDIT come sidenote: Nel caso degli errori aritmetici GPU, questo (ctrl + f "Prima GPU con supporto memoria ECC ") potrebbe anche essere di interesse, anche se non necessariamente pertinente agli errori di cui sopra.

In termini di ciò che consideri la "CPU" attuale (unità di esecuzione, pipeline..ect), praticamente non succede mai. C'è stato un problema noto con uno dei sapori Pentium qualche tempo fa, ma questo è l'unico che io abbia mai sentito nominare. Ora, se si considerano gli insiemi di chip incorporati nei processori o almeno lo stesso imballaggio di tali controller USB, TSEC, controller DMA o controller di memoria, ci sono un sacco di errori. Dubito che ci sia qualche tipo di dati statistici a riguardo.

Un altro problema di "hardware scadente" da considerare in questo contesto è che l'hardware in virgola mobile è intrinsecamente "lossy": ha una precisione limitata e con numeri sufficientemente grandi (fare riferimento alla citazione Dijkstra originale) non sarà possibile distinguere tra x e x + 1 , o anche x + 1000000 . Puoi ottenere librerie in virgola mobile di precisione "infinita", ma sono lente e alla fine ancora limitate dalla memoria disponibile.

In breve, Dijkstra stava lavorando nel campo della teoria, e il vero hardware / software non si adatta molto bene agli ideali teorici. (Ricorda, la "macchina di Turing" originale ha specificato un nastro di carta infinito.)