Qualche giorno fa Donald Knuth, uno dei mostri sacri della programmazione, autore di vari libri della serie Art of Computer Programming, ha rilasciato un’intervista a InformIT in cui, tra le altre cose, esprime un parere estremamente negativo sulla attuale tendenza dei produttori hardware verso le architetture multi-core.

Il suo pensiero si può riassumere più o meno con: i produttori hardware non sanno più come migliorare le prestazioni dei loro chip, quindi hanno riciclato l’idea del multiprocessing, mantenendo le prestazioni fisse (o inferiori) su un singolo core, e mettendo diversi core per poter dire che la CPU è più veloce. In questo modo fanno ricadere la “colpa” nel mancato rispetto della legge di Moore (il raddoppio della potenza di elaborazione ogni 18 mesi) sui programmatori, dicendo che non sono in grado di scrivere software adatto alle nuove architetture.

Io, come diceva un saggio, sono “completamente d’accordo a metà col mister”.

Il problema hardware

Tutto si riconduce alla sostanziale stagnazione delle prestazioni delle CPU single-core da qualche anno a questa parte. Si sono raggiunte miniaturizzazioni oltre le quali si rischia di creare corto-circuiti tra i componenti, e frequenze oltre le quali si rischia di generare interferenze tra le piste o, peggio, surriscaldamenti e consumi sproporzionati, che possono portare la CPU a fondere o a esplodere letteralmente in mancanza di sistemi di raffreddamento che sono sempre più esagerati (dai ventoloni da 6″ a 5-6000 giri/minuto a sistemi di raffreddamento a liquido o a celle di Peltier).

Semplicemente sembra che la tecnologia abbia quasi raggiunto il suo limite e, a meno di un “breakthru” nei metodi costruttivi, che comunque molti stanno cercando nel campo ottico o quantistico, sarà difficile spremere ulteriore potenza ai chip.

La soluzione, quindi, è stata quella di riciclare la vecchia idea del multi-processore, ma ottimizzandola: si mettono più processori sullo stesso chip, in modo da non occupare il bus principale di sistema durante le sincronizzazioni tra core, che quindi rimane libero per i trasferimenti da e per la RAM e il resto del sistema. Sono ormai diffusissimi i dual core, e si vedono tri-core, quad-core e anche chip a 8 core.

Il risultato, indubbiamente, è quello di raddoppiare, triplicare, quadruplicare o ottuplicare la “potenza” disponibile.

Il problema software

Dal punto di vista software le cose non sono così semplici, purtroppo.

Il primo problema è quello a carico del Sistema Operativo, che deve garantire una certa sicurezza all’utente: che i suoi dati siano integri. In un’architettura multiprocessore (o multi-core, che è praticamente la stessa cosa) fisicamente vengono eseguite più operazioni contemporaneamente. Questo significa che ognuno dei core può (o potrebbe) modificare la stessa cella di memoria, o magari leggerla mentre un’altro la sta scrivendo, per non parlare dell’accesso contemporaneo a una periferica.

Parte di questo problema viene risolta dall’hardware, che arbitra l’accesso al bus ai processori, ma buona parte viene comunque delegata al S.O., visto che comunque una operazione che un software ritiene “elementare” come può essere scrivere un carattere sullo schermo viene spezzettata in decine o centinaia di istruzioni a livello assembly.

Inoltre il S.O. deve mantenere una certa affinità di un processo con una CPU, per evitare che dopo un context switch, un processo rimbalzi tra una CPU e l’altra, svalidando continuamente la cache relativa, e quindi ammazzando le prestazioni. Ma anche l’affinità deve essere tenuta sotto controllo, per evitare che, morti tutti i processi che giravano su una CPU, i restanti sfruttino solo l’altra, dimezzando le prestazioni.

Questo porta quindi a dei rallentamenti per proteggere zone di memoria o semplicemente per decidere su quale CPU/core debba essere eseguita una certa operazione.

L’altra faccia della medaglia è rappresentata dagli algoritmi: se c’è un solo processo che gira (e che fa calcoli pesanti, per esempio), questo occuperà una sola CPU, mentre l’altra sarà completamente inerte, dimezzando le prestazioni nel caso di un dual-core, o riducendole a 1/8 nel caso di un 8-core. Nel caso di 64 core…

