Il passaggio al multicore è il segreto per l’aumento delle prestazioni. Spesso però si verificano dei problemi a causa di conflitti di risorse: due parti di un programma tentano di utilizzare la stessa risorsa (memoria, dati, periferiche) e si scontrano in qualche modo. Freescale e CriticalBlue hanno realizzato un software di nome Prism che analizza il punto in cui le risorse entrano in conflitto per correggere velocemente il codice.
Dual core, quad core, multicore… e molti problemi!
Il passaggio al multicore è ampiamente accettato come la soluzione futura del settore informatico per soddisfare le esigenze di prestazione nell'ambito di un bilancio di potenza accettabile. Purtroppo, si hanno in mano milioni di righe di codice collaudato sul campo, ma scritto per un singolo core. Come fare per migrare in modo sicuro che ad un paradigma del tutto nuovo?
Chiunque passi ad un’architettura multicore è preoccupato per una particolare classe di bug legati all’elaborazione parallela. Questi sono in linea di principio gli stessi tipi di errori che si possono facilmente incontrare nei software multi-threaded: dipendenze dei dati (comportamento lento perché una parte di un programma è in attesa di un altro alla fine); condizioni di competizione (una funzione utilizza una risorsa prima che la risorsa sia pronta), o addirittura di stallo (in cui due diverse porzioni di un programma sono in attesa di un altro, con conseguente lock-up della CPU).
Come regola generale, tutti questi problemi col multicore sorgono a causa di conflitti di risorse: due parti di un programma tentano di utilizzare la stessa risorsa (memoria, dati, periferiche) e si scontrano in qualche modo. Il software che contiene questi problemi è una "risorsa errata." Trovare questi problemi è estremamente difficile perché il programma deve essere in esecuzione. Anche allora le circostanze che causano il conflitto possono essere difficili da ricreare o prevedere. Quando si inserisce il software non corretto su una piattaforma multicore, le probabilità che si verifichino dei problemi sono anche superiori con le applicazioni multi-threaded. Questo perché i core eseguono in modo indipendente in modo che ci sia un’autentica elaborazione parallela e non solo un’accelerazione.
Prism: una possibile soluzione per il multicore
Ma Prism, un software di programmazione multicore, aiuta a risolvere il problema. Come? Freescale è impegnata in questo con CriticalBlue Ltd - un fornitore di software di analisi multicore con sede a Edimburgo. Usando il software LTE Layer 2 come banco di prova, hanno applicato CriticalBlue di Prism, un strumento di analisi del software multicore, per individuare rapidamente il codice sub-ottimale in esecuzione sul processore MPC8572. L'analisi ha permesso di migliorare le prestazioni del codice di quasi il 40 per cento. In termini reali, questo significa che si possono stipare in più canali e rendere la soluzione integrata più competitiva.
Freescale prevede di aggiungere nuove funzionalità fino al 2011. Il programma di sviluppo collaborativo fornisce strumenti integrati progettati per aiutare a identificare e quantificare rapidamente i vantaggi di lavorare in parallelo. Se state sviluppando un software per la migrazione o un multicore System-on-Chip, dovreste conoscere lo strumento Prism di CriticalBlue.
Come si può realizzare questo Prism? L'approccio di base è che si visualizza una timeline che mostra come un programma di software embedded e una risorsa incorporata vengono utilizzati nel corso del tempo col multicore. Se le diverse parti di un programma si basano sulla stessa risorsa, si può vedere quando e dove le parti entrano in conflitto e trovare l'origine dell'errore del software. Se ci sono situazioni di stallo o altri problemi come quelli che abbiamo visto prima, capirete dove guardare nel codice per cercare di risolverli.
Andando sul sito ufficiale di CriticalBlue, nella sezione dedicata a Prism, potrete scaricare una versione di prova del programma da utilizzare gratuitamente per trenta giorni.
interessante articolo, non sapevo di questi problemi, pensavo che fossero risolti in fase di progettazione, insomma a livello hardware e non software.
Proprio in questi giorni sono impegnato nello studio di multi-core, multi-thread e programmazione mirata per questi topic. Un mio amico, mi citò una frase di uno dei massimi esponenti del settore, il quale affermava che attualmente in realtà non molti programmi sono adatti alle nuove tecnologie, e le tecniche di programmazione non permettono di sfruttare a pieno le enormi capacità di hardware, proprio per il problemi che l’articolo espone. È solo una citazione e di programmazione ne so ben poco, ma per quel poco che ho visto sviluppando un mips mi son reso conto che effettivamente non ha tutti i torti, e questo ovviamente su single core, figuriamoci su multi-core. Basti pensare a tutti i data hazard che bisogna gestire e alle situazioni in cui non c’è rimedio.
Mi sembra che il multicore sia come un condominio dove più condomini ci sono e più problematiche nascono, da bambino osservavo le formiche è rimanevo estasiato dall’ordine che avevano, pur essendo moltissime, forse c’è qualcosa che noi umani non siamo ancora riusciti a capire e quindi ad imparare. Se Freescale e CriticalBlue sono riusciti a migliorare le prestazioni del 40% forse hanno trovato una strada per evitare i conflitti, chissà se sarà estensibile a noi umani 😉
Cavolo!! Questa è davvero una buona notizia per chi si occupa di programmazione aprallela! fino ad oggi era relativo tutto al programmatore ed era abbastanza difficile assegnare al compilatore o alla macchina il compito di controllare il codice. Bisognava semplicemente prestare molta attenzione. Questo invece cambia un pò le carte in tavola!!
Sarebbe davvero curioso scoprire come è strutturato l’algoritmo!
l’accesso alla memoria nei sistemi multicore è la parte più dolente. ricordo che un pò di tempo fa la Intel realizzò dei chip di sviluppo che contenevano al loro interno qualche centinaio di core (immagino che fossero abbastanza primitivi per entrarci tutti) allora hanno studiato le prestazioni del sistema a seconda di quanti core stessero lavorando. ne è uscito fuori che oltre un certo numero di core le prestazioni calano perchè si creano code e conflitti per l’accesso alla memoria. A questo punto mi sembra fondamentale poter contare anche su software che ottimizzano il lavoro del sistema distribuendolo in maniera equa. Per poter realizzare sistemi più veloci non basta diminuire le dimensioni dei transistor e aumentarne la quantità. Bisogna intervenire anche (e soprattutto) sull’ottimizzazione della logica che si sta utilizzando, sia a livello hardware che software
Non ho capito però nell’articolo se questo sistema è adatto al debug delle sole soluzioni freescale, oppure anche ad altre architetture (ammetto di avere sonno, perdonatemi se me lo sono perso)
non c’è scritto se è adatto solo a freescale, la freescale lo fa ma bhò, non so se va bene anche per analizzarne altri tipi..
Ti posso portare la mia esperienza stupida quanto elementare. Io ho provato in un corso di programmazione a implementare degli algoritmi che lavoravano in parallelo su più thread. Vedi il core come un thread. Ecco,facendo girare su una cpu atom con un gb di ram una semplice funzione matematica come il calcolo dei primi 1000 numeri primi ottenevo un risultato simile a questo. Fino a 30/40 thread in parallelo il tempo di esecuzione si riduceva esponenzialmente. Superando la quota 50 era come fare eseguire l’operazione in maniera sequenziale. Arrivando fino a 100 le prestazioni venivano ridotte drasticamente. Pensandolo con i thread risulta ancora più semplice da capire =)
Il problema, secondo me, è che si devono creare due core indipendenti l’uno dall’altro, ma che siano comunque gestiti da un core esterno, che ha solo il compito di dirigere le operazioni tra i restanti core, e non quella di organo di calcolo del dispositivo che lo possiede. Mettendo oltre ai core un altro che li gestisce, i core lavorano con un certo ritmo, che gli impedisce di andare in situazioni di bug.
questa cosa della circuiteria di gestione già si fa. Il problema però è che comunque l’accesso alla memoria va fatto con un certo criterio, ma se tanti core vogliono accedere alla memoria, non c’è criterio che regga. qualcuno deve aspettare. Ti faccio un esempio pratico: la spesa. Per sveltire le operazioni di pagamento vengono introdotte tante casse, casse veloci, casse lente, ma alla fine tocca sempre fare la fila, non c’è niente da fare. Immagina che la cassa rappresenti la memoria e che la gente rappresenti i core. Per migliorare le prestazioni puoi aumentare la velocità della memoria (una dose di cocaina ai cassieri), ma non puoi aumentarla all’infinito (overdose, e limiti di velocità relativistici).
La cocaina mi sembra un esempio un pò brutto da fare, e soprattutto inaspettato, ma comunque ho capito il concetto grazie!