I test Phoronix bocciano il kernel Linux 2.6.33: è davvero bloated

pubblicato: mercoledì 03 marzo 2010 da Silvio Gulizia

Lo chiamavano il gordo, ma alla fine era quello che faceva sempre gol. No, non è Ronaldo ai tempi del Real Madrid, ma il kernel Linux che lo stesso papà Torvalds ha recentemente definito bloated, gonfio. La redazione di Phoronix.com, magazine specializzato nei test di benchmark, propone infatti una serie di test eseguiti negli ultimi due anni da cui si vede come le performance del kernel non siano in costante miglioramento, come si vorrebbe. Anzi, il nuovo kernel 2.6.33, da poco rilasciato e che prometteva diverse novità, come abbiamo riportato, ne esce con le ossa rotte.

Poco o nulla sembra infatti cambiato, in termini di prestazioni, per quanto riguarda la compressione con 7zip e Lzma fra la versione 2.6.24 e quella 2.6.33 del kernel. Idem per quanto riguarda Apache, che anzi ha accusato un calo di prestazioni da versione a versione per poi posizionarsi sugli stessi livelli di inizio rilevazione, mentre in diversi altri test le prestazioni crescono nelle ultime tre release prima di tornare a livelli decisamente inferiori con la 2.6.33, come per esempio per quanto riguarda l’uso di PostgreSql.

Se le conclusioni dei tester sono più ponderate, le nostre di utenti sono drastiche: Linux è diventato un ciccione. Intel, a dire la verità, l’aveva già anche detto: il kernel ha perso il 12% in termini di prestazioni nelle ultime 10 release. E Torvalds aveva sancito: Tux è diventato un pinguino grasso e lento. “Un signore grasso e lento giunto al viale del tramonto” cantavano Elio e le storie tese in una sigla di Mai dire gol di diversi anni fa. Che proseguiva invitando il protagonista della filastrocca ad appendere le scarpe al chiodo: “Dai ascolto a chi ti vuole bene campione / fallo anche tu / Meglio adesso che sei un mito / da domani sarai un peto”.

Ora, nessuno vuole vedere Linux in panca ma forse occorre davvero riflettere sul tentativo degli sviluppatori del kernel di correre dietro a ogni novità. E il fatto che Ubuntu 10.4 dovrebbe montare il kernel 2.6.32 aggiunge un altro spunto alla riflessione, alla luce dei test di cui abbiamo parlato.

(3 Voti | Media: 3 su 5)

26 commenti

Gallerie Correlate

Commenti dei lettori

(Inserisci un commento - Nascondi commenti anonimi)

Claudio2
03 mar 2010 - 14:37 - #1

0 punti

E’ il momento di Hurd:P
zoom
03 mar 2010 - 14:54 - #2

0 punti

se il 2.6.32 risulta migliore del successivo, allora forse è bene che non solo ubuntu ma un pò tutte le distro che avessero intenzione di usare il 2.6.33 tornino indietro al 2.6.32
luuuucaaa
03 mar 2010 - 15:17 - #3

0 punti

Penso che sia arrivato il momento di riscrivere tutto da 0.
Giorg
03 mar 2010 - 15:25 - #4

0 punti

Vogliamo Linux 3.0!! :)
Shu
03 mar 2010 - 15:26 - #5

2 punti

Non vi sembra un po’ catastrofista, questo articolo?

Le prestazioni del 2.6.33 sono in linea con quelle del 2.6.24 di due anni fa. C’è stato solo un exploit di tre kernel (30, 31 e 32) su PostgreSQL, che può benissimo essere dovuto a ottimizzazioni di PostgreSQL a carattersitiche presenti in quei kernel, e magari rimosse dai successivi. Probabilmente provando versioni diverse di PostgreSQL i risultati sarebbero diversi.

Tra l’altro il .33 presenta prestazioni spaventose rispetto a tutti gli altri kernel in caso di accessi multipli (quindi SEMPRE, per un server, e SPESSO, per un client).

In generale, il trend delle prestazioni è andato migliorando, soprattutto nel .33.

Vorrei anche far presente che un 12% di prestazioni “perse” in 10 release (2 anni), mentre le CPU hanno aumentato del 130-150% le prestazioni, sono niente. Nello stesso periodo, probabilmente, il kernel di Windows ha perso il 40-60%. :P
Oltretutto Intel non si riferiva al .33, che è uscito da pochi giorni, ma a versioni precedenti che, si vede anche dai grafici, erano spesso più lente del .24 preso a campione.

Quindi no, non ne esce affatto con le ossa rotte, e se aveste letto l’articolo di Phoronix, invece di guardare solo i due grafici peggiori, non avreste nemmeno scritto questo pezzo. Il .33 è uno dei migliori kernel usciti negli ultimi 3 anni, e probabilmente le basse prestazioni in alcuni punti sono semplicemente frutto di ottimizzazioni in altri (vedi la differenza su Dbench, per esempio, con 1 o 12 client).
ekerazha
03 mar 2010 - 15:34 - #6

