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
