In questi ultimi giorni in rete non si parla altro che di una piccola Patch da applicare al kernel che ne migliora sensibilmente le prestazioni, e che addirittura Linus Torvalds n'è soddisfatto. Sono venuto anche a conoscenza di un metodo alternativo per ottenere gli stessi risultati. Quello che ancora non avevo visto erano dei benchmark che provassero se tutto questo fosse vero. Mi sono deciso quindi di fare questo sporco lavoro 🙂 e sinceramente avrei voluto fare molti più test, ma purtroppo in questi giorni di continua pioggia, e le vecchie linee di merda che ci sono in Italia, la ADSL risulta molto degradata, e non ho potutto fare dei test che richiedevano il download di un paio di giga. Comunque per il momento sono riuscito a fare 8 test, ma non escludo di farne degli altri. Questi 8 test comunque ci danno un indirizzo, e cioè, che la patch funziona., ma secondo me non fa sfracelli. Questi test li ho fatti, come si può vedere in figura sopra, su Debian Squeeze , kernel 2.6.36 (x86_64), con compiz attivo ed iceweasel aperto.
Benchmark:
La prima immagine di ogni serie si riferisce al benchmark senza patch:
Esempio:
7-zip prima immagine = senza patch
7-zip seconda immagine = con patch
e così via per tutte le altre.
Da questi primi test si evince che questa patch effettivamente funziona, ma proverò a farne degli altri per avere una visione completa di dove e quanto effettivamente sono i miglioramenti.
enjoy 😉
L’ho provata la patch, e dato che personalmente mi fido di più della sensazione “a pelle” che dei benchmark, posso dire che la patch fallisce miseramente, cioè non noto assolutamente cambiamenti sostanziali
Molto più funzionale la patch ck, almeno lato desktop
Restiamo in attesa allora di ulteriori prove.
Grazie 😉
Dai risultati dei bench risulta esserci un peggioramento nelle prestazioni: come fai a dire "Da questi primi test si evince che questa patch effettivamente funziona" ?
Per quanto riguarda il suo meraviglioso funzionamento a livello desktop (come da video e non limitato ad un singolo task benchmarkabile) non ci sono parole, funziona davvero.
Forse non è chiarissimo cosa faccia la patch.
Teoricamente questi benchmark dovrebbero PEGGIORARE con la patch, non migliorare, perché lo scopo è di rendere più reattivo il sistema, non più veloce.
Significa che mentre comprimi un 7zip o encodi un ogg, puoi continuare a muovere finestre senza lasciare la scia, a costo di metterci qualche secondo in più per avere il file compresso.
Non puoi "overcloccare" la CPU via software, puoi solo decidere cosa farle pare con priorità più alta, sacrificando il resto.
Bye.
@m
direi che facendo una media dei test che ho, risulta che ci sono dei miglioramenti, quello che non mi sento di dire, ma sicuramente dipenderà dalle mie conoscenze, e che questa sia un fulmine.
@Alex
quindi secondo te questa patch risulta utile solamente per i vecchi pc, dato che in quelli recenti riesci a fare un make j4 e diverse altre cose senza che le finestre lascino la scia. In rete tutti la hanno presentata come la patch delle meravigie, in grado di rendere linux velocissimo…..bha 😉 se quello che riesce a fare va bene solamente per i vecchi pc, a questo punto sono ulteriormente deluso
@tutti
leggete cosa ne pensa Con Kolivas di questa patch https://ck-hack.blogspot.com/2010/11/create-task-groups-by-tty-comment.html
@edmond,
scusa ma la matematica non è opinabile 😉
In quanti test c'è miglioramento ed in quanti peggioramento?
Il primo di ogni serie è "senza patch" ed il secondo "con patch"?
nei test esposti siamo 5 a 5 (ne ho degli altri fatti successivamente) comunque si rafforza in me il pensiero che questa patch non ha senso adesso 😉
@edmond:
scusa la franchezza, ma prima di eseguire test inutili potevi documentarti sul motivo per cui è stata creata questa patch.
sulla mailinglist degli sviluppatori del kernel (lklm) [1] sono riportati dei benchmark. la patch non è utile per rendere il pc più veloce ma per diminuire la latenza massima e media, cioè la reattività, quando i cgroups sono abilitati nel kernel (ormai di default). nulla di più. tra l'altro, se i cgroups sono disabilitati il pc risulta, secondo i benchmarks effettuati, poco meno reattivo che con cgroups + patch [2].
tutto detto in maniera sintetica.
[1] https://lkml.org/lkml/2010/10/19/123
[2]https://lkml.org/lkml/2010/11/16/392
@edmond: scusa se nel precedente messaggio sono sembrato troppo caustico, però si fa una gran parlare di questa patch e molto spesso a sproposito confondendo ancora di più le acque e le idee.
@suinonatante
no problem, questo spazio è aperto a tutti, specialmente quando i commenti sono ben argomentati 😉 comunque chiedo venia per i test, se questi hanno contribuito a fare più confusione 😉
Dai test io evinco che la patch funziona meglio del previsto, Kon colivas sostiene che il suo metodo applicato a bfs portava dei peggioramenti prestazionali, seppur più reattività, quindi l'ha abbandonata.
Qui invece sembra che le prestazioni rimangano sostanzialmente invariate; in più ci si guadagna che i processi ed i suoi thread non prendono il controllo della macchina impedendoci di lavorare.
E' vero quanto dice, Kon Colivas, un nice messo prima del comando 'bloccante' ha lo stesso effetto, ma:
1- A priori potrei non sapere se qual comando sarà o meno avido di risorse
2-Se un script bash o una patch del kernel sono capaci di raggruppare per me i thread in modo che non si pestino tropop le gambe a vicenda, perchè non perseguire questa strada?
@Andy77
in effetti analizzando questi test, più altri che ho, sembrerebbe che addirittura ci sarebbero dei miglioramenti anche quando la cpu non è a pieno carico. Per quanto mi riguarda non ho le conoscenze per contraddire Con Kolivas 🙂 ed in più mi è simpatico.
io continuo a preferire il BFS di CK
anche io uso abitualmente un kernel con le patches di ck, in effetti le suggeriscono proprio i developers della distro che uso.
https://www.tuxjournal.net/?p=16813
leggete anche i commenti a proposito dell'ultima versione di systemd…
molto interessante.