0 punti

Le prestazioni di PostgreSQL e programmi con un carico simile, in particolare nell’accesso al disco, hanno avuto un calo imbarazzante
Anonimo codardo
03 mar 2010 - 15:38 - #7

-3 punti

Considerazioni abbastanza sciocche imho. Il kernel secondo me non è il posto dove andare cercare le brute performance: quelle si realizzano a livello di applicazione o ancora meglio a livello di libreria (ad esempio aggiungendo il supporto alle operazioni parellele sulle collezioni).

Un kernel deve essere prima di tutto stabile. Una perdita del 10% di prestazioni non è nulla sopratutto se confrontato con la potenza e l’economicità dell’hardware attuale. Queste considerazioni valgono in ambiente professionale: se poi volete un giocattolo con cui far girare un cubo ad un paio di frame al secondo più veloce, per favore cambiate sistema operativo e levatevi dalle @@
guiodic
03 mar 2010 - 15:49 - #8

0 punti

Condivido quanto detto da shu e anonimo codardo.
ekerazha
03 mar 2010 - 15:56 - #9

0 punti

Le parole di “Anonimo codardo” sono quelle di chi non conosce la struttura di un kernel. Le prestazioni vanno ricercate eccome anche nel funzionamento del kernel (che poi influenza anche le prestazioni delle applicazioni), non a caso in componenti come lo scheduler si ricerca l’efficienza a livello quasi maniacale.
inteso
03 mar 2010 - 16:10 - #10

0 punti

x Shu

scusa, non ho il tempo di leggere la recensione, quindi te lo chiedo: questa prova è stata fatta sullo stesso hardware o no?
A vedere il tuo commento sembrerebbe di no.. ma allora:

1) non avrebbe senso;

2) a maggior ragione, essendo presente UN CALO di prestazioni nonostante l’ hardware sia AUMENTATO di potenza in modo netto rispetto a 2 anni fa, mi verrebbe da dire che Linux sia diventato LENTISSIMO..

no?
darkbasic
03 mar 2010 - 16:12 - #11

1 punto

Ossblog come al solito non legge gli articoli che riporta.
Ciò non toglie che regression simili non dovrebbero passare lo stato di rc.
Mickmouse
03 mar 2010 - 16:35 - #12

2 punti

Mi chiedo se ci sia qualche ragione dietro questa «interpretazione» catastrofista di numeri che di catastrofico hanno poco o nulla, salvo che non ci si vogliano stracciare le vesti e battere il petto per una regressione delle prestazioni di un filesystem dopo che precedenti implementazioni le avevano innalzate a scapito della sicurezza dei dati. Se vogliamo parlare della pesantezza dello stack GNU/linux, vera o presunta che sia, bisognerebbe piuttosto confrontarlo con altri sistemi operativi, quali ad esempio debian/FreeBSD, FreeBSD, Solaris, Mac OS X e presto, sulle pagine di Phoronix, anche Windows. Puntare l’indice su regressioni ben note alla comunità, accettate in cambio della sicurezza dei dati dell’utente e peraltro facilmente aggirabili passando parametri di mount opportuni o utilizzando filesystem diversi (anch’essi parte di linux, guarda un po’…), è semplicemente ridicolo. Il «bloated» a cui alludeva Linus, del quale peraltro non amo lo stile e a volte anche le idee, era una riflessione nient’affatto banale sulla vastità del kernel e sulle difficoltà che ciò comporta e comporterà sempre più per la sua manutenzione ed evoluzione. Mettere insieme cose che fra loro non hanno nulla a che fare, come in questo articolo, è indice non soltanto di poca competenza tecnica, ma anche di scarse capacità intellettuali o abbondante pigrizia.
Le ragioni dietro il catastrofismo, dicevo… spero si tratti soltanto di incapacità di reperire in prima persone notizie degne di essere chiamate tali, con la necessità quindi di prendere spunto dal lavoro altrui per raffazzonare un titolo e dare una parvenza di novità alla parte alta della pagina… panta rei.
Fabio, Io
03 mar 2010 - 16:55 - #13

0 punti

C’è anche da dire che i test sono stati fatti su ext3.
Sarebbe interessante verificare se il comportamento è analogo su etx4 o se sia dovuto almeno in parte al file system
thelostone
03 mar 2010 - 17:00 - #14

0 punti

Il viale del tramonto, appendere le scarpe al chiodo. Ma che è. Ma che dici. Ma che scrivi.
Condivido ovviamente la maggior parte dei commenti precedenti che fanno notare l’inconsistenza di fondo dell’articolo.
E aggiungo che è quantomeno logico che un kernel monolito come Linux diventi sempre più “pesante” nel momento in cui si cerca di estendere la compatibilità hardware.
Anonimo codardo
03 mar 2010 - 17:18 - #15

