Un tema ricorrente della fantascienza è quello dell’uomo che viene dal futuro. E, ovviamente, esistono parecchi dibattiti su cosa potrebbe mai fare un uomo del futuro se, improvvisamente, arrivasse nel nostro tempo. Qui il problema diventa interessante.

Se io finissi nel Medioevo, probabilmente potrei anticipare alcune tecniche, ma sarebbero poca cosa rispetto a ciò che conosco oggi. Sarei forse riconosciuto come inventore, magari persino come inventore geniale, ma poco più. In campo militare potrei forse accelerare lo sviluppo e la diffusione di artiglierie e razzi, ma non potrei davvero dire di averli inventati: i razzi a polvere esistevano già nella Cina medievale, e l’artiglieria a polvere comparve anche in Europa durante il tardo Medioevo.

Potrei forse tentare qualcosa nel campo delle macchine termiche. Il problema è che conoscere il principio di funzionamento di una macchina non significa automaticamente essere capaci di costruirla con la tecnologia disponibile. Con le tecniche metallurgiche e meccaniche medievali non è semplice produrre un cilindro, un pistone e soprattutto delle tenute abbastanza precise da ottenere una macchina efficiente.

Qualcosa concettualmente simile a una primitiva macchina di Stirling sarebbe forse possibile, almeno come dimostratore: il principio è relativamente semplice e non richiede una caldaia ad alta pressione. Ma tra sapere come dovrebbe funzionare e costruirne una capace di erogare una potenza realmente utile rimarrebbe una distanza tecnologica considerevole. Non a caso il primo motore Stirling realmente impiegato risale al 1818.

Magari, con espedienti come accoppiamenti tra bronzo e ferro, qualcosa si potrebbe fare, ma sarebbe complicato. Bisognerebbe sperimentare parecchio con le combinazioni di materiali disponibili all'epoca: bronzo e ferro, bronzo e pietra, ferro e pietra, legno dove possibile. Ma ne uscirebbero facilmente macchine complicatissime, inefficienti e fragili.

Il problema, cioè, è che mi mancherebbero le fondamenta tecnologiche necessarie per portare all'indietro delle nozioni che, per noi, sono elementari.

Io so perfettamente cos'è un pistone. So come funziona un cilindro. So cos'è una valvola, conosco una macchina a vapore e conosco il principio di una macchina di Stirling. Ma questo non significa che sappia costruire, partendo da una fucina medievale, un cilindro abbastanza regolare, un pistone abbastanza preciso, delle tenute affidabili e delle superfici lavorate con tolleranze sufficienti.

E non è soltanto una questione di conoscenze: dietro oggetti che oggi consideriamo banali esiste una supply chain notevole. Servono materiali con caratteristiche abbastanza prevedibili, utensili capaci di lavorarli, altri utensili capaci di costruire quegli utensili, sistemi di misura, tecniche di fusione e lavorazione, e persone che sappiano fare tutte queste cose con una certa ripetibilità. Insomma: potrei portare nel Medioevo l'idea della macchina. Ma non necessariamente la civiltà industriale necessaria per costruirla.

---

Abbiamo due problemi, quindi, se vogliamo tornare indietro e fare tutto il lavoro daccapo.

Per prima cosa, le fondazioni. Bisogna avere idea di come si costruiscono le cose. Non semplicemente di come funzionano, ma proprio di come si costruiscono. Probabilmente, già nel Rinascimento, con i materiali giusti e una quantità indecente di tentativi, si sarebbe potuto costruire qualcosa che oggi riconosceremmo come un rudimentale dispositivo a semiconduttore: per esempio un raddrizzatore a cristallo. Il problema sarebbe stato ottenere materiali abbastanza puri e contatti abbastanza affidabili da mostrare qualcosa di ripetibile.

E alla fine quale sarebbe stata la grande dimostrazione? «Guardate: la corrente passa molto meglio in una direzione che nell'altra».

E loro: e che diavolo sarebbe questa “corrente”?

Fantastico.

