Perché non esiste un'interfaccia di query hardware ISO?

4

Attualmente sto leggendo un libro, un capitolo sull'I / O e mi è venuta in mente una domanda.

Fondamentalmente, quando si programma in C / C ++, si ha una straordinaria opportunità di ottimizzare il comportamento dell'hardware. Usando il buffering per i dispositivi a blocchi, usa streaming e I / O asincrono per dispositivi di rete ad alta latenza e così via.

E se stai scrivendo un'applicazione server destinata a applicazioni con carichi elevati, e puoi ottimizzare i dispositivi I / O, ciò può davvero cambiare enormemente i requisiti hardware. Supponiamo che tu sappia che la cache dell'HDD è di circa 32MB, e che ama lo streaming di dati in blocchi da 8MB, e hai 16GB di RAM che sono economici e inattivi, potresti usare solo% di basso livello% con un buffer da 8MB e fare con esso. Il che toglierebbe tonnellate di lock e user > kernel- > le transizioni utente causate da letture più piccole, diciamo 64 KB ciascuna.

Il problema è che, in pratica, devi eseguire il programma sulla piattaforma di destinazione per ottenere i dati effettivi sulle prestazioni e ottimizzare per questo. E se porti quell'applicazione per dire ARM, le ottimizzazioni possono persino ritorcersi contro.

Quindi, perché non ci sono API per ottenere i valori di sweet-spot per l'architettura su cui stai lavorando.

_read , QueryOptimalHddReadBuffer , QueryOptimalHddWriteBuffer , QueryHddSeekTimeCharacteristics , ecc.

    
posta Coder 10.10.2011 - 02:17
fonte

1 risposta

4

Suppongo che ci siano fondamentalmente due motivi. Prima di tutto, immagino che nessuno abbia nemmeno tentato di presentare una proposta per qualcosa di simile in una forma che il comitato potrebbe persino sperare di accettare, se lo volessero.

Secondo (e probabilmente secondariamente), sospetto che ci sia un atteggiamento secondo cui l'implementazione può e dovrebbe fare la maggior parte di tale ottimizzazione più o meno automaticamente. Per utilizzare il tuo esempio, c'è un motivo _read non standardizzato da C o C ++ e fread è invece standardizzato: consente l'implementazione di eseguire il buffering, quindi invece di eseguire query per la dimensione di lettura ottimale per il sistema, dovrebbe solo fare la dimensione di lettura ottimale automaticamente. Mi rendo conto che ciò che sceglie non è ottimale per tutti gli scopi, ma dubito che un QueryOptimalHDDReadBuffer (ecc.) Sia necessariamente migliore.

    
risposta data 10.10.2011 - 04:40
fonte

Leggi altre domande sui tag