Ciao Michele, concordo con il tuo ragionamento e faccio un passo oltre, tra il processore e la RAM ci sono un paio di strati di cache, per portare il processore al 100% dati e istruzioni devono essere interamente contenuti nella cache. Un semplice script bash che somma all'infinito due numeri potrebbe essere sufficiente.
-- Gianluca On May 13, 2016 8:14 PM, "Michele Ripamonti" <[email protected]> wrote: > Secondo me in entrambi i casi non si riesce a spingere il tempo di CPU al > 100%. > Nel caso di dd if=/dev/zero of=/dev/null , probabilmente ciò che si > ottiene dopo il ctrl^c è semplicemente il throughput della ram del sistema. > Penso che la cpu sprechi un sacco di cicli di clock in attesa delle > read/write, seppur farlocche. In soldoni, se semplicemente sostituendo la > cpu con una più performante, si ottiene lo stesso throughput da dd, il > processore non è impegnato al massimo, la ram fa da collo di bottiglia. > > Non ho provato ma da top si trovrebbe vedere lo spaccato cpu/io sui core. > > È venerdì sera e sono stanco, potrei aver sparato cazzate enormi, se fosse > questo il caso, per favore correggetemi :-) > Il 13/Mag/2016 09:16, "zad zad" <[email protected]> ha scritto: > >> Caro Antonio, prima di additare gli altri dovresti rivedere le tue >> competenze. >> On May 13, 2016 7:43 AM, "Guerrisi Antonio" <[email protected]> >> wrote: >> > >> > Non ti sembrano operazioni pesanti perché non hai idea di come funzioni >> un PC. La compressione è uno dei lavori peggiori per una CPU ... >> Alla CPU che tu stia facendo compressione oppure leggendo un file di >> tutti uno non importa nulla. Le operazioni di base sono le stesse sia per >> uno che per l'altro task. Quello che importa è il numero di operazioni >> richieste per un determinato lavoro. Che nel caso della compressione sono >> molte e complesse. >> Infatti basta un semplice dd if=/dev/zero of=/dev/null per sortire lo >> stesso effetto di un gzip, qui non c'è nessuna compressione, solo tante >> operazioni semplicissime senza uso di dma. >> Lanciare comunque un singolo gzip carica un singolo core, quindi non far >> lavorare pesantemente la cpu. >> >> Per non parlare poi dello scheduler in uso che può comunque modificare il >> nice del processo in esecuzione e quindi il carico sulla cpu. >> Per CARICARE tutti i core potresti lanciare più gzip: >> for i in {1..4}; do gzip -c /dev/urandom > /dev/null &; done >> Sostituisci 4 con il numero di core del tuo pc. >> Concordo cmq che stress effettua un egregio lavoro e le opzioni --cpu >> --timeout danno un ottimo controllo. >> Ps. Mi scuso per aver risposto direttamente al tono provocatorio di >> Antonio, ma non ho resistito. Pregherei Antonio si di rispondere, ma in >> modo costruttivo, senza additare di ignoranza o altro, ma aiutando a >> capire. Siamo un gruppo non singoli in una Arena. >> >> _______________________________________________ >> BrigX Linux Users Group >> [email protected] >> http://brigx.it/mailman/listinfo/ml_brigx.it >> >> > _______________________________________________ > BrigX Linux Users Group > [email protected] > http://brigx.it/mailman/listinfo/ml_brigx.it > >
_______________________________________________ BrigX Linux Users Group [email protected] http://brigx.it/mailman/listinfo/ml_brigx.it
