Non so perchè Mauro voglia per forza portare la CPU al 100%, ma il calcolo di cryptomonete sicuramente è un'applicazione che satura completamente la CPU (ma solo quella! niente ram e niente i/o su disco).
2016-05-14 12:25 GMT+02:00 Gianluca Santoro <[email protected]>: > 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 > >
_______________________________________________ BrigX Linux Users Group [email protected] http://brigx.it/mailman/listinfo/ml_brigx.it
