Architetture a 64bit, la dimostrazione di come il software proprietario sia un freno all'innovazione.

In questi giorni un troll che è passato da questo blog ha rinfrescato la discussione sui processori a 64bit. Il troll in questione, come molti altri utenti, ha dimostrato di essere enormemente confuso in merito alle architetture a 64bit ed agli eventuali vantaggi che queste ultime hanno rispetto alle architetture a 32bit. Oggi proverò a fare un po' di chiarezza in più sulla questione.

Bisogna intanto chiarire che le architetture a 64bit non sono una novità, il primo processore a 64bit è stato sviluppato per l'architettura RISC. Questo tipo di architettura, per anni è stata (e per certi versi ancora è) in competizione con l'architettura utilizzata nei sistemi x86 che equipaggiano da sempre i nostri PC (che hanno un'architettura CISC). Il primo processore a 64bit fu prodotto dalla MIPS Computer Systems e si chiamava R4000. I processori realizzati da MIPS Computer Systems erano molto utilizzati per la produzione di grafica vettoriale ed hanno trovato largo spazio d'uso anche nelle console videuliche (Sony playstation 1 usava un mips a 32bit, Playstation 2 usa EmotionEngine, una CPU progettata da Sony stessa con due core a 64bit, Playstation 3 usa CELL, che si avvale sempre del set di sitruzioni RISC pur non essendo MIPS). Normale quindi che i primi processori a 64bit siano nati proprio su questo tipo di sistemi.

In ambito domestico, ovvero nei nostri PC, i processori a 64bit hanno fatto il loro debutto molto più tardi, ovvero il 23 Settembre 2003, con il lancio dei processori Athlon 64 di AMD. Facciamo un passo indietro. Due anni prima l'azienda regina dei processori X86, ovvero Intel, lanciò sul mercato un processore a 64bit destinato ai server. Il processore in questione si chiamava Itanium, un processore a 64bit che però non usava il set di istruzioni x86 e che era il risultato di una nuova architettura realizzata in joint venture con HP. Il set di istruzioni si chiamava EPIC ed era diverso sia dal RISC che dal CISC. Probabilmente possiamo considerare Itanium come un tentativo (fallito) di soppiantare la (sempre criticata) architettura x86 e di fare così fuori anche la concorrente AMD. Il progetto di Intel fallì (anche se Itanium ha ancora oggi una piccola quota di mercato dietro a x86, SPARC e PowerPC) principalmente per due motivi: mancato supporto software e produzione da parte di AMD di un processore a 64bit compatibile al 100% con l'architettura x86 (quindi totalmente retrocompatibile). La compatibilità di Itanium era invece ottenuta grazie ad un core x86 inserito nella CPU ma i cali di prestazioni erano notevoli. Itanium fu largamente criticato proprio dal punto di vista prestazionale ma i limiti non erano nel processore quanto nella mancata ottimizzazione del codice per l'architettura.

Il secondo problema ha penalizzato anche le CPU a 64bit di AMD. In realtà credo che la storia dei processori a 64bit sia l'esempio più lampante di come il software proprietario tenda spesso ad essere un freno all'innovazione. Non a caso Hector Ruiz, allora amministratore delegato di AMD, ebbe a dire in merito a Windows a 64bit: "non è un segreto che siamo delusi per il ritardo"¹ e proprio nello stesso periodo elogiò la comunità open source e Linux. Il motivo era semplice, AMD puntava ai 64 bit per avere un vantaggio tecnologico su Intel, che all'epoca scommetteva sui 64 bit solo per la nuova architettura Itanium e che in ambito desktop invece promuoveva i 32 bit e la tecnologia Hyper trading. AMD contava molto su quel vantaggio tecnologico rispetto alla concorrente ma non potè mai sfruttare questo vantaggio perché i software proprietari non erano ottimizzati per codice a 64bit, ecco perché Ruiz all'epoca elogiò moltissimo la comunità Gnu/Linux affermando che: il supporto della tecnologia AMD64 da parte degli sviluppatori open source ha fatto sì che questa tecnologia sia oggi impiegata all'interno di alcuni tra i computer più potenti del mondo". I processori a 64bit vennero sfruttati appieno solo con i sistemi operativi open source e furono invece terribilmente penalizzati dal mancato supporto nativo da parte dei software proprietari.

In effetti Ruiz aveva le sue ragioni per elogiare la comunità open source, le varie distribuzioni Gnu/Linux iniziarono a supportare i processori a 64bit quasi immediatamente; a pochissimo tempo dal lancio dei primi Athlon64 tutte le distribuzioni più importanti già supportavano nativamente i processori a 64bit offrendo sistemi operativi completamente ottimizzati per tale architettura. Ma, senza addossare la croce ai soliti noti, bisogna dire che alla fine anche Microsoft non si fece attendere moltissimo e lanciò il suo primo sistema operativo a 64bit per x86 nell'aprile del 2005, quasi 2 anni dopo il lancio del primo processore x86-64. Il problema è che tale sistema operativo non ebbe alcuna penetrazione sul mercato, anche perché, nonostante la presenza di layer di emulazione in grado di garantire la compatibilità con i software e le librerie a 32bit, l'uso di Windows a 64bit era piuttosto problematico. Per iniziare a parlare di Windows a 64bit (per x86) veramente funzionanti, supportati ed usati, dobbiamo attendere Windows Vista, ovvero il 2007. Ovvero ben 4 anni dal lancio del primo processore a 64bit. Nonostante tutto però, ancora oggi che i processori a 64bit sono diventati addirittura quad core, è piuttosto raro vedere versioni a 64bit dei sistemi operativi Microsoft nelle case degli utenti. Oggi, con il lancio di Windows 7, a quasi 7 anni dal lancio del primo processore x86-64 pare che aziende, produttori di driver e software house intendano finalmente supportare seriamente i processore x86-64. Il bello è che qualcuno cerca di spacciare il pieno supporto per una tecnologia vecchia di anni come una grande novità e questa cosa mi fa certamente sorridere un po'.

La colpa della lenta penetrazione di Windows a 64 bit però non è dipesa da Microsoft. Il problema è che Windows è un sistema operativo proprietario, distribuito senza sorgenti e che, per larga parte, vive in ecosistema fatto di altri software proprietari. Tutti i più importanti software usati nei sistemi operativi Windows sono software proprietari distribuiti senza codice sorgente. Autocad, Adobe, i produttori di driver e tante altre software house hanno tardato moltissimo il supporto ai 64 bit (con l'esempio più clamoroso del player flash, ancora oggi disponibile a 64bit solo in versione Alpha e solo per sistemi Gnu/Linux). Paradossalmente anche i software liberi largamenti diffusi su Windows (Firefox, OpenOffice, VLC) non distribuiscono binari precompilati per Windows a 64 bit (e vi assicuro che compilare software sorgente su Windows non è assolutamente più facile del famigerato ./configure && make && make install delle distribuzioni Gnu/Linux). Risultato: chi usa Windows a 64 bit è costretto ad avere un sistema ibrido che non può, per sua stessa natura, sfruttare i vantaggi dei 64bit. Non ibrido soltanto nelle librerie quanto proprio nei software che è possibile utilizzare. Avere un sistema operativo a 64bit ed utilizzare software compilati a 32bit che linkano a librerie a 32bit, come detto da Lucalosvizzero nel suo pezzo su Windows 7, penalizza senza ombra di dubbio le prestazioni complessive del sistema, non foss'altro perché si è costretti ad avere necessariamente doppioni delle stesse librerie di sistema (sia nella versione a 32bit che nella versione a 64bit) per semplici ragioni di compatibilità. Un sistema a 64bit non può utilizzare librerie a 64bit per avviare applicazioni a 32bit, quindi, se il parco di applicazioni non è interamente a 64bit è necessario avere almeno il set di librerie a 32bit che servono per far funzionare le applicazioni a 32bit installate.

Su Gnu/Linux il supporto ai 64 bit è stata tutta un'altra storia, non priva ovviamente di problemi e difficoltà, ma senza ombra di dubbio più dinamica ed intraprendente. Io ho iniziato ad usare Gnu/Linux a 64bit praticamente non appena uscirono le prime distribuzioni e da subito ho trovato il sistema usabile al 80%. Il restante 20% era, in larga parte e non a caso, legato ai software proprietari, in particolar modo all'odiato flash ed agli altrettanto odiati codec win32. Ancora oggi non esiste una versione a 64bit di Flash player, l'unica versione disponibile e l'alpha (Linux only) di cui vi ho accennato poche righe più su, comparsa sul sito di Adobe dopo anni di richieste ignorate, guarda caso quando Microsoft lanciò Silverlight (disponibile su Linux con il nome di Moonlight). Ancora oggi quell'Alpha release è l'unica versione di Flash disponibile per i 64 bit ma per fortuna l'esistenza di quest'alpha version non mi costringe a creare un sistema ibrido (con librerie a 32bit e firefox a 32bit) solo per poter vedere i filmati su youtube. Dopo anni di complicazioni causate dai software proprietari ora posso finalmente usare un sistema puramente a 64bit, tuttavia l'esperienza di Flash ha indispettito me e molti utenti di sistemi a 64bit per molti anni, ed è stata la dimostrazione più lampante di quanto il software proprietario, ancor più nei sistemi open source, sia per l'utente una vera e propria palla al piede. Per fortuna flash è un software di poco conto ed usare un browser a 32bit per navigare non è la fine del mondo. Ma l'esempio di Flash è ancora oggi l'esempio più lampante di quanto possa essere deleterio essere schiavi di un formato proprietario del quale non siamo più in grado di fare a meno. Se il problema fosse stato su un software di maggiore importanza e complessità forse i processori 64bit sarebbero state inutili anche sui sistemi Gnu/Linux ed oggi sarebbero stati spazzati via a causa della scarsissima richiesta sul mercato.

Non vi sono dubbi sul fatto che i software proprietari nel caso dei 64bit (ma anche in molti altri casi) sono stati un grande freno all'innovazione. I software open source, per loro stessa natura, si sono adattati quasi immediatamente alla nuova architettura, sono stati i primi a supportarla ed ancora oggi sono forse gli unici in cui l'uso di tale architettura ha un senso.

Concludo con una piccola nota a margine. Sui processori x86-64 si possono installare sistemi operativi a 32bit in modo trasparente. I 64 bit supportano nativamente il set di istruzioni a 32bit, tuttavia un processore a 64bit costretto a lavorare in modalità 32bit non può esprimere al meglio le sue potenzialità ed in particolari task potrebbe anche essere penalizzato nelle prestazioni rispetto ad un processore a 32bit. I motivi sono tanti, tecnicamente complessi e vanno fuori dalla scopo per cui è stato scritto quest'articolo, la cosa sicura è che non ha senso acquistare un processore a 64bit per usarlo poi su un sistema operativo a 32bit. Bisogna infine porre l'accento su un'altro aspetto che, a giudicare da certi commenti, non è affatto chiaro: una cosa è usare un processore a 64bit con un'architettura a 32bit pura (ovvero a 32bit a partire dal kernel per concludere alle applicazioni), altra cosa è usare un processore a 64bit con un'architettura mista, ovvero un sistema con kernel a 64bit e software a 32bit che funzionano grazie a layer di emulazione come wow64 o ABI come linux32. Altra cosa ancora è usare un sistema operativo a 64bit puro, dove tutto è ottimizzato per funzionare a 64bit. Inutile sottolineare che l'acquisto di una CPU a 64bit nel primo caso è inutile, nel secondo scarsamente utile e solo nel terzo di una qualche utilità.

Fonte: Linux Pro del 25/03/2005

1. Windows Vista: vuoi la versione a 64bit? Devi pagarla a parte!
2. Asus lancia sul mercato un PC Linux Inside: piccino picciò, sia nelle dimensioni sia nel prezzo.
3. Il software proprietario in Gnu/Linux, ha un senso?
4. Il 2010 Sarà l'Anno di Linux? Ma chi se ne frega! :-) O di Come i PC siano Liberi Tranne che nel Software.
5. Quanto valgono il kernel Linux ed i software liberi?

(Gli utenti ritengono che questo articolo valga +3, hanno votato 3 utenti)

 Loading ...