Non sarebbe fregato un cazzo a nessuno, considerando il lavoro necessario per ottenere materiali decenti e il fatto che, intorno a quell'oggetto, non esisteva ancora praticamente nulla che potesse servirsene.

Il secondo problema è, appunto, la supply chain.

Non riuscirete mai a ottenere una tecnologia senza avere prima almeno una parte della base industriale necessaria a costruirla.

Erone di Alessandria, nel I secolo, descriveva già l'eolipila: una sfera fatta ruotare dalla reazione di getti di vapore. Quindi il principio secondo cui il vapore poteesse produrre movimento era lì, visibile, quasi duemila anni prima della rivoluzione industriale.

Ma era poco più di un dispositivo dimostrativo. Girava, certamente, ma non era una macchina progettata per trasferire quantità significative di potenza a un carico.

Per arrivare a una macchina a vapore che funzioni davvero non basta sapere che il vapore spinge.

Occorrono cilindri sufficientemente regolari, pistoni che combacino abbastanza bene, valvole, tenute, metallurgia ripetibile, strumenti di misura e soprattutto macchine utensili capaci di costruire con precisione altre macchine. Quando nel Settecento si cominciarono a produrre cilindri molto più precisi mediante alesatura, le macchine a vapore fecero un salto enorme.

Occorre quindi finire in un mondo sufficientemente avanzato da consentire l'invenzione, non semplicemente la scoperta.

Per quanto noi sappiamo immensamente più di quanto si sapesse nel passato, probabilmente non riusciremmo a spacciarci per grandi scienziati. Molti dei principi che conosciamo sarebbero incomprensibili, oppure completamente inutili senza tutto ciò che deve esistere intorno a essi.

Potremmo invece diventare grandi inventori, a una condizione: dominare abbastanza bene la tecnologia primitiva del periodo e, contemporaneamente, conoscere il passo immediatamente successivo.

Non si tratta di prendere uno stadio tecnologico n e saltare direttamente a n + 100. A n mancano precisamente le novantanove industrie, tecniche, conoscenze pratiche e supply chain necessarie per costruire n + 100.

Bisogna procedere per piccoli passi: da n a n + 1.

Saremmo forse più fortunati nelle arti “liberali”, perché lì alcune idee richiedono molta meno infrastruttura materiale.

Potremmo anticipare la scoperta europea delle Americhe, per esempio, con tutte le conseguenze devastanti che ne deriverebbero. Potremmo portare ai Romani un sistema contabile basato sulla partita doppia: avevano una contabilità sorprendentemente sviluppata, ma non risulta che possedessero la partita doppia nel senso che acquisterà più tardi nel mondo mercantile italiano.

Oppure potremmo semplicemente spiegare ai medici di lavarsi le mani.

Persino con l'ottica incontreremmo lo stesso problema. Produrre lenti veramente buone è complicatissimo: bisogna saper scegliere il vetro, lavorare le superfici con precisione, controllarne la curvatura e lucidarle senza rovinarne la geometria. Non per niente bisogna arrivare all'epoca di Galileo perché il telescopio diventi rapidamente uno strumento realmente utile.

Potremmo pensare di aggirare il problema usando uno specchio. L'idea del telescopio riflettore non richiede affatto Newton per essere concepita: già all'inizio del Seicento si fecero tentativi con specchi concavi, ma ottenere uno specchio con la forma e la superficie necessarie per produrre un'immagine decente era a sua volta un notevole problema tecnologico.

E anche qui bisognerebbe trovare l'ascoltatore giusto.

Galileo lo trovò nella Repubblica di Venezia. Nel 1609 mostrò il suo cannocchiale alla Signoria e ai senatori veneziani facendo osservare, dai campanili, navi che erano ancora così lontane da richiedere ore prima di diventare visibili a occhio nudo. L'utilità militare e commerciale dello strumento era immediatamente evidente.

E i telescopi diventarono anche un'attività economicamente interessante: all'inizio del 1610 Galileo scriveva di averne già costruiti più di sessanta, molti dei quali finirono venduti o distribuiti.

