Sistemi operativi personalizzati
Ai vecchi tempi dei supercomputers (gli anni '70), era difficile trovare sistemi operativi ricchi e allo stesso tempo stabili. Lavoravo allo sviluppo di un sistema, all'epoca, e posso dire con certezza che non ne esistevano con quelle caratteristiche. Facevamo del nostro meglio, ma sapevamo che eravamo lontani dal risultato che volevamo. Chiunque abbia lavorato su un grande sistema di computers, sa che deve essere pronto alla frustrazione per reggere il carico di lavoro, che può essere anche di 100 ore alla settimana. Spesso si arrivava ad un annullamento del progetto, in particolare perché i progettisti non si preoccupavano abbastanza dell'utente. L'obiettivo era di mettere insieme un SO che funzionasse e fosse anche utile.
Oggi ci sono molti sistemi, ricchi di funzionalità e più o meno stabili. Però la loro sopravvivenza dipende dalle grandi compagnie che li producono, e che li rendono via via più completi; non è inusuale, infatti, aggiornare il sistema almeno una volta al mese, se non altro per le patch di sicurezza.
I supercomputers offrono una facile soluzione; il loro sistema operativo non ha bisogno di sofisticazione, e l'interfaccia grafica (GUI) è superflua. È un elemento importante, ma può essere completamente ospitata da un PC collegato al supercomputer, ed è quindi la GUI del PC quella che si usa. Il sistema operativo del supercomputer può essere ridotto ai minimi termini in base alle applicazioni, non ai bisogni dell'utente. Non avrebbe molto senso trasferire un sistema operativo per PC su un supercomputer, tranne che in casi particolari, come quello rappresentato da Linux. I PC sono fatti per l'utente, i supercomputer per far girare le applicazioni velocemente, e non c'è ragione per mischiare questi due concetti.
Oggi l'accoppiata Linux/supercomputer è sempre più comune. Linux è un sistema gratuito, e mantenuto da una schiera di appassionati guidati dallo scopo di dimostrare che il loro S.O. è quello definitivo. L'idea di fondo è ottima, il problema è che gli aggiornamenti vanno selezionati con la lente d'ingrandimento, che è un po' il tallone d'Achille del freeware in generale. La buona notizia è che tutto ciò di cui abbiamo bisogno è un sistema Linux di base, insieme a poche parti di applicazioni, per compiti come il multithreading e simili. Queste parti di codice, probabilmente, sono a pagamento, ma normalmente il supporto è ottimo, e migliorano tantissimo con il passare del tempo, per via della concorrenza.
La comunicazione tra processori è vitale. Le applicazioni devono essere distribuite tra decine di migliaia di processori, e tutti i processori devono essere sincronizzati. La sincronizzazione richiede una comunicazione, gestita dal sistema operativo (calls); quindi il tempo che il SO ci mette per gestire queste chiamate è vitale per determinare le prestazioni generali del sistema.
Il miglior approccio, orientato alle prestazione dell'applicazione, sta nell'aggirare il SO e permettere la comunicazione diretta tra i vari processi in corso, tramite l'interfaccia multiprocessore (MPI). Alcune MPI, ingegnosamente, permettono la comunicazione diretta senza creare confusione, pur evitando di passare per il sistema operativo. La coda di lavoro della MPI è gestita da una subroutine a livello dell'applicazione. Quindi, si può ridurre ulteriormente il livello di complessità del sistema operativo, con la MPI. Non sarebbe fantastico che il sistema operativo supportasse direttamente le richieste della MPI?
Un'altra area che ha bisogno di soluzione creative è quella della risoluzione dei problemi, e della visualizzazione dello stato del sistema. I supercomputers, normalmente, hanno migliaia di processori, con migliaia di possibili vie di comunicazione. Non esiste nessun passaggio prevedibile da processore a processore. È un fatto che può generare una certa ansietà, quando si tenta di trovare un difetto nei collegamenti, o un processore “pigro”. La salvezza sarebbe un sistema di visualizzazione dello stato che funzionasse anche come strumento di correzione, se solo esistesse…
Ecco, quindi, un altro buon modo di tenere i supercomputers lontani dall'ufficio; usate un sistema operativo che impedisce la comunicazione diretta tra le applicazioni. In questo modo otteniamo due effetti collaterali, entrambi debilitanti. Il primo sono i costi: un sistema operativo personalizzato assorbirà moltissime risorse monetarie per continuare a funzionare, rendendolo poco interessante, a meno che non abbiate abbondanza di fondi. Le aziende trovano, in genere, poco stimolante investire in un sviluppatore che faccia questo lavoro. L'altra questione riguarda le risorse umane: dovrete almeno raddoppiarvi per far funzionare l'applicazione nonostante il sistema operativo, e quindi ci vorrà un ufficio più grande. Altro punto dolente, per chi amministra l'azienda.