Le unità a stato solido sono sufficientemente potenti da non preoccuparsi dei colli di bottiglia del disco IO?

Question

Ho un programma di proof-of-concept che sta facendo alcune comunicazioni tra interpreti semplicemente scrivendo e leggendo dall'HD. Sì, so che questo è veramente lento; ma era il modo più semplice per far funzionare le cose. Avevo sempre programmato di tornare indietro e scambiare quella parte del codice con un meccanismo che fa tutto l'IPC (comunicazione tra processi) nella RAM.

Con l'arrivo di dischi a stato solido, pensate che il collo di bottiglia rischia di diventare trascurabile?

Note: è un software server scritto in C# che chiama alcune librerie di crunch di numeri bare metal scritte in FORTRAN.

Answer 1

La risposta breve è probabilmente no. Un famoso ricercatore di nome Jim Gray ha tenuto un discorso su archiviazione e prestazioni che includeva this great analogy. Supponendo che il tuo cervello sia il processore, l'accesso a un registro richiede 1 tick dell'orologio (numeri a sinistra) che equivale approssimativamente a quell'informazione nel tuo cervello. L'accesso alla memoria richiede 100 tick di clock, quindi equivale all'incirca a ottenere dati da qualche parte nella città in cui vivi. L'accesso a un disco standard richiede all'incirca 10^6 tick, che è l'equivalente dei dati presenti su Plutone. Dove si trova lo stato solido? L'attuale tecnologia SSD è compresa tra 10^4-10^5 a seconda di chi chiedi. Mentre possono essere più veloci di un ordine di grandezza, c'è ancora un enorme divario tra la lettura dalla memoria e la lettura dal disco. Questo è il motivo per cui la risposta alla tua domanda è probabilmente no, poiché con la stessa rapidità con cui gli SSD diventano, saranno comunque molto più lenti del disco (almeno nel prossimo futuro).

Answer 2

Penso che i colli di bottiglia siano appena spostati. Poiché prevediamo un throughput più elevato, scriviamo programmi con richieste più elevate.

Questo spinge i colli di bottiglia a bus, cache e parti diversi dal meccanismo di lettura/scrittura (che è comunque l'ultimo della catena).

Con un processo non vincolato dall'I/O del disco, quindi penso che potresti trovarlo vincolato dallo scheduler che limita la quantità di istruzioni di lettura/scrittura (come con tutte le istruzioni di processo).

Per sfruttare appieno la velocità I/O illimitata, è necessaria una risposta in tempo reale e una gestione molto aggressiva delle cache e così via.

Quando dischi diventano più veloci poi così fa RAM e processori e la domanda sui dispositivi. Il collo di bottiglia è lo stesso, il carico di lavoro diventa più grande.

Answer 3

Non credo che cambierà il modo in cui le applicazioni con I/O sono scritte il più piccolo possibile. Avere processori più veloci non ha fatto sì che la gente scelga bubblesort come algoritmo di ordinamento.

Le gerarchie di memoria esterna sono un problema intrinseco dell'informatica.

Answer 4

Joel on Software ha un article sulla sua esperienza di aggiornamento a stato solido. Non è esattamente lo stesso problema che hai, ma il mio take-away è stato:

Le unità a stato solido possono velocizzare significativamente le operazioni legate all'I/O, ma molte cose (come la compilazione) sono ancora vincolate alla cpu.

Answer 5

ma era il modo più semplice per mettere tutto in funzione. Di solito trovo che sia molto più economico pensare bene una volta con la tua testa, piuttosto che far pensare la CPU milioni di volte inutilmente.

Answer 6

unità a stato solido fanno fare un miglioramento importante IO throughput e cioè il fatto che su dischi allo stato solido, blocco frazione è meno di un problema da un supporto rotante. Ciò significa che le applicazioni con limiti di IO ad alte prestazioni possono spostare l'attenzione dalle strutture che organizzano i dati a cui si accede per strutture che ottimizzano l'IO in altri modi, ad esempio mantenendo i dati in un singolo blocco mediante compressione. Detto questo, anche le unità a stato solido beneficiano di schemi di accesso lineari perché possono precedere i blocchi successivi in ​​una cache di lettura prima che l'applicazione lo richieda.

Una regressione evidente sul dischi a stato solido è che le scritture richiedono più tempo di legge, anche se entrambi sono ancora generalmente più veloce rispetto ai dischi rotanti, e la differenza è restringimento con nuovi, di fascia alta dischi a stato solido.

Answer 7

Ho un'unità a stato solido, e no, questo non eliminerà l'I/O come collo di bottiglia. L'SSD è bello, bit non è quello bello.

In realtà non è difficile padroneggiare i primitivi IPC del sistema o creare qualcosa su TCP. Ma se vuoi mantenere il tuo roba del disco e renderlo più veloce, ramdisk o tmpfs potrebbe fare il trucco.

Answer 8

No, purtroppo no. Lo rendono comunque più interessante: le unità SSD hanno letture molto veloci e senza tempi di sincronizzazione, ma le loro scritture sono quasi lente come i normali dischi rigidi. Ciò significa che vorrai leggere la maggior parte del tempo. Tuttavia, quando scrivi sull'unità, dovresti scrivere il più possibile nello stesso punto, poiché le unità SSD possono scrivere solo interi blocchi alla volta.

Answer 9

No. Gli attuali SSD sono progettati come sostituti del disco. Ogni livello, dal controller SATA al driver del filesystem, li tratta come storage.

Questo non è un problema della tecnologia di base, il flash NAND. Quando la memoria flash NAND viene mappata direttamente nella memoria e utilizza un sistema di memorizzazione del registro rotante invece di un file system basato su file nominati, può essere abbastanza veloce. Il problema fondamentale è che NAND Flash funziona solo bene negli aggiornamenti di blocco. Gli aggiornamenti dei metadati dei file causano costose operazioni di lettura-modifica-scrittura. Inoltre, i blocchi NAND sono molto più grandi dei tipici blocchi del disco, il che non aiuta nemmeno le prestazioni.

Per questi motivi, il futuro degli SSD sarà un SSD con cache migliore. La DRAM nasconderà il sovraccarico di una mappatura scadente e un piccolo backup del supercond consentirà all'SD di eseguire il commit più rapidamente delle scritture.

Answer 10

Che ne dici di utilizzare un'unità RAM al posto del disco? Non dovresti riscrivere nulla. Basta puntarlo su un diverso file system. Windows e Linux hanno entrambi. Assicurati di avere molta memoria sulla macchina e crea un disco virtuale con spazio sufficiente per l'elaborazione. L'ho fatto per un sistema che ascoltava più protocolli su un tocco di rete. Non ho mai aggiornato il pacchetto che stavo per ottenere e c'erano troppi dati per tenerlo in memoria. Vorrei scriverlo sul disco RAM e quando qualcosa è stato completato, vorrei spostarlo e lasciare che un altro processo farlo fuori dalla RAM e su un disco fisico. In questo modo sono riuscito a tenere il passo con le schede di rete di classe server molto occupate. In bocca al lupo!

Answer 11

Qualcosa da tenere a mente:

Se la comunicazione comporta frequenti messaggi ed è sullo stesso sistema si otterrà molto buone prestazioni perché Windows non sarà effettivamente scrivere i dati in primo luogo.

Ho dovuto ricorrere ad esso una volta e ho scoperto questo: la luce del drive ha fatto NON entrare nel tempo fintanto che i dati continuavano a essere scritti.