Questo, per fare un esempio, funzionava.

Ma difficilmente riusciremmo ad andare molto oltre.

---

E qui sarebbe la mia teoria. Un uomo del futuro, a patto di avere conoscenze simili a quelle di Cyrus Smith, l’ingegnere de L’isola misteriosa di Jules Verne, uno di quegli ingegneri ottocenteschi letterari che non sanno soltanto come funzionano le cose: sanno come rifarle partendo quasi da zero. non apparirebbe come uno scienziato geniale, al massimo come un ingegnere creativo, o un creativo tout-court.

Ecco la mia teoria: un uomo del futuro sarebbe indistinguibile da un inventore del suo tempo, e un inventore del suo tempo da un uomo del futuro.

---

A sostegno, ho un esempio.

Cosa direste se io vi spiegassi che nel 1987 — e ripeto: nel 1987 — qualcuno aveva costruito, non semplicemente immaginato, una macchina che anticipava concettualmente CUDA, il calcolo su GPU, il data-parallel computing, il superparallelismo, il calcolo vettoriale massivamente parallelo, i virtual processor, la memoria distribuita, il routing hardware tra migliaia di unità di calcolo, le operazioni globali di reduce e broadcast, il graph computing, le sparse matrix operations, le simulazioni cellulari, le reti neurali parallele e perfino, in forma ancora embrionale, l'idea che convenga portare il calcolo verso i dati invece di spostare continuamente i dati verso un unico processore?

Non aveva “inventato CUDA”, naturalmente. Non aveva “inventato MapReduce”. Non aveva “inventato le GPU”.

Aveva però già messo insieme molti dei concetti architetturali che oggi consideriamo moderni: migliaia di processori semplici, enormi quantità di parallelismo, dati distribuiti, comunicazione tra nodi gestita dalla macchina, e un modello di programmazione nel quale non si pensa più a un processore che esegue una sequenza di istruzioni, ma a una popolazione di processori che esegue contemporaneamente operazioni su una popolazione di dati.

Nel 1987.

Parliamo dei sistemi di CM, la “Connection Machine”.

La Connection Machine non fu una singola macchina, ma una famiglia progettata da Thinking Machines, la società fondata da Danny Hillis e Sheryl Handler. Il punto interessante, è che CM-1 e soprattutto CM-2, del 1987, sembrano quasi un catalogo di idee che oggi consideriamo normali, solo realizzate quando il normale computer era ancora sostanzialmente una CPU abbastanza grossa che parlava con una memoria abbastanza grossa.

La CM-2 poteva avere 65.536 processori elementari, ciascuno semplicissimo e dotato della propria memoria. Non cercava quindi di costruire un processore mostruosamente veloce: cercava di costruire una quantità mostruosa di processori piccoli. Oggi diremmo massively parallel computing. È la stessa inversione concettuale che sta dietro alle GPU moderne: non fare un'operazione alla volta molto velocemente, ma fare una quantità enorme di operazioni contemporaneamente.

E qui cominciano le genialate.