Alcuni algoritmi possono essere resi paralleli, ma anche in questo caso si presentano diversi problemi: per esempio l’algoritmo potrebbe essere parallelizzabile in due “stream” di calcolo, ma allora in una CPU ad 8 core ne sfrutterebbe solo due. Oppure potrebbe essere parallelizzabil, per esempio, con un numero di processi pari a 1/4 del totale dei dati. Ma allora con 16 “dati” si potrebbero sfruttare bene 4 core ma non sfruttarne 8, ma soprattutto con un milione di “dati” si sfrutterebbero bene 250.000 core, ma avendone solo 2 si creerebbero 125.000 processi per core, costringendo il S.O. a gestire questa enorme coda di processi, con la possibilità di passare più tempo a sincronizzare i processi che ad eseguirli.

Visto l’attuale tendenza (2 core, 4 core, 8 core e in aumento costante) è difficile pensare ad algoritmi “ben parallelizzabili” su diverse architetture. In pratica è un bersaglio mobile.

La “terza faccia della medaglia” è data dal fatto che non è affatto semplice, oggi come oggi, scrivere codice parallelo.

Si possono scrivere programmi multiprocesso per isolare i dati da elaborare e comunicare solo tramite dei “bus” (code messaggi, buffer, ecc.) tra i vari processi in esecuzione, oppure multithread, condividendo la stessa area di memoria per evitare l’overhead dei suddetti bus, ma col rischio di andare a sovrascrivere aree di memoria sbagliate e quindi mandando a monte tutti i calcoli effettuati.

I linguaggi di programmazione attuali raramente offrono facilitazioni da questo punto di vista, quindi si tratta di un lavoro fondamentalmente manuale di sincronizzazione e trasferimento dati. Operazioni che rischiano di azzerare i vantaggi di un multicore, se effettuate in modo meno che ottimo.

Conclusioni

La situazione è abbastanza complessa, ma è già stata affrontata in passato, ed esistono tecniche di programmazione e librerie ben collaudate, ma rimane lo scoglio della difficoltà di ottimizzazione, soprattutto rispetto ad architetture che cambiano continuamente numero di core.

Dall’altra parte il multicore è un “male necessario”, altrimenti saremmo ancora fermi a 2 anni fa con le prestazioni, ed il nuovo processore Atom di Intel ne è la dimostrazione: single core a 1.6 GHz più lento del Celeron M a 900 MHz. Certo, consuma meno, ma fornisce prestazioni maggiori solo se in modalità dual-core.

Dovremo quindi abituarci a convivere con questa architettura almeno per qualche anno (poi, per i soliti corsi e ricorsi storici, si tornerà al single core, magari quantistico, finché non si riterrà nuovamente necessario ricorrere ai multi-core quantistici, ecc. ecc.).

Per i programmatori significa adeguarsi ad imparare la programmazione concorrente, e la mia speranza è che i nuovi linguaggi che si stanno affacciando ora sul mondo (D, Vala, ecc.) forniscano strumenti semplici per ottenerla. Con alcuni linguaggi semplicemente è impossibile programmare in modo concorrente, quindi potrebbero essere destinati se non all’oblio almeno a un forte ridimensionamento, in caso non si adeguassero.

Per gli utenti significa capire il proprio PC, e sfruttarlo al meglio. Per esempio lanciare due istanze della stessa applicazione contemporaneamente al lavoro su dati diversi per sfruttare entrambi i core, se l’applicazione non li supporta di suo. Un caso emblematico: compilando software su Linux con make è sufficiente specificare l’opzione -j seguita dal numero di job contemporanei da eseguire. Conviene usare n+1, dove n è il numero di CPU/core, quindi 3 per un dual-core, 5 per un quad-core, ecc. (il +1 serve a sfruttare tutte le CPU in compilazione mentre il processo extra legge o scrive su disco).

Quando una persona diventa programmatore o sistemista, la maggior parte delle volte viene affascinato da cose a cui non dovrebbe nemmeno pensare. Un cristiano potrebbe chiamarle “tentazioni demoniache”, un buddista “ricchezze terrene”, ecc. ecc. Invece sono da evitare il più possibile, e da abbandonare per poter raggiungere la Vera Illuminazione. Vediamone qualcuna.

chmod 777

Questo semplice mantra (che per i file può anche essere “chmod 666″, notate il numero diabolico) permetterà a chiunque di andare a letto con la vostra ragazza, di venire a cena a casa vostra in qualsiasi momento, di “prendere in prestito” la vostra macchina, di leggervi la posta direttamente dalla cassetta, ecc. ecc. ecc.

Seriamente: Questo semplice comando permette, su sistemi Linux e Unix, di accedere a qualsiasi risorsa (a un file, in realtà, ma in Unix/Linux TUTTO è un file) senza alcuna limitazione. Guardatevi da esso, poiché è il male. A parte dare il permesso di esecuzione (che nelle directory serve per poterci entrare, ma nei file rende eseguibile il file stesso) concede pieni poteri sul file a qualsiasi utente: lettura, scrittura, modifica, azzeramento. Forse l’unica cosa che non si può fare è cancellarlo (servono permessi equivalenti sulla sua directory). Può sembrare che risolva tutti i propri problemi (non devo più diventare root per modificarlo!), ma ci sono un sacco di motivi per cui Windows è pieno di virus e Linux no. Il fatto che le distribuzioni non usino mai chmod 777 è uno di questi.

Se un fiile ha un certo set di permessi è proprio perché nessuno, per errore o intenzionalmente, lo modifichi. Aprendo in questo modo i permessi di accesso si consente a programmi impazziti, a servizi bucati da cracker o semplicemente a un errore di digitazione di fare danni seri. Pensate a quale sia la differenza tra un “rm -Rf /” dato da utente (cancella solo i file a cui ha accesso l’utente, quindi solo la sua home e pochi file in /tmp) e dato da root (cancella tutto il sistema operativo).

goto

Qui entriamo nel campo della programmazione. Ormai è risaputo che goto è la fonte di tutti i mali, l’anticristo, il limone sulla Nutella. Lo dicono perfino Dijkstra e Wirth! (I link sono alla Wikipedia italiana, ma quella inglese è più completa). goto vi farà uscire di strada in macchina (goto fosso), vi farà entrare nello sgabuzzino invece che in bagno (goto bin). Potreste perfino finire a letto con un uomo invece che con una ragazza (goto man)! Attenti!

Seriamente: goto, se usato male (e nel 99% dei casi viene usato male) rende “spaghetti-code” i vostri programmi. Fa perdere velocemente il flusso logico delle procedure/funzioni, e porta a errori inaspettati (“ma questo codice non doveva essere eseguito quando questa variabile ha questo valore!”). Linus Torvalds lo può usare perché lui sa quello che fa.

global

Qui parlo in generale delle variabili globali. C’è un motivo per cui sono state inventate la programmazione strutturata e quella ad oggetti. Le variabili globali sono una macchina del tempo rotta, che ci porta solo indietro di 50 anni: guerra (o primo dopoguerra), malattie, dispersi, fame, ecc. ecc.

Seriamente: usare variabili globali è pericoloso quanto e forse più che usare goto: queste variabili possono venire modificate da altre funzioni che non c’entrano niente con quello che stiamo facendo, ed è impossibile sapere con esattezza, guardando il codice, che valore hanno in un certo punto. Passate valori alle funzioni, impostateli in qualche variabile di classe, ma guardatevi sempre dall’usare variabili globali. Hanno senso solo in pochissimi casi, e, se siete dei principianti, in NESSUN caso.

In PHP questo comprende anche l’uso di register_globals. Questa direttiva (che per fortuna verrà disabilitata e sarà reso impossibile abilitarla conla versione 6 di PHP) prende tutte le variabili che arrivano dall’esterno del vostro script (quindi GET e POST, i cookies, i valori in sessione, le variabili d’ambiente) e le mette tutte in un minestrone, rendendole variabili globali. C’è un ordine preciso di “riempimento” di questo minestrone, ma vi sfido a capire, a colpo d’occhio, se una variabile sia stata passata da GET o se arrivi dalla sessione dell’utente. Molto meglio usare le superglobals: $_GET, $_POST, $_COOKIES, $_SESSION e $_ENV (oltre a $_SERVER).

addslashes()/stripslashes()/magic_quotes

Qui si parla specificatamente di PHP. Il giorno che queste funzioni verranno tolte da PHP probabilmente smetterà di piovere folgore dal cielo, o più probabilmente un\\\’infinita\` di pagine web l\’una coi caratteri più sballati dell\\\’altra, e parecchi casi di SQL-injection spariranno dalla rete.

Seriamente: poche cose in una pagina web hanno bisogno delle barre prima di un carattere. Può sembrare giusto prima di infilare una stringa in MySQL (per cui la ‘ è un carattere speciale e, se contenuta in una frase, fa “escapata” con \’), ma, per esempio, in PostgreSQL il modo giusto di fare l’escape è ” (due virgolette singole) e non \’, quindi i vostri script non funzioneranno cambiando DB. Usate mysql_real_escape_string(), pg_escape_string() o, meglio ancora, PDO o un framework come Zend Framework. Per passarle su un URL (un link con <a>, per esempio) la funzione giusta è urlencode(). addslashes non è quasi mai la risposta giusta. Vale la stessa considerazione di global: se siete principianti, addslashes() non è MAI la risposta giusta.

<font>, <b>, <i>, <frame> (guest stars: <table>, <br>)

Entriamo nel mondo del web dalla porta sul retro: HTML. Il poveretto era nato con buonissime intenzioni: l’ipertesto, la digitalizzazione e il collegamento delle informazioni, la diffusione della cultura. Ma tre bambini cattivi (non facciamo nomi, solo iniziali: MS, NS e MM) gli hanno regalato le caramelle fuori dalla scuola, e da allora si sta disintossicando in diverse comunità di recupero. Per fortuna ultimamente ha trovato un bel po’ di amici che lo stanno tirando fuori dal tunnel, ma ci sono ancora un sacco di bambini cattivi in giro!

Seriamente: L’HTML è nato per descrivere la struttura delle informazioni, non la loro rappresentazione sullo schermo. Usare editor WYSIWYG facilita sicuramente lo scrivere pagine web, ma avete mai provato a modificare il posizionamento di un’immagine senza usare quegli editor, o ad aggiungere un’immagine in mezzo alle altre, anche CON quegli editor? Da un po’ il W3C ha preso una posizione netta sulla questione: l’HTML deve descrivere solo COSA è una certa informazione, mentre il COME FARLA VEDERE è compito dei CSS. COME SI COMPORTA è compito di Javascript (o ECMAscript), e con questo il cerchio si chiude. font, b e i sono (finalmente) tag deprecati. Un testo non è “Arial 18px bold italic”, ma “titolo di sezione”, quindi <h2> (per esempio). Una frase importante non è “bold”, ma “importante” (strong) appunto! Prima si impara a usare i tag giusti, meglio è.

Ho messo come guest star <table> e <br> perché si devono ancora usare, ma solo quando è giusto usarli. Non si usa <table> per definire il layout di una pagina, ma solo per intabellare dati. Non si usa <br> per fare spazio con le righe vuote, ma solo per andare a capo senza chiudere un paragrafo (che è <p>).

Una malattia molto diffusa per chi si avvicina ai CSS è la DIVite (accompagnata dalla SPANite): quando non si sa cosa mettere, si mettono un div o uno span, dimenticando che esistono decine di tag che non usa nessuno. Una lista della spesa è <ul>, una lista di passi per una ricetta è una <ol>. Una lista di definizioni da vocabolario è <dl>. Un’etichetta da dare a qualcosa è <label>. La legenda di una tabella è <caption>. Una breve citazione è <q>, mentre una citazione lunga è <blockquote>. Un indirizzo è <address>. Ecc. ecc. Imparate a usare i tag giusti al momento giusto, e il vostro codice sarà molto pià leggibile (e modificabile, che è la cosa più importante). Quando ci sarete arrivati, date un’occhiata anche ai Microformati, tenendo conto che ci sono già estensioni per Firefox che li usano, e che in futuro saranno sempre più diffusi e richiesti. E non dimenticate di impostare il DOCTYPE corretto!

Conclusione

Per ora chiudo qui, ma sono sicuro che ho dimenticato un sacco di cose. La morale è sempre la solita: diffidate delle strade che sembrano troppo semplici. Sicuramente c’è qualcosa che non va.