High performance computing: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Rimossa categoria nascosta inserita senza motivazione ed in modo errato |
Nessun oggetto della modifica |
||
Riga 17:
Infine tra le altre alternative esistono delle piattaforme HPC che eseguono il codice su una [[CPU]] accedendo direttamente ai dati memorizzati su un altro sistema [[multiprocessore simmetrico|SMP]], utilizzando ad esempio un indirizzamento globale ed un sistema per il supporto della rete di collegamento tra i vari [[multiprocessore simmetrico|SMP]]. Tali sistemi sono i cosiddetti [[ccNUMA]] (cache coherent NonUniform Memory Access). Questi ultimi possono essere visti come delle grandi [[multiprocessore simmetrico|SMP]] virtuali, anche se il codice viene eseguito più lentamente se i dati su cui si opera sono memorizzati su un altro [[multiprocessore simmetrico|SMP]] (da qui il costo d’accesso non uniforme).
Oggi i [[supercomputer]] vettoriali continuano a fornire i più alti livelli di prestazioni per alcune applicazioni, ma restano comunque costosi. Le [[multiprocessore simmetrico|SMP]] sono largamente commercializzate, con un numero di processori che va da due a oltre cento, come
I COW sono diventati comuni e i cluster, composti da migliaia di processori, vengono utilizzati sia nei laboratori così come nell’industria (ad esempio per l’elaborazione sismica). Il costo delle reti è nel frattempo diminuito mentre le prestazioni fornite sono aumentate rapidamente, così che il problema associato alla lentezza delle reti COW si è di molto ridotto
<ref name=nota1>
{{en}}{{cita libro
Riga 32:
|capitolo=The Challenge of Providing a High-level Programming Model for High performance computing
}}</ref>.
Per quanto riguarda il futuro, la [[Semiconductor Industry Association]] ha delineato la possibile evoluzione della tecnologia di semiconduttore fino al 2014.▼
Il futuro del supercalcolo sarà condizionato sia dall’evoluzione della tecnologia circuitale sia da quella del disegno di sistema che, a sua volta, non potrà non essere influenzato dalla tecnologia disponibile▼
<ref name=nota2>{{cita web▼
|url=http://www.mondodigitale.net/Rivista/03_numero_uno/high_performance_computing.pdf ▼
|titolo=Evoluzione e prospettive dell'High Perfomance Computing▼
|anno=2003▼
}}</ref>.▼
== Implementazione sui sistemi di calcolo ==▼
Poiché i sistemi di calcolo, ogni giorno, sono sempre più sofisticati e veloci, gli sviluppatori di applicazioni per HPC devono spesso lavorare insieme ad ingegneri e progettisti per identificare e correggere i vari [[bug]] e le instabilità che insorgono. Essi devono adeguarsi continuamente a scrivere codice per nuovi tipi di architetture e spesso sono i primi che utilizzano i nuovi [[linguaggio di programmazione|linguaggi di programmazione]], le librerie, i [[compilatore|compilatori]], insieme ai più recenti strumenti per lo sviluppo di applicazioni. Tuttavia, la continua riprogrammazione si rivela inefficiente perché impiega troppa manodopera e gli esperti in applicazioni HPC non sono molti, dunque sono essenziali dei modelli standard di programmazione ad alto livello per ridurre lo sforzo umano nella riprogrammazione delle nuove piattaforme. Purtroppo fornire standard ad alto livello per le applicazioni HPC non è un’impresa facile poiché nascono ogni giorno nuove architetture per il calcolo ad alte prestazioni, ognuna con specifiche caratteristiche diverse dalle altre e che devono essere sfruttate in maniera adeguata per raggiungere l’alto livello di prestazione richiesto. I programmatori HPC sono riluttanti a sacrificare le prestazioni in cambio di una maggiore facilità di programmazione, dunque è necessario un modello standard che permetta di sfruttare al massimo tutti i tipi di piattaforma. Vi sono poi ulteriori vincoli: il modello di programmazione deve essere di facile comprensione per semplificare l’identificazione dei [[bug]] e la loro correzione. Deve essere scalabile, per far fronte all’aumento di complessità del problema e quello di potenza della macchina. Infine, poiché quello dell’HPC è una mercato relativamente piccolo, i produttori non sarebbero in grado di far fronte ad un’ elevata quantità di modelli di programmazione diversi e di conseguenza, lo standard, deve essere compatibile con la maggior parte dei codici e piattaforme per HPC▼
<ref name=nota1/>.▼
▲Un esempio di moderno sistema che sfrutta l’HPC è il [[Sun Modular Datacenter]] della Sun. La tecnologia [[InfiniBand]] è la più utilizzata per interconnettere i sistemi HPC anche se la tecnologia [[10 gigabit Ethernet]] con l'aggiunta delle tecnologie [[lossless ethernet]] tendenzialmente potrà essere la soluzione di riferimento<ref>
{{en}}{{cita libro
|cognome=Gai
Riga 59 ⟶ 46:
|capitolo=I/O Consolidation in the Data Center
}}</ref>.
▲Per quanto riguarda il futuro, la [[Semiconductor Industry Association]] ha delineato la possibile evoluzione della tecnologia di semiconduttore fino al 2014.
▲Il futuro del supercalcolo sarà condizionato sia dall’evoluzione della tecnologia circuitale sia da quella del disegno di sistema che, a sua volta, non potrà non essere influenzato dalla tecnologia disponibile
▲<ref name=nota2>{{cita web
▲|url=http://www.mondodigitale.net/Rivista/03_numero_uno/high_performance_computing.pdf
▲|titolo=Evoluzione e prospettive dell'High Perfomance Computing
▲|anno=2003
▲}}</ref>.
▲== Implementazione sui sistemi di calcolo ==
▲Poiché i sistemi di calcolo, ogni giorno, sono sempre più sofisticati e veloci, gli sviluppatori di applicazioni per HPC devono spesso lavorare insieme ad ingegneri e progettisti per identificare e correggere i vari [[bug]] e le instabilità che insorgono. Essi devono adeguarsi continuamente a scrivere codice per nuovi tipi di architetture e spesso sono i primi che utilizzano i nuovi [[linguaggio di programmazione|linguaggi di programmazione]], le librerie, i [[compilatore|compilatori]], insieme ai più recenti strumenti per lo sviluppo di applicazioni. Tuttavia, la continua riprogrammazione si rivela inefficiente perché impiega troppa manodopera e gli esperti in applicazioni HPC non sono molti, dunque sono essenziali dei modelli standard di programmazione ad alto livello per ridurre lo sforzo umano nella riprogrammazione delle nuove piattaforme. Purtroppo fornire standard ad alto livello per le applicazioni HPC non è un’impresa facile poiché nascono ogni giorno nuove architetture per il calcolo ad alte prestazioni, ognuna con specifiche caratteristiche diverse dalle altre e che devono essere sfruttate in maniera adeguata per raggiungere l’alto livello di prestazione richiesto. I programmatori HPC sono riluttanti a sacrificare le prestazioni in cambio di una maggiore facilità di programmazione, dunque è necessario un modello standard che permetta di sfruttare al massimo tutti i tipi di piattaforma. Vi sono poi ulteriori vincoli: il modello di programmazione deve essere di facile comprensione per semplificare l’identificazione dei [[bug]] e la loro correzione. Deve essere scalabile, per far fronte all’aumento di complessità del problema e quello di potenza della macchina. Infine, poiché quello dell’HPC è una mercato relativamente piccolo, i produttori non sarebbero in grado di far fronte ad un’ elevata quantità di modelli di programmazione diversi e di conseguenza, lo standard, deve essere compatibile con la maggior parte dei codici e piattaforme per HPC
▲<ref name=nota1/>.
== Problemi ==
Riga 70:
<ref name=nota2/>.
Tra questi linguaggi abbiamo ad esempio l’[[Occam]].
La progettazione di un algoritmo efficiente è, spesso, più efficace di un hardware sofisticato.
Purtroppo, non è facile trovare la soluzione giusta. Con la disponibilità del calcolo parallelo, il ricercatore che debba sviluppare una nuova applicazione potrebbe essere invogliato a cercare fin dall’inizio algoritmi intrinsecamente parallelizzabili. Più difficile è, evidentemente, il compito di chi debba riadattare software applicativo già esistente alle nuove possibilità tecnologiche.
Bisogna inoltre considerare i limiti dell’elaborazione parallela. A titolo d’esempio,si immagini di avere 52 carte di uno stesso mazzo distribuite in modo casuale e di volerle mettere in ordine. Se ci fossero quattro giocatori a volersi dividere le attività secondo i colori (cuori, quadri, fiori, picche) si farebbe certamente prima che se si dovesse svolgere la stessa attività da soli. Ma fossero 52 i giocatori, tutti intorno allo stesso tavolo, a voler ordinare il mazzo si farebbe probabilmente solo una gran confusione. Questo banale esempio può far comprendere come esista un limite al di là del quale non conviene spingere sul parallelismo degli agenti ma, piuttosto, sulla velocità del singolo
| |||