• Un'istruzione, una quantità enorme di dati. La CM-1 e la CM-2 erano SIMD: un controllo centrale diceva a migliaia di processori di eseguire contemporaneamente la stessa operazione sui propri dati. Oggi il parente concettuale più evidente è GPU computing, CUDA, OpenCL, SIMT/data parallelism. Non è CUDA ante litteram, ma l'idea fondamentale è quella: scrivo essenzialmente cosa deve succedere a ciascun elemento, e la macchina lo fa in parallelo su una popolazione enorme di elementi.
• Il computer principale diventa il coordinatore dell'acceleratore. La Connection Machine aveva normalmente un computer convenzionale davanti — una workstation Sun, una VAX o una Lisp Machine — che eseguiva il programma e impartiva il lavoro alla macchina parallela. Oggi diremmo, molto naturalmente, host CPU + accelerator: praticamente il modello con cui programmiamo una GPU.
• I dati stanno vicino al processore che li usa. Ogni processing element disponeva della propria memoria. Non c'era l'idea di decine di migliaia di CPU che litigano per accedere a un'unica RAM centrale: dati e computazione venivano distribuiti. Oggi questo concetto ricompare continuamente sotto nomi diversi: distributed memory, local memory, NUMA, accelerator memory, compute-near-data. La documentazione del successivo CM-5 dice esplicitamente che, aumentando i processori, memoria condivisa e bus diventano colli di bottiglia e che quindi memoria e comunicazione devono essere distribuite.
• Non programmi i processori: programmi i dati. In Lisp, C e successivamente CM Fortran si potevano descrivere strutture di dati parallele e applicare operazioni collettivamente. La documentazione di Thinking Machines fa esempi quasi comici da leggere oggi: un documento per processore, un pixel per processore, una cella di automa per processore. Oggi diremmo array programming, data-parallel programming, kernels, tensor operations, e in parte penseremmo a CUDA, NumPy, JAX o framework simili.
• Più elementi logici che processori fisici. La CM possedeva i cosiddetti virtual processors. Il programmatore poteva ragionare come se avesse molti più processori di quelli realmente installati; l'hardware e il software multiplexavano gli elementi virtuali sui processori fisici. Si arrivava a oltre un milione di processori virtuali. Oggi l'idea ci sembra banalissima: logical threads, work items, massive oversubscription, cioè descrivere un parallelismo logico molto superiore alle unità fisiche disponibili e lasciare alla piattaforma il compito di schedularlo.
• La rete faceva parte del computer. I 4.096 chip della CM-1/CM-2 erano collegati secondo un ipercubo a dodici dimensioni, così che qualunque chip fosse raggiungibile in non più di dodici passi. Inoltre esisteva hardware dedicato al routing dei messaggi. Oggi penseremmo immediatamente a high-speed interconnect, network-on-chip, cluster fabric, e a tutto il problema moderno di come spostare dati velocemente tra migliaia di unità di calcolo.
• Il routing non era lasciato al programmatore. Tu descrivevi dove dovevano finire i dati; la rete della CM provvedeva a farli arrivare, gestendo contemporaneamente un numero enorme di comunicazioni. Concettualmente è molto vicino all'idea moderna di message routing hardware, delle fabric HPC e, più alla lontana, di cose come RDMA: il trasferimento dei dati non deve trasformarsi in un lavoro manuale della CPU centrale.
• Operazioni collettive. Broadcast, comunicazioni globali, combinazione e distribuzione di risultati erano parte naturale del modello. È qui che puoi citare con prudenza map/reduce: non il MapReduce di Google, che comprende un modello distribuito, fault tolerance, shuffle su cluster eccetera, ma le primitive concettuali map, reduce, scan, broadcast e redistribuzione dei dati erano precisamente il genere di operazioni per cui quelle macchine erano costruite.
• Sparse matrix e graph computing. Una macchina nella quale ogni elemento possiede dati propri e può comunicare attraverso una rete era naturalmente interessante per grafi, matrici sparse, automi cellulari, PDE e simulazioni fisiche. Oggi diremmo graph processing, sparse computation, scientific GPU computing. Già nel 1988 venivano pubblicati risultati di calcolo scientifico su tutti i 65.536 processori della Connection Machine.
• Reti neurali sulla macchina parallela. La Connection Machine nasceva esplicitamente anche dall'ambiente dell'AI del MIT e dall'idea di ottenere comportamento complesso da un'enorme quantità di elementi semplici interconnessi. Non era una GPU per il deep learning, ovviamente; ma era una piattaforma quasi naturalmente adatta al connectionism, alle reti neurali e ai modelli nei quali molti nodi fanno simultaneamente operazioni semplici. Ed è difficile non vedere la parentela filosofica con gli acceleratori AI odierni.
• Acceleratori specializzati dentro una macchina parallela. La CM-2 aggiunse unità hardware in virgola mobile condivise da gruppi di processori elementari. Anche qui non direi “tensor core del 1987”, perché sarebbe troppo; ma l'idea di avere una massa di elementi generalissimi affiancata da unità specializzate per le operazioni numeriche costose è terribilmente moderna.
• Storage parallelo. Il DataVault distribuiva i dati su molti dischi e più DataVault potevano lavorare contemporaneamente; i dati potevano essere trasferiti direttamente verso le sezioni della macchina parallela. Oggi diremmo striped parallel storage / parallel I/O. E il DataVault adottava ridondanza ed error correction in una forma che retrospettivamente viene classificata come RAID-2, prima ancora che il termine RAID diventasse comune.
• La rete diventa più importante del singolo processore. Questa idea diventa ancora più evidente con la CM-5 del 1991: Thinking Machines abbandona il gigantesco SIMD di processori a un bit, passa a centinaia o migliaia di nodi SPARC con memoria locale e costruisce attorno a essi una fat-tree network ad alta banda. Oggi una fat tree/Clos è esattamente il genere di struttura che associamo ai grandi cluster e ai data center. La CM-5 aveva addirittura reti separate per dati, controllo e diagnostica.
• SIMD quando conviene, MIMD quando serve. La CM-5 non obbligava più tutti i nodi a fare esattamente la stessa cosa: potevano operare indipendentemente, ma restava il supporto per l'esecuzione sincronizzata data-parallel. Oggi diremmo che stai combinando distributed computing, SPMD e vector/SIMD acceleration nella stessa macchina.

