In che modo i "numeri di latenza di Jeff Dean che ogni programmatore dovrebbe conoscere" possono essere precisi nel contesto di diverse implementazioni hardware?

Mi riferisco a questo grafico dei numeri di latenza , attribuito a Jeff Dean a Google.

La cosa che non capisco è che questi numeri non variano da un set di hardware all'altro? Come possono essere precisi per tutti i diversi tipi di RAM, CPU, scheda madre, disco rigido, ecc?

Questi numeri (elencati anche sulla Programmazione da soli di Norvig in 10 anni ) sono approssimativi, utili solo come (ordine di) grandezza.

In realtà, l'hardware di oggi (almeno per desktop o laptop) non varia molto anche tra un laptop economico da 300 € e una workstation di fascia alta da 10k €. La velocità varia al massimo di circa 2 o 4. Tale workstation può avere un disco più grande, più core, cache e RAM. Tuttavia, ciò non influisce molto sulle prestazioni raw a thread singolo.

Guarda alcune cifre su http://openbenchmarking.org/ o alcuni comparatori di CPU.

La cosiddetta legge di Moore sta morendo . Il mio desktop di 3+ ​​anni a casa (un i3770K) potrebbe essere sostituito (oggi, a marzo 2016) da un certo i6700 che è solo il 20% più veloce.

I numeri non sono fatti per essere precisi. Sono i rapporti tra gli ordini di grandezza tra i livelli che contano.

Tuttavia, quando appare una tecnologia dirompente (ad es. Cloud computing, Ethernet da 10 GB / 100 GB, nuovo modulo kernel di rete, reti di archiviazione SSD, virtualizzazione e containerizzazione), questi numeri possono essere invalidati a causa della comparsa, scomparsa o spostamento di nuovi livelli.

Quando si programma a un livello molto alto, in cui tutto il calcolo, la rete, l'analisi, ecc. Vengono eseguiti utilizzando librerie non scritte da soli, conoscere i dati sulle prestazioni delle operazioni di basso livello potrebbe non essere di grande aiuto, poiché l'opportunità di migliorare ogni le prestazioni della biblioteca sono piuttosto limitate o assolutamente impossibili.

Invece, leggi attentamente la documentazione relativa alle prestazioni di ciascuna libreria. Se una biblioteca non viene fornita con quelle, chiedi loro - rendile un problema. Oppure scopri come eseguire il benchmarking del software nel modo corretto.

Avere una conoscenza di base dei numeri di latenza è importante quando si viene assunti da un'azienda che progetta e produce componenti software. Confrontalo con un'azienda che progetta e produce automobili e tutti i componenti in essa contenuti: il proverbiale "reinventare la ruota" (gomma, pressione dei pneumatici, gradini, ecc.)

La maggior parte delle società di software non lavora a livello di componente: interi sistemi software funzionali possono essere costruiti mettendo insieme i componenti. Queste società di software non devono concentrarsi su come progettare i componenti in termini di latenze; devono invece valutare la qualità dei componenti che scelgono.

Per riassumere, (1) è molto probabile che non sia necessario conoscere i numeri di latenza; (2) a meno che tu non voglia essere assunto da un'azienda che produce componenti software (librerie), sia per la vendita che per uso interno (come in alcune delle più grandi società di software del mondo), (3) se hai bisogno di quei numeri, è compito tuo fare i benchmark tu stesso, in modo scientificamente corretto, altrimenti non dovresti lavorare su componenti software.

Nessuno ha affermato che questi numeri siano accurati per qualsiasi hardware.

Tuttavia, sono molto, molto più precisi delle ipotesi cieche. Questo è ciò su cui molte persone purtroppo basano il proprio codice.

Non sono perfettamente precisi e non sono realmente destinati ad essere.

Sono (specialmente sui numeri più piccoli) un po 'meglio del solo ordine di grandezza. Un altro punto è che può aiutare a capire quali cose sono vicine tra loro, che a volte le persone fraintendono come molto più distanti di quanto non siano realmente. Per un ovvio esempio, un bel po 'di persone presumono che la cattiva reputazione del ramo sia spesso una grande cosa. Esso può essere un grosso problema se è ripetuto un sacco, ma non è necessariamente la pena sacrificare una quantità enorme ovunque e ovunque solo per ottenere una migliore branch prediction (ad esempio, se si legge dalla memoria principale, o addirittura L2 cache per migliorare branch prediction, è probabilmente una perdita netta).

Allo stesso tempo, sì, gli ordini di grandezza possono essere le parti più utili. Ad esempio, ci vuole circa 100 volte più tempo per accedere ai dati dalla memoria principale che da un registro. Sì, su una macchina potrebbe essere circa 97 volte più lunga e su un'altra potrebbe essere più vicina a 127 volte più a lungo. Quasi sicuramente sarà più vicino a 100 che a 10 o 1000.

Personalmente, tenderei a pensare che la maggior parte di questi siano simili alle isole, per esempio, nell'Oceano Pacifico. Le velocità del disco rigido (ad esempio) potrebbero essere le isole Hawaii. Le velocità SSD sono le isole filippine. Questo sta mostrando la mappa su una scala abbastanza piccola da far sembrare ognuno di essi come un singolo punto. Se ingrandiamo, questo non è chiaramente vero, ma la distanza tra le due catene è molte volte maggiore delle distanze tra le isole in entrambe le catene.

Naturalmente i numeri non possono essere precisi per ogni macchina. E suppongo che non avrebbero mai dovuto. Tuttavia, mostrano differenze nell'ordine di grandezza tra diversi tipi di operazioni.

Potresti trovare alcuni link e dati più utili nei commenti dei tuoi dati collegati.