0 punti

@ekerazha
L’attuale scheduler di Linux (di Molnár) è _già_ il migliore possibile quello vuoi dire tu è che bisognerebbe migliorare i _tempi di risposta_.
Shu
03 mar 2010 - 18:09 - #16

1 punto

@inteso
Il test di Phoronix è stato fatto a parità di hardware e di tutto il resto del software, tranne appunto il kernel (non so come abbiano risolto con udev, visto che è molto dipendente dal kernel, ma probabilmente hanno aggiornato solo lui).

Se avessero aggiornato anche l’hardware, tutti quei grafici sarebbero stati in ascesa costante. :)

Quello che volevo dire è che anche mantenendo la stessa macchina dal 2008 ad oggi, una perdita di prestazioni del 12% è ben poca cosa, considerando che nel frattempo le feature del kernel sono cresciute a dismisura (oltre al supporto a nuovi hardware c’è il supporto anche a nuovi filtri nel firewall, a nuovi filesystem di rete e non, a nuovi protocolli di rete, ecc.)

Bye.
aytin
03 mar 2010 - 18:39 - #17

0 punti

#12 - Mickmouse
“Se vogliamo parlare della pesantezza dello stack GNU/linux, vera o presunta che sia, bisognerebbe piuttosto confrontarlo con altri sistemi operativi, quali ad esempio debian/FreeBSD, FreeBSD, Solaris, Mac OS X e presto, sulle pagine di Phoronix, anche Windows.”

E’ la prima cosa a cui ho pensato.

E poi, scusate, lo stesso autore di questo articolo, nell’articolo immediatamente precedente (http://www.ossblog.it/post/5869/lxde-conquista-anche-mint-saranno-i-netbook-a-decretarne-il-successo) si chiede che senso possa avere ottimizzare usando DE sempre più leggeri visto che i pc sono sempre più potenti e ora, di fatto, fa una considerazione diametralmente opposta: bisogna ottimizzare il kernel perché così è troppo ricco di funzionalità e pesante.
Della serie: delle due, l’una.
ghostdog
03 mar 2010 - 18:39 - #18

0 punti

in molti casi le performance sono allineate, ma qualcuno mi spiega perchè in alcuni test ci sono state delle regressioni paurose? ci sarà un motivo tecnico no?

non penso che è arrivata una scimmia che ha pigiato tasti a caso sul sorgente del kernel.
inteso
03 mar 2010 - 18:41 - #19

0 punti

x Shu

ok, ci siamo capiti ;-)
ekerazha
03 mar 2010 - 19:04 - #20

0 punti

@ Anonimo codardo
No, quello che voglio dire io è che come dimostra anche lo sviluppo dello scheduler, le prestazioni e l’efficienza vanno ricercate anche nel kernel e non solo nelle applicazioni.
bah!!!
03 mar 2010 - 19:10 - #21

0 punti

Vabbé dai ci sta un calo, io sulla stessa macchina me ne sono accorto senza tanti test ma è trascurabile perché in alcune cose va meglio quindi …
Helloboy
03 mar 2010 - 20:19 - #22

0 punti

Ma scusate tanto è opensource si scarica la sorgente si fanno lo modifiche del caso (per questo si deve per lavorare be mi pagano anche) e bene che va pure meglio di prima…
Quindi “WHERE IS THE PROBLEM” con Windows se po fa NO con MAC se po fa NO con tutti i sistemi operativi open se po fa SI!!!
aleksander
03 mar 2010 - 20:44 - #23

0 punti

Tralasciando quanto possano essre utili sti test….cmq sarebbe interessante come già detto da altri un confronto tra Linux,FreeBSD,OpenSolaris,Mac e Windows.
abel233
04 mar 2010 - 06:51 - #24

0 punti

non so chi è peggio se il blog o i test di sophorov!! XD
Paolo Ornati
07 mar 2010 - 11:41 - #25

0 punti

Le esageratamente maggiori prestazioni di 3 release del kernel in
pgbench sono troppo belle per essere vere, e infatti non sono vere.
Sono il risultato di un “BUG”: è chiaro che se non ti interessa
l’integrità dei dati in caso di crash puoi andare _molto_ più veloce:

http://www.mail-archive.com/pgsql-performance@postgresql.org/msg34841.html

“The pgbench TPS figure Phoronix has been reporting has always been a
fictitious one resulting from unsafe write caching. With 2.6.32
released with ext4 defaulting to proper behavior on fsync”

I risultati dei benchmark andrebbero letti con occhio critico, non per fare sensazionalismo ;)
rekiah
09 mar 2010 - 16:51 - #26

0 punti

@ Paolo:

Ho postato sul forum Phoronix un link a quel post da te citato. Qui trovi la loro risposta in merito: http://www.phoronix.com/forums/showthread.php?t=22280&page=5