E secondo me la genialata più premonitrice non è nessuna di queste singolarmente.

È l'astrazione.

Hillis aveva sostanzialmente detto: smettiamo di pensare al computer come a un processore che possiede della memoria. Pensiamolo come a una popolazione di elementi computazionali che possiedono ciascuno dei dati, e costruiamo una rete abbastanza intelligente da permettere loro di collaborare.

Nel 1987 sembrava una maniera piuttosto esotica di costruire un supercomputer. Eccola, in una foto.

E faccio notare che quei LED non servivano praticamente a nulla.

Ma qualcuno, evidentemente, aveva già deciso che se mettevi un computer dentro un rack alto quanto un armadio, allora ci dovevano essere dei LED. Molti LED. Possibilmente abbastanza da far capire, anche da lontano, che lì dentro stava succedendo qualcosa di molto interessante.

Oggi si chiama semplicemente un rack.

Ma nel 1987 quasi tutta l'industria dei supercomputer stava andando nella direzione opposta.

L'idea dominante era: costruire pochi processori sempre più potenti, sempre più veloci, con registri vettoriali enormi e memorie capaci di alimentarli abbastanza in fretta. Era, grosso modo, la filosofia Cray.

La Connection Machine faceva quasi il contrario: prendeva decine di migliaia di processori stupidissimi, dava loro della memoria locale, li collegava con una rete mostruosa e diceva: adesso lavorate tutti insieme.

Non era la prima macchina parallela della storia, naturalmente. Esistevano già SIMD, vector processor e predecessori come ILLIAC IV.

Ma nessuno aveva portato quella filosofia fino a quel livello di esasperazione: 65.536 processori, (nel cazzo di 1987!!!!) virtual processor, memoria distribuita, routing hardware e un modello di programmazione nel quale il programmatore ragionava sui dati, non sulla CPU.

Cray, che in quel periodo rappresentava praticamente l'aristocrazia del supercomputing, sarebbe arrivata al massively parallel processing soltanto negli anni Novanta.

E quando ci arrivò, con il Craylink e il uniCOS e tutto quanto, il mondo che Thinking Machines aveva cominciato a costruire sembrava già molto meno assurdo.

---

Potete continuare a studiare la macchina, e troverete cose come un'architettura di interconnessione a ipercubo a dodici dimensioni, nella quale ogni nodo è identificato da un indirizzo binario e ogni bit dell'indirizzo corrisponde, di fatto, a una dimensione del cubo.

Per capire quali passi separano due nodi basta fare lo XOR dei loro indirizzi: ogni bit a uno segnala una dimensione lungo la quale bisogna ancora muoversi. La distanza tra due punti dell'ipercubo diventa quindi semplicemente il numero di bit diversi tra i due indirizzi, cioè la loro distanza di Hamming.

In pratica, un “lattice” a dodici dimensioni nel quale una parte enorme del problema del routing viene ridotta a operazioni logiche elementari sugli indirizzi, invece di richiedere tabelle gigantesche o algoritmi complicati per decidere ogni volta dove mandare un dato.

E tutto questo non era un esercizio accademico: serviva a far comunicare migliaia di processori e a spostare enormi quantità di dati attraverso la macchina senza trasformare la rete interna nel collo di bottiglia dell'intero sistema.

Ed è questo che fa impressione.

Più si entra nei dettagli, più si trovano idee che oggi ci sembrano naturali: topologie pensate per scalare, indirizzamento che incorpora la geometria della rete, routing hardware, parallelismo spinto, memoria distribuita, calcolo vicino ai dati.

C'è tanta di quella roba che oggi chiameremmo moderna lì dentro, e così poca roba che sembra appartenere davvero al 1987, da fare quasi paura.

E poi, l'idea di metterci led inutili e una forma stravagante, per farle apparire in questo modo:

che diavolo avevano in mente?

---

Se io vi dicessi che un ingegnere di NVIDIA e uno di IBM, arrivati dal 2026, fossero finiti nel 1987 e avessero costruito un supercomputer usando soltanto i mezzi disponibili all'epoca, ovviamente mi dareste del pazzo.

Ma santiddio, se poi scendessimo nel tecnico, fareste tanta, tanta, tanta fatica a dimostrare che la storia è inverosimile.

Perché quasi tutti i concetti avanzati che riconosciamo nei prodotti del 2026 sono già lì dentro.

Certo: sono costruiti come una macchina di Stirling costruita dai Romani dopo che qualcuno gli ha passato il progetto. Rozza, gigantesca, costosa, fatta con quello che esisteva allora.

Ma l'idea è quella.

Nel 1987 questi avevano già dati distribuiti tra migliaia di memorie locali, processori assegnati ai dati, processori virtuali, routing hardware per spostare informazioni da una parte all'altra della macchina e primitive collettive come scan e reduce.

Non avevano MapReduce nel senso di Google, naturalmente.

Avevano però già costruito buona parte dei meccanismi architetturali dai quali un'idea come MapReduce diventa quasi ovvia: distribuire i dati, portare il calcolo dove sono i dati, fare la stessa operazione su una popolazione di elementi e poi raccogliere o redistribuire i risultati.

In hardware.

Nel 1987.

---

Certo, i due fondatori non erano dei pirla qualsiasi. E tra quelli che finirono a lavorare sui problemi matematici della macchina c'era anche un tale Richard Feynman.

Perché non ci facciamo mancare niente.

Ma se provo a immaginare due ingegneri arrivati dal 2026, uno di NVIDIA che progetta GPU e uno di IBM che disegna mainframe, finiti per sbaglio nel 1987 e costretti a costruire qualcosa usando soltanto la tecnologia disponibile allora, beh: questo è più o meno quello che farebbero.

Prenderebbero migliaia di processori relativamente stupidi, distribuirebbero la memoria, costruirebbero una rete per farli comunicare, inventerebbero un modo per assegnare enormi quantità di dati a enormi quantità di unità di calcolo e cercherebbero di nascondere tutta questa mostruosità dietro un'astrazione programmabile.

Ah, sì.

Oggi una parte importante di tutto questo la chiamiamo semplicemente GPU.

E allora il sospetto che, periodicamente, qualcuno cada dal futuro e finisca nel nostro presente diventa, santiddio, difficile da togliersi dalla testa.

E ri-ecco la mia teoria: un uomo del futuro sarebbe indistinguibile da un inventore del suo tempo, e un inventore del suo tempo da un uomo del futuro.

Tadaaa...

---