Ho letto che la selezione e la programmazione multi-thread erano modelli IO con basse prestazioni, ad esempio questo IBM developerworks article on high perfomance IO.Perché AIO è migliore dell'elaborazione IO selezionata e multi-thread?
Non riesco a capire come sincronizzare/sincronizzare: il blocco/non blocco sta migliorando le prestazioni. Perché AIO è l'opzione migliore qui?
Essere asincroni e/o non bloccanti non fornisce alcun incremento di velocità inerente alle singole operazioni IO all'interno di un sistema, se ci vuole x millisecondi per leggere dal disco che è ciò che richiederà.
Il vantaggio di questi approcci risulta vero in ambienti multi-thread (o ambienti in cui l'operazione può continuare nonostante l'IO ritardato) consentendo alle operazioni IO di essere effettivamente separate dal thread principale di esecuzione. L'aumento delle prestazioni percepito da questo è dovuto alla diminuzione del numero di risorse utilizzate per attendere semplicemente che IO ritorni o sblocchi.
In questo thread è disponibile un buon confronto tra asincrono e non blocco.
Potrebbe essere più di un 'thread principale di esecuzione', (vedi IOCP). AIO vince anche perché più lavoro viene spinto nel kernel e quindi riduce i cicli di apertura e la copia evitabile. –
In un ambiente con thread, è dannoso per un singolo thread bloccare più del necessario perché impedisce ad altri thread di funzionare. Per evitare che venga utilizzato l'IO asincrono non bloccante. Una libreria comune per questo è Boost.Asio.
Quando un singolo thread blocca indefinitamente per un "read" o "recv", non è che gli altri thread fanno in modo che la CPU calcoli .. ?? Ho pensato (sono ancora sotto l'impressione) che il thread debba abbandonare la CPU a meno che e fino a che il blocco non venga rimosso da una sorta di segnale dal kernel a questo thread .. –
Perché un thread threading blocca altri thread? Non può contenere mutex, ecc., o se lo fosse, non saresti in grado di scrivere lo stesso codice con AIO. – Rup
Considerate questo: quando il vostro programma raggiunge un punto in cui deve attendere che l'utente inserisca del testo, avete due scelte: aspettate finché non lo fa, e CPU non sta facendo nulla nel frattempo, oppure potete bloccare il programma corrente e usarlo CPU per fare altri calcoli utili. Dopo l'input dell'utente, puoi sbloccare il tuo programma e continuare. In questo modo potresti migliorare le prestazioni.
"hai due scelte: aspetta fino a che non lo fa, e CPU non sta facendo nulla nel frattempo" .. Non è che l'altro thread verrà chiamato implicitamente da allora ?? –
@AnerudhanGopal, beh, hai ragione, non è esattamente niente, anche gli altri thread avranno le loro possibilità, ma poiché il thread di I/O non è un blocco ogni volta che ne ha la possibilità, sprecherà CPU, fino a quando l'utente non inserirà qualcosa. – atoMerz
Il blocco di un intero processo mentre si attende il completamento di un singolo IO non è efficiente se ci sono altre cose che il processo potrebbe fare. AIO è un modo per consentire al processo di eseguire altre operazioni mentre il sistema è che fa IO per esso; il multithreading è un altro. La differenza tra utilizzando più thread o l'utilizzo di AIO è in gran parte di progettazione; in un tipico server , ad esempio, è molto più semplice utilizzare più thread, e non ci dovrebbero essere molte differenze nelle prestazioni. Per altre applicazioni , AIO potrebbe essere più semplice e/o fornire maggiori prestazioni. È un altro strumento da considerare, ma non si applica ovunque.
Trovo la domanda chiara. Il collegamento contiene il confronto di vari modelli di I/O e dice che 'AIO' è migliore di' select', che anch'io trovo dubbioso, soprattutto considerando alcuni degli esempi forniti contenenti un'attesa attesa 'while (aio_error (& my_aiocb) == EINPROGRESS); '. – avakar
@avakar: Diresti quindi che * performance * qui è correlato al tempo di esecuzione/reattività? –
@MatthieuM., Sì, è così che l'ho capito. – avakar