Kiedyś na forum zapytałem czy może być tak, że poniższy wynik nie będzie 4

var a = 2;
var b = a + 2;
print(b)

Jednym z powodów mógłby być cosmic ray, ale ostatnio Google podrzucił ciekawy papier - Cores that don't count.

Mianowicie - jako że Google ma wiele procków w swojej flocie, to zauważyli, że od czasu do czasu pojawiają im się tzw. "mercurial cores" - czyli rdzeń procesora, który np. dla danej instrukcji liczy źle oraz robi to "pocichu".

Mamy zatem procesor w którym to np. 3 rdzenie liczą OK, ale czwarty już źle.

Tutaj przykłady do czego m.in takie uszkodzone rdzenie mogą doprowadzić

Violations of lock semantics leading to application data-corruption and crashes.
Data corruptions exhibited by various load, store, vector,and coherence operations.
A deterministic AES miscomputation, which was “self-inverting”: encrypting and decrypting on the same core yielded the identity function, but decryption elsewhere yielded gibberish.
Corruption affecting garbage collection, in a storage system, causing live data to be lost.
Database index corruption leading to some queries, depending on which replica (core) serves them, being non-deterministically corrupted.
Repeated bit-flips in strings, at a particular bit position(which stuck out as unlikely to be coding bugs)
Corruption of kernel state resulting in process and kernel crashes and application malfunctions

Jako czynniki wpływające na pojawianie się "mercurial cores" podejrzewa się m.in:

Upływ czasu
Steady increases in CPU scale and complexity
Silicon feature sizes are now measured in nanometers,leaving smaller margins for error, and perhaps morerisk of post-burnin (latent) failures.
Novel techniques, such as stacked layers, add complexity and manufacturing risks.
Temperature, frequency, and voltage all play roles, but their impact varies: e.g., some mercurial core CEE rates are strongly frequency-sensitive, some aren’t. Dynamic Frequency and Voltage Scaling (DFVS) causes frequency andvoltage to be closely related in complex ways, one of several reasons why lower frequency sometimes (surprisingly) increases the failure rate

Czyli zatem co, czy procki będą dalej iść w tym kierunku i nawet w kród appkach będziemy rozkładać obliczenia na N rdzeni i głosować za wynikiem jak w kosmosie? :)

a może jakieś radykalne zmiany po stronie OSów, kompilatorów, czy vendorów procków (w papierze wspominali o Design-for-test, to make it easier to detect cores with subtle manufacturing defects, and exposing these test features to end users (for “scrubbing” in-service machines);)

może trzeba będzie wrócić do podejścia bardziej MainFrameowego, aby zamiast unreliable hardware łatać softwarowo, to jednak postarać się zrobić go jak najbardziej reliable?

jak dobrze że człowiek robi backupy, bo płakałbym jak @furious programming że ktoś wątek usunął i musiałbym od nowa pisać