performance - threads - thread informatica




Directory walker sui sistemi operativi moderni più lento quando è multi-thread? (4)

Una volta ho avuto la teoria che sui moderni sistemi operativi l'accesso in lettura multithread sull'HDD dovrebbe funzionare meglio.

Ho pensato che:
il sistema operativo accoda tutte le richieste di lettura e le riorganizza in modo tale da poter leggere dall'HDD in modo più sequenziale. Più richieste otterrebbero, meglio sarebbe in grado di riorganizzarle per ottimizzare la sequenza di lettura.
Ero molto sicuro di averlo letto da qualche parte poche volte.

Ma ho fatto un po 'di benchmarking, e ho dovuto scoprire che l'accesso in lettura multithread per lo più ha prestazioni molto peggiori e non ha prestazioni migliori.

Ho avuto l'esperienza sotto Windows e Linux. Ho confrontato la ricerca pura dei file usando gli strumenti del sistema operativo, e avevo anche scritto dei propri piccoli benchmark.

Mi sto perdendo qualcosa?
Qualcuno può spiegarmi i segreti di questo argomento?
Grazie!


A quanto pare stai facendo saltare la testina di lettura dappertutto. Il collo di bottiglia è il disco, non il processore.

Per riformulare, la CPU potrebbe essere parallela ma il disco non lo è.


Che tu stia vedendo o meno l'aumento della velocità dipenderà quasi sicuramente dallo scenario che stai guardando e dall'hardware. Maggiori dettagli sulla tua metodologia di benchmark sarebbero utili qui.

A un livello grossolano, l'opportunità di un aumento di velocità si verifica quando non si utilizza il throughput massimo del controller di I / O e le sue cache o quando si sovrappone l'I / O con il lavoro intensivo della CPU e sono bloccati l'un l'altro.

Stai confrontando le letture di più file di piccole dimensioni sparsi nel sistema o semplicemente leggendo alcuni file di grandi dimensioni in sequenza? Vedrai le diverse caratteristiche di prestazione qui.

Hai profilato con un buon profiler di sistema come il toolkit di prestazioni (gratuito) di Windows per vedere cosa sta succedendo nei tuoi benchmark? Questo è praticamente un must.

Questo tipo di benchmark può essere molto divertente da scrivere e profilare, non lasciare che qualche falsa partenza interferisca con la ricerca di accelerazioni.

-Rick


Penso che tu stia parlando di accodamento nativo dei comandi, che potrebbe essere abilitato o meno sul sistema con cui stai provando. Dalla voce di Wikipedia :

In effetti, i nuovi kernel Linux mainstream supportano AHCI in modo nativo. Windows XP richiede l'installazione di un driver specifico del fornitore anche se AHCI è presente sull'adattatore bus host. Windows Vista supporta nativamente sia AHCI che NCQ. FreeBSD supporta completamente AHCI e NCQ dalla versione 8.0.

Inoltre, non ho eseguito alcun test, ma NCQ potrebbe non essere così efficace per una directory walk che deve accedere a file / inode di piccole dimensioni su tutto il disco. Potrebbe essere che il controller del disco sia in grado di soddisfare ogni richiesta abbastanza velocemente da non riuscire a creare una coda per riordinarla, quindi non si vedrà alcun beneficio.


Probabilmente qui è importante dividere la lettura della directory o delle informazioni del file dall'elaborazione di tali informazioni. In altre parole, l'IO del disco in un thread, l'elaborazione e la ricerca in un altro. Passare le informazioni I / O completate al thread di elaborazione con una coda limitata. In questo modo ti assicurerai che il tuo thread IO non stia mai aspettando l'elaborazione dei risultati prima di essere impegnato nella lettura del prossimo blocco di dati da elaborare.





parallel-processing