Jak często procesory popełniają błędy obliczeniowe?

W notatkach Dijkstry na temat programowania strukturalnego dużo mówi o sprawdzalności programów komputerowych jako bytów abstrakcyjnych. W związku z tym zauważa, że ​​testowanie nie wystarczy. Na przykład zwraca uwagę na fakt, że niemożliwe byłoby przetestowanie funkcji mnożenia f (x, y) = x * y dla dowolnych dużych wartości xiy we wszystkich zakresach xiy. Moje pytanie dotyczy jego misc. uwagi na temat „kiepskiego sprzętu”. Wiem, że esej został napisany w latach 70., kiedy sprzęt komputerowy był mniej niezawodny, ale komputery wciąż nie są idealne, więc czasami muszą popełniać błędy obliczeniowe . Czy ktoś wie, jak często to się zdarza lub czy są na to statystyki?

Pomijając rzeczywiste / rzeczywiste błędy w projekcie procesora, myślę, że szukasz tego SO Pytanie: Cosmic Rays. Jakie jest prawdopodobieństwo, że wpłyną one na program . Nie mogę uzyskać cytatów, ponieważ SO jest ponownie blokowane w pracy tutaj ( westchnienie ).

Ignorując powyższe, wydaje mi się, że pamiętam kilka błędów obliczeniowych FPU we wczesnych Pentium, więc z pewnością nie są one nieomylne.

Nie mam pod ręką żadnych twardych dowodów, ale moje przeczucie mówi mi, że powinieneś być bardziej zaniepokojony uszkodzeniem części pamięci podręcznej / pamięci RAM / dysku niż błędem obliczeń.

Dużym problemem w odpowiedzi na to pytanie jest obecnie to, że producenci procesorów pakują erratę dla układu w umowę NDA (NonDisclosure Agreement). Intel to robi, IIRC.

Wielu mniej tajnych producentów wprowadza poprawki do arkusza danych, ale nie mówi ci, co się zmieniło, więc jeśli nie masz ochoty porównać wszystkich 300 stron, trudno ci będzie powiedzieć.

W procesorach pojawiło się wiele złych instrukcji. Oglądanie raportu jądra Linuxa, który znajduje przy starcie, jest średnio interesujące.

Bardzo pokrewny jest papierowy błąd Google dotyczący błędów pamięci, są one częstsze niż myślisz. „Błędy pamięci DRAM w środowisku naturalnym: badanie terenowe na dużą skalę” Schoeder, Pinheiro i Weber Pierwotnie opublikowane w ACM SIGMETRICS w 2009 r. Opublikowane ponownie w komunikacie ACM, luty 2011 r.

Wszystkie te błędy pamięci oznaczają dla ciebie pytanie, że bez pamięci ECC i tak otrzymasz błędne obliczenia.

Kiedy pracowałem dla dostawcy sprzętu, twierdzono, że żaden wbudowany procesor nie był wolny od błędów. I to tylko błędy logiczne. Zazwyczaj producent znajduje większość z nich i albo odpowiada procesorowi, albo odnajduje ustawienia BIOS, które go otaczają. Ale oprócz tego, że takie rzeczy, jak promienie kosmiczne, czasami odwracają nieco pamięć (a pamięć zwykle ma bity parzystości lub obwody SECDED, aby ocalić bekon), zawsze istnieje skończona szansa, że ​​fragment zostanie odczytany nieprawidłowo. Zauważ, że bity nie są prawdziwymi zerami i jedynymi logicznymi, ale hałaśliwymi rzeczami, takimi jak napięcia i prądy, a biorąc pod uwagę skończony hałas w systemie, zawsze istnieje szansa, że ​​odczytany zostanie niewłaściwy bit. W dawnych czasach (jako programista aplikacji) znalazłem kilka błędów sprzętowych - zarówno złej logiki, jak i jednostki X w CPU Y czasami daje mi zły typ wyniku, czas, aby chłopaki z HW zastąpili odmianę żetonów. Rzeczywiste obwody dryfują z czasem i użytkowaniem, a jeśli twój szykuje się do awarii, możesz zacząć wykrywać błędy bitów, szczególnie jeśli podkręcasz lub w inny sposób przekraczasz zalecany zakres działania.

Jest to prawdziwy problem w przypadku superkomputerów, w których rozważane są obliczenia obejmujące 1e18 lub więcej operacji zmiennoprzecinkowych.

Poniższa treść może dotyczyć błędów obliczeniowych w procesorach graficznych.

Biorąc pod uwagę wystarczająco dużo czasu, Intel i7-3610QM i Nvidia GeForce GTX 660 nie będą się ze sobą zgadzać, biorąc pod uwagę te same instrukcje. (cuda 5.5, compute_20, sm_20)

Pozostaje zatem stwierdzić, że jeden z nich popełnia błąd.

Podczas testu porównawczego studium wykonalności symulacji cząstek zauważyłem, że po tysiącu transformacji o podwójnej precyzji (transformacje, w tym sin, cos, mnożenie, dzielenie, dodawanie i odejmowanie) zaczęły pojawiać się błędy.

Dam ci mały fragment liczb do porównania (pierwszy numer to zawsze procesor, drugi procesor graficzny)

-1.4906010142701069
-1.4906010142701074

-161011564.55005690
-161011564.55005693

-0.13829959396003652
-0.13829959396003658

-16925804.720949132
-16925804.720949136

-36.506235247679221
-36.506235247679228

-3.3870884719850887
-3.3870884719850896

(zauważ, że nie każda sekwencja transformacji powoduje błąd)

Chociaż maksymalny błąd jest prawie nieistotny (0.0000000000000401%), nadal istnieje i przyczynia się do błędu skumulowanego.

Teraz ten błąd może wynikać z różnicy w implementacji jednej z wewnętrznych bibliotek. Rzeczywiście wygląda na to, że GPU woli zaokrąglać w dół lub obcinać tam, gdzie procesor zaokrągla w górę. Co ciekawe, wydaje się, że dzieje się tak tylko w przypadku liczb ujemnych.

Chodzi o to, że identyczne instrukcje niekoniecznie gwarantują identyczne wyniki, nawet na urządzeniach cyfrowych.

Mam nadzieję, że to się przyczyniło.

EDYCJA jako sidenote: W przypadku błędów arytmetycznych GPU, to (ctrl + f „Pierwszy GPU z obsługą pamięci ECC”) może również być interesujące, choć niekoniecznie związane z powyższymi błędami.

Pod względem tego, co uważasz za rzeczywisty „procesor” (jednostki wykonawcze, potok .. itd.), Prawie nigdy się to nie dzieje. Znany był problem z jednym ze smaków Pentium jakiś czas temu, ale to jedyny, o jakim kiedykolwiek słyszałem. Teraz, jeśli weźmie się pod uwagę układy scalone wbudowane w procesory lub przynajmniej takie samo opakowanie, takie jak kontrolery USB, TSEC, kontroler DMA lub kontroler pamięci, istnieje wiele błędów. Wątpię jednak, aby istniały jakiekolwiek dane statystyczne na ten temat.

Kolejny „kiepskie hardware” kwestią do rozważenia w tym kontekście jest fakt, że zmiennoprzecinkowych sprzęt jest z natury „stratny”: ma ograniczoną dokładność iz dostatecznie dużych ilościach (patrz powrotem do pierwotnego Dijkstra cudzysłów) nie będzie w stanie odróżnić xi x + 1, a nawet x + 1000000. Można uzyskać „nieskończone” precyzyjne biblioteki zmiennoprzecinkowe, ale są one powolne i ostatecznie wciąż ograniczone dostępną pamięcią.

Krótko mówiąc, Dijkstra działał w dziedzinie teorii, a prawdziwy sprzęt / oprogramowanie nie pasuje zbyt dobrze do ideałów teoretycznych. (Pamiętaj, że oryginalna „maszyna Turinga” określała nieskończoną taśmę papierową.)