Armonk, NY, 7 Aprile 1964
Una nuova generazione di elaboratore elettronico per la computazione è stato introdotto oggi dalla International Business Machines Corporation.
Il chairman del board IBM Thomas J. Watson Jr. considera l’evento il più importante della storia dell’azienda.
[…]
“System/360 rappresenta un netto progresso rispetto ai concetti passati di design e costruzione di computers. È il prodotto di uno sforzo internazionale nei laboratori IBM e segna la prima radicale riprogettazione dell’architettura dei computer IBM in un decennio. Il risultato sarà più produttività a un costo inferiore. È l’inizio di una nuova generazione – non solo di computer – ma della loro applicazione nei campi aziendale, scientifico e governativo.”
Con queste parole, roboanti ma per nulla ingiustificate, Thomas J. Watson Jr. toglieva uno dei grandi lucchetti che bloccavano la concezione moderna di computer. IBM System/360 introduce infatti una delle grandi svolte dell’informatica moderna: l’ISA standard.
La Instruction Set Architecture, questo il significato dell’acronimo, rappresenta tutto l’insieme di istruzioni che un processore può eseguire – che si tratti di aritmetica, logica, gestione dati o controllo di esecuzione. La standardizzazione dell’ISA implica la riutilizzabilità di un software su più computer, diversi come potenza di calcolo, costo e destinazione d’uso.
Ecco perché, il System/360 apre una nuova era: prima non esisteva un mercato del software ma un mercato del tempo di programmazione. Esistevano hardware proprietari, da programmare in modo totalmente personalizzato e senza possibilità di riutilizzo del codice. Esistevano dunque solo software sviluppati ad hoc e destinati a specifici ambiti di utilizzo. Ambiti fino ad allora chiusi all’esterno come banche, istituti di ricerca, università.
Prima di proseguire va tuttavia chiarito il significato con cui usiamo la parola standard: se oggi, in un mercato tecnologico maturo, della definizione di standard si occupano entità esterne, che proteggono la nozione divenuta fondamentale di interoperabilità, negli anni ’50 era normale che due macchine dello stesso produttore non parlassero un linguaggio comune. System/360 è in questo senso il capostipite di una famiglia di macchine per le quali era possibile sviluppare software su una base comune.
System/360 porta dunque una visione nuova che, creando i germi del mercato del software, crea per IBM l’occasione per diventarne la prima protagonista ed ammortizzare i costi di sviluppo su un parco macchine allargato. Nasce dunque anche il concetto di retrocompatibilità, come entità di cui tenere conto nello sviluppo di nuove tecnologie hardware (per mantenere la compatibilità col software esistente) e software (per mantenere la compatibilità con l’hardware esistente). Una nozione che rappresenta tuttora la pietra miliare dei sistemi IBM dedicati al mondo enterprise e che domina anche – con effetti a mio parere non esattamente positivi – il mondo PC.
Un interessante parallelo fra la rivoluzione dell’ISA standard e i tempi moderni arriva da uno dei miei personali punti di riferimento per quel che riguarda il giornalismo tecnico: John Stokes, che compara, in un interessante articolo di ArsTechnica, l’innovazione portata dal System/360 con una rivoluzione moderna, la virtualizzazione.
Tanto l’ISA comune che la virtualizzazione rompono il legame univoco fra una piattaforma hardware e un software, abilitando la portablità del codice e quindi creando un nuovo mercato o estendendolo oltre i suoi confini – è il caso della virtualizzazione.
In entrambi i casi, secondo Stokes, la chiave è l’inserimento di un livello di astrazione – fra il programmatore e l’hardware nel caso dell’ISA, fra il software e l’hardware reale nel caso della virtualizzazione.
Questa interessantissima considerazione apre la scena a quesiti filosofici cruciali nell’informatica attuale. Per esempio, un’ISA sviluppata attorno ai requisiti della sola virtualizzazione eliminerebbe la necessità di portarsi dietro le istruzioni ereditate per motivi di retrocompatibilità da architetture finora sviluppate in modo evolutivo come x86? E ancora, stavolta in campo software, che bisogno c’è per Microsoft di rimanere ancora arroccata su un kernel derivato da Windows NT quando si potrebbe relegarne l’esecuzione a una macchina virtuale e ripartire da una base di codice completamente nuova?
Alcune risposte:
– ottimizzazione delle prestazioni
– bassa latenza e basso overhead nel trattamento delle informazioni multimediali in real-time
– bassa occupazione di memoria
La virtualizzazione e’ utile in certi casi ma, a meno di sviluppi rivoluzionari, e’ meglio che rimanga un accessorio (Java virtual machine docet…), piuttosto che diventare la base della prossima generazione di architetture.
Beh rispetto ai primi tempi di Java l’hardware ha fatto molti passi avanti, al punto che oggi dei multicore in molti non sanno che farsene… Per il resto, lungi dall’essere un accessorio, la virtualizzazione è già protagonista del mondo server e potrebbe assumere un ruolo importante anche in quello desktop.
[quote]
E ancora, stavolta in campo software, che bisogno c’è per Microsoft di rimanere ancora arroccata su un kernel derivato da Windows NT quando si potrebbe relegarne l’esecuzione a una macchina virtuale e ripartire da una base di codice completamente nuova?
Non sono un esperto del settore, ma la penso come te. Oggi, con processori multicore e con tutta la potenza sprecata che si ha, sarebbe una cosa + che logica.
Anzichè pensare alla retrocompatibilità, Microsoft farebbe bene a pensare a un sistema operativo che segni una discontinuità netta con i vecchi windows, delegando a una/+ virtual machine che possano essere avviate “a richiesta” dai software che richiedano una versione precedente. Poichè hanno i sorgenti, credo abbiano la possibilità di approntare vm fortemente ottimizzate.
Il discorso potrebbe anche estendersi all’architettura stessa x86. Avere una nuova architettura XYZ, che possa virtuallizzare quella x86.
IMHO, naturalmente.
Quello che viene citato, la possibilità di ISA implementanti istruzioni specifiche per la virtulizzazione,nacque 20 anni dopo,negli anni 80′.
Le macchine IBM iniziarono a essere “partizionabili” con l’introduzione dell’esa390. caratteristica che mantengono ancora nelle evoluzioni odierne (z10) e che è stata introdotta da un tot di anni anche nelle serie Systtem i/p.
Questo avvenne con modalità simili anche sulle macchine VAX (poi DEC), piattaforma VMS, a partire dal 75′;la tecnologia si trasformò e morì con le gloriose macchine Alpha, HP e Intel nel nuovo millennio ricrearono qualcosa di simile per Itanium.
La virtualizzazione veniva (e viene tuttora) gestita a livello hardware da un ISA con specifiche estensioni, astratto tramite un “Hypervisor”.
Non solo, questo concetti si è esteso anche ai concetti di i/o, con tecnologie come i VIOS di IBM e simili.
A titolo di esempio, l’Hypervisor della attuale Playstation 3 di Sony è una tecnologia figlia della collaborazione con IBM,
e lontana cugina di quella descritta sopra.
E’ quello che io sto dicendo da due anni a questa parte ma tutti mi prendono per scemo e me ne dicono contro cento e una.
Speriamo bene.
“jvm docet?” Se c’è qualcosa che la Java Virtual Machine insegna, è che tramite bytecode si possono ottenere prestazioni pressoché equivalenti (e in certi casi perfino superiori) a quelle del codice nativo, ottenendo indiscutibili vantaggi dal punto di vista sia dello sviluppatore che dell’utente finale.
Il mito “Java è lento” risale a chi faceva girare le applet su 486 nel ’94, ma da allora è stata fatta tanta strada – tant’è vero che in ambito server, dove le prestazioni misurate sono importanti, Java è una piattaforma molto usata, e in ambito client MS stessa sta gradualmente transitando verso un approccio basato su una macchina virtuale che non ha nulla di diverso da Java (.NET).
Se rimangono dei limiti sono dovuti al “non-determinismo prestazionale” dell’operazione di garbage collection, ma a questo si sta lavorando (e a proposito, l’allocazione di memoria tramite gc è più veloce dell’allocazione tradizionale tramite malloc() – ad esempio, allocare un oggetto non richiede l’invocazione di una funzione).
Quindi ben vengano le virtual machine, risolveranno all’utente diversi problemi fra cui sicurezza (applicazioni in sandbox con controllo a grana fine delle operazioni consentite) e compatibilità (“vendor lock-in” ridotto al minimo).
Una curiosità: MS ha già usato una virtual machine per soddisfare le esigenze di compatibilità di un suo S/O in corrispondenza di una svolta epocale, il passaggio da DOS + Windows 3.1 a Windows NT 3.1. Se avete un Windows a 32 bit la potete trovare ancora sui vostri hard disk, sotto il nome ntvdm.exe. Ha risolto gli annosi problemi di stabilità che nascevano dal sistema di virtualizzazione “nativa” del DOS che è stato usato dalle versioni “client” di Windows, fino a Windows ’98.
L’architettura delle vm e’ cosi’ ‘veloce’ che Microsoft sta pensando di tornare a spingere sullo sviluppo non-managed in C++ per Visual Studio 2010, rifacendo le MFC.
Alla luce, soprattutto, del fatto che di applicazioni managed (e di applicazioni/applet java, tranne qualche notevole eccezione), sui desktop non se ne vedono poi molte in giro…
Per quello che vedo, dopo l’infatuazione iniziale per le vm e la virtualizzazione, lo sviluppo nativo sta riprendendo decisamente piede. E per fortuna, aggiungo.
@Aquaventura, i miglioramenti di prestazioni che si possono ottenere con i linguaggi “managed” provengono in parte da assunzioni che non sono vere per linguaggi “unsafe” come il C++. Far girare il C++ sulla VM di .NET è stato uno sbaglio fin dall’inizio (ti ricordi, MS aveva ricevuto un coro di critiche per aver introdotto il sottosistema “unsafe” su .NET per supportare il C++).
Ma da questo a dire che MS sta cambiando rotta con il prossimo Visual Studio ce ne passa: non è forse vero che proprio il prossimo VS introdurrà il .NET framework 4.0? Ed è forse prevista una versione nativa di C#?
Per quanto riguarda la diffusione di Java sul desktop, se non si vedono molte applicazioni Java in giro non è per le loro prestazioni, ma per il fatto che si interfacciavano male con l’ambiente operativo che le circondava. Ora che (su Windows) le cose sono cambiate con l’avvento di .NET, un numero sempre crescente di nuove applicazioni si basa su di esso.
Per finire, dovresti provare a scrivere del codice in C++ che eserciti le funzioni che usi più spesso nella programmazione di tutti i giorni, e poi scrivere del codice Java equivalente che faccia esattamente le stesse cose. Poi misura i tempi d’esecuzione dei due programmi: i risultati potrebbero sorprenderti ;) .
Io sui pc continuo a veder girare applicazioni scritte in C++, da Office a Photoshop, passando per Pro Tools, Cubase, 3dsmax, Premiere e tutto quello che ‘conta’. Poi, ovviamente non so cosa facciate girare voi sui vostri desktop, ma Eclipse e Azureus sono due mangia-memoria pieni di leak ‘a tradimento’… ;-)
Per non parlare dei giochi poi!
Ripeto: ci hanno provato, ha comunque un senso per le applicazioni server-based con interfaccia web (jsp e asp.net ad esempio), ma poi la situazione mi sembra talmente ovvia a propendere per il nativo che la virtualizzazione rimane un bel sogno, forse per il 2020 e per le macchine a 128 bit con 32GB di ram (per fare le stesse cose che facciamo ora ma semplificare, questo lo ammetto, la vita ai programmatori…).
Per ora mi tengo ben stretto il C++ e la standard template library…eheheh…
Io vedo che Paint.net è scritto in C# ed è molto piu completo e avanzato di
Gimp che è scritto in C.
Il fatto che i piu famosi programmi scritti in Java (Azureus ed Eclipse) siano lenti non è un dato significativo in se, ci sono molti altri fattori da considerare e inoltre per quello che fanno va piu ch bene.
Molti software importanti (AutoCAD, Photoshop, Office, etc) sono in C++ per motivi storici (quando sono nati le piattaforme managed non erano adeguate) ma se dovessero riscriverli daccapo di sicuro sceglierebbero .Net o Java.
io fino ad ora ho sempre sentito parlare della presunta superiorita’ di java sul c++, ma a parte che mi sembra sbagliato (c’e’ sempre il fatto che il c++ e’ molto piu’ vicino all’hw di java), di queste teorie non ho mai trovato una fonte imparziale che le confermasse, a parte il “prova a fare due programmi simili, uno in c++ e uno in java, e vedrai”.
a parte che per le mie personalissime prove, java e’ ben piu’ lento del c/c++, e quasi tutti gli applicativi java che ho provato (in primis eclipse e logo express) hanno consumi di ram enormi e sono lentissimi.
per la virtualizzazione, non sono assolutamente d’accordo sul ragionamento “c’e’ tanta potenza, virtualizziamo”.
come me ci sono molti, esempio soft-land.org, che credono che la virtualizzazione sia utile in alcuni casi e non per uso generalizzato. sprecare potenza elaborativa vuol dire sprecare risorse.
non e’ forse meglio cercare di utilizzare un minor numero di computer per fare le stesse cose?
nella mia ex-azienda volevano virtualizzare alcuni server.
bene, ho guardato l’uso in cpu e hd di quei server. Bassissimo. ho fatto presente che sarebbe stato meglio usare UN server per avere piu’ demoni equivalenti ai vecchi server su quel nuovo server, in modo da sfruttare UN server al 80% invece che avere 3 server al 13%.
mi e’ stato risposto: bravo, e se si guasta il server cosa fai? risposta mia: la stessa cosa che se si guasta un server su cui girano server virtualizzati.
volevo scrivere “3 server al 23%”
Credo che sia necessario distinguerei concetti di virtualizzazione che sono stati tirati in ballo finora.
Se parliamo di virtualizzazione in senso generico, è chiaro che ci riferiamo a uno strato che nasce per porre uno strato fra le applicazioni e il sistema (non necessariamente l’hardware) sul quale devono girare, intendendo con ciò che non sia strettamente necessario che le applicazioni siano codificate con istruzioni dell’ISA dell’hardware che ci sta sotto.
Restringendo il campo alla virtualizzazione in ambito delle CPU, ci si riferisce alla capacità che ha quest’ultima di astrarre e di permettere un controllo “più fine” sulle risorse e funzionalità che espone (es: I/O, paginazione, interrupt, registri e istruzioni speciali, ecc.), ma… le istruzioni da eseguire rimangono sempre quelle dell’ISA nativo.
Rimanendo sempre in ambito CPU c’è da dire che alcune CPU moderne, in particolare x86 e PowerPC, da tempo “virtualizzano” anche l’ISA: le istruzioni, infatti, vengono scomposte in microistruzioni di un’altra ISA (un processore RISC estremamente semplice) ed eseguite da quest’ultima. Da citare anche Itanium, che nelle prime due incarnazioni aveva la possibilità di eseguire istruzioni dell’x86, convertendole internamente in quelle della sua ISA nativa, ma con tempi di esecuzione estremamente lenti.
Quindi possiamo vedere 3 livelli di “virtualizzazione”, dal livello più alto a quello più basso (l’ultimo è talmente basso che… non è nemmeno possibile controllarlo direttamente).
Questo permette di rispondere alla prima questione solleva: si può “ammazzare” l’ISA x86 in favore di un’altra “più bella / conveniente”? Sulla carta sì (vedi Itanium). E’ conveniente farlo? No, perché le prestazioni di questa famiglia di microprocessori da anni sono molto elevate, a costi ridotti: uccidere l’ISA x86 non conviene quindi a nessuno. Intel stessa c’ha provato ad ammazzare il suo figliuolo, per ben due volte (la prima, in sordina, con l’80860, la seconda molto più esplicitamente, con Itanium), e c’è rimasta secca, visto che ha lasciato il mercato x86 in mano ad AMD che ha imposto la sua evoluzione a 64 bit (detta AMD64 o x86-64).
La seconda questione riguarda la possibilità di “ammazzare” (tramite virtualizzazione) il kernel di NT. Prima di tutto bisognerebbe vedere le ragioni per farlo. Posto che siano valide, c’è da dire che Windows fa già uso di un sistema di “virtualizzazione”: i cosidetti subsystem.
In buona sostanza, le API e, quindi, il codice nativo di Windows è ben nascosto e non direttamente accessibile. A questo codice si può accedere utilizzando lo strato intermedio che è rappresentato, appunto, dai subsystem. Nella storia di Windows ne sono esistiti diversi: Win16 (usato per le applicazioni di Windows fino a 3.1), Win32 (usato da Windows 9x in poi), Win64 (usato per le incarnazioni a 64 bit di Windows: XP x64 e Vista x64), OS/2 (usato per far girare le applicazioni OS/2) e POSIX (usato per far girare le applicazioni POSIX-compliant, quindi “Unix-like”); a questo possiamo aggiungere anche .NET, che probabilmente diverrà il futuro subsystem “di default” di Windows.
Si tratta, come si può vedere, di un meccanismo estremamente flessibile. Talmente flessibile che si può tranquillamente pensare di sostituire il kernel con codice nuovo di pacca, senza che nessuna applicazione che faccia uso di un qualche subsystem abbia qualche problema.
Quindi la risposta anche qui è sì: si può benissimo cambiare completamente il codice del kernel di Windows. Rimane da capire perché lo si dovrebbe fare.
Terza questione: velocità di esecuzione di applicazioni in ambienti managed vs applicazioni native. Qui http://shootout.alioth.debian.org/ si possono trovare dei benchmark, sebbene siano limitati e, al solito, vadano presi con le pinze.
In particolare se ci soffermiamo sul Java vs C e C++ abbiamo i seguenti risultati.
Quad Core 32 bit
Java (server) vs GCC: http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&lang2=gcc
Java (server) vs G++: http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&lang2=gpp
Quad Core 64 bit
Java (server) vs GCC: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=gcc
Java (server) vs G++: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=gpp
Che non mi sembrano malvagi, in particolare confrontando Java col C, dove la situazione mi sembra più o meno equivalente. Col C++, è vero, non c’è storia: Java sta sempre sotto, anche se non stiamo parlando di diversi ordini di grandezza.
Rimane l’eccessivo consumo di risorse: vera piaga di Java.
Per contro c’è da dire che i linguaggi managed permettono un livello di produttività ben più elevato rispetto ai linguaggi più “tradizionali”. Al solito, un buon programmatore sceglierà lo strumento “migliore” per risolvere i problemi che gli si presentano.
Infine per rispondere sull’uso di sistemi virtualizzati, personalmente li trovo più comodi da gestire rispetto a una macchina non virtualizzata su cui gira tutto, perché mi permettono di “ritagliare” le risorse da mettere a disposizione in maniera molto fine, cambiandole anche “in corso d’opera”, e spostando una macchina virtuale che è diventata troppo onerosa su una macchina reale che è più scarica. Il tutto con disservizi ridotti all’osso o addirittura inesistenti.
Un grosso bonus e aiuto per gli amministratori di sistema.
Scusate se mi sono dilungato troppo: mi rendo conto che avrei potuto farci un articolo. :D