Qual è il linguaggio di programmazione più utilizzato nel calcolo ad alte prestazioni? E perché? [chiuso]

Credo che un sacco di Fortran sia usato in HPC, ma non sono sicuro che sia solo per motivi legacy.

Le caratteristiche dei moderni linguaggi di programmazione come la garbage collection o il polimorfismo di runtime non sono adatte per HPC poiché la velocità è importante, quindi non sono sicuro di dove arrivi C # o Java o C ++.

qualche idea?

Ho visto molto Java usato per HPC in aree in cui (1) c'è poco codice legacy e (2) i tempi di sviluppo e la qualità del codice sono importanti. I domini applicativi tipici sono finanza, data mining o bioinformatica.

Dipende molto dall'applicazione (c'è vita al di fuori dell'algebra lineare), ma le prestazioni delle recenti JVM sono spesso alla pari con il codice C. A volte più veloce quando JVM è in grado di eseguire in runtime ottimizzazioni intelligenti che i compilatori statici (C, Fortran) non possono fare. E decisamente più veloce quando c'è molto calcolo simbolico.

Dato un periodo di tempo fisso per lo sviluppo del programma, il codice Java risultante è costantemente più veloce del codice C. HPC in Java ha sicuramente senso quando il codice viene sviluppato o modificato frequentemente. Un'altra caratteristica importante è la mobilità del codice su hardware diverso.

Puoi trovare riferimenti in http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Per quanto riguarda il presupposto di Fortran secondo cui due indirizzi sono univoci, stiamo lavorando a uno strumento di analisi statica che consentirà ottimizzazioni simili per il codice in linguaggi di alto livello, ma senza il bit "Bad Things May Happen". Contattatemi se interessati.

Nei miei anni di esperienza, fino a 5 anni fa, sono sempre stati Fortran e C. Ciò dipendeva principalmente dal fatto che le persone provenissero più dall'ingegneria o più dalla scuola di pensiero CS (non so come metterlo meglio , okey? :-)

In quello che stavamo facendo, Fortran veniva usato quasi esclusivamente.

Da quello che ho letto in questi giorni, con i nuovi aggiornamenti allo Standard F2003 / 08 e con l'introduzione di Co-Arrays, sembra che stia riprendendo slancio.

Inoltre, uno, se non in parte, l'articolo - Il linguaggio di programmazione HPC ideale

Penso che per il vero pedale al metal, l'unica vera scelta sia Fortran. Il ragionamento è che la cosa più importante per lo sfruttamento di ILP a basso livello (parallelismo a livello di istruzione) è la disambiguazione dell'indirizzo di memoria. Le regole defacto in Fortran consentono al compilatore di determinare che due indirizzi sono univoci (e quindi l'ordine di carichi e magazzini, o anche i magazzini e i magazzini possono essere scambiati senza il rischio di generare codice errato). C lascia troppo spazio per i puntatori sovrapposti affinché il compilatore possa estrarre dal parallelismo tanto parallelismo di basso livello.

Inoltre, l'allineamento dell'array, le righe della cache wrt e i limiti SSE / AVX sono importanti per la generazione e l'esecuzione di loop efficienti. Se le matrici vengono passate tramite blocchi comuni, il compilatore / caricatore può assicurare che tutte le matrici si avviino sugli stessi limiti di allineamento degli indirizzi e che possano essere utilizzati carichi e archivi SSE / AVX più efficienti. L'hardware più recente è in grado di gestire accessi di memoria non allineati, ma poiché l'accesso alla memoria non è allineato correttamente, l'utilizzo parziale delle linee della cache comporta prestazioni inferiori. Anche se un programmatore C allinea correttamente tutti i suoi array, esiste un meccanismo per comunicarlo al compilatore?

Per riassumere, i due problemi più importanti sono l'indipendenza degli indirizzi di memoria e il riconoscimento da parte del compilatore che le strutture di dati accessibili hanno lo stesso allineamento "naturale" che l'hardware vuole. Finora Fortran fa il miglior lavoro su questi due compiti.

Solo qualche nota aneddotica. Non ho fatto alcun calcolo ad alte prestazioni da solo.

Per i calcoli (crunching dei numeri), Fortran e C. Sì, è per motivi legacy:

• Ampia disponibilità di codice sorgente e ricette di dominio pubblico.
• Entrambi supportano MPI .
• Entrambe le lingue sono compilate.
• I compilatori per entrambe le lingue sono forniti da tutti i sistemi operativi e fornitori HPC.
• Sono disponibili compilatori vettorializzanti.
• Entrambi richiedono un livello folle di ottimizzazione per ottenere prestazioni elevate quando vengono portati su un cluster diverso (dimensioni della memoria, numero di CPU ecc.) Diversi
  • Questo in realtà spiega perché il codice open source è importante: è necessaria la modifica, quindi la ricetta originale deve essere scritta in una lingua che è buona per la modifica manuale.

La tendenza attuale per lo scricchiolio dei numeri è quella di scrivere generatori di programmi che automatizzino l'ottimizzazione del codice sorgente al fine di ottimizzare le prestazioni date le caratteristiche del cluster. Questi generatori spesso producono in C.

Una seconda tendenza è quella di scrivere in un dialetto specializzato di C per GPU specifiche o Cell BE.

Per lavori non numerici, come programmi che elaborano dati da un database (ma non dal database stesso), è molto più economico eseguire cluster di macchine "di base" senza le costose apparecchiature di rete personalizzate. Questo di solito si chiama "High Throughput Computing". E Python è la lingua # 1 qui (usando il famoso Riduci Mappa). Prima di Python, i progetti di elaborazione batch possono essere scritti in qualsiasi lingua e di solito vengono inviati da Condor .

Ho lavorato su alcuni codici MOLTO ad alta intensità di calcolo in (gasp!) C #.

Sto realizzando un'implementazione GPGPU di FDTD per la modellazione ottica. Su un piccolo cluster (128 processori), molte delle nostre simulazioni richiedono settimane per l'esecuzione. Le implementazioni della GPU, tuttavia, tendono a funzionare circa 50 volte più velocemente - e questo è su una scheda NVidia di livello consumer. Ora abbiamo un server con due schede a doppio processore GTX295 (diverse centinaia di core), e presto otterremo alcune Teslas.

In che modo ciò riguarda la tua lingua? Allo stesso modo in cui il codice C ++ FDTD che stavamo usando prima era associato alla CPU, questi sono associati alla GPU, quindi la differenza ( molto piccola) di potenza tra il codice gestito e il codice nativo non entra mai in gioco. L'app C # funge da conduttore: caricamento dei kernel OpenCL, passaggio di dati da e verso le GPU, fornitura dell'interfaccia utente, reportistica, ecc., Tutte attività che sono un problema nel culo in C ++.

Negli anni passati, la differenza di prestazioni tra codice gestito e non gestito era abbastanza significativa che a volte valeva la pena sopportare il terribile modello a oggetti di C ++ per ottenere il extra percento di velocità. In questi giorni, il costo di sviluppo di C ++ vs C # supera di gran lunga i vantaggi per la maggior parte delle applicazioni.

Inoltre, la maggior parte della differenza di prestazioni non verrà dalla tua lingua scelta, ma dall'abilità del tuo sviluppatore. Alcune settimane fa, ho spostato un'operazione di divisione singola dall'interno di un ciclo a triplo annidamento (attraversamento di array 3D), che ha ridotto del 15% i tempi di esecuzione per un determinato dominio computazionale. Questo è il risultato dell'architettura del processore: la divisione è lenta, che è una di quelle facce che devi solo aver raccolto da qualche parte.

Fortran è più comune, principalmente a causa dell'eredità (le persone usano ancora il vecchio codice) e della familiarità (la maggior parte delle persone che fanno HPC non hanno familiarità con altri tipi di lingue).

Le caratteristiche dei moderni linguaggi di programmazione come la garbage collection o il polimorfismo di runtime non sono adatte per HPC poiché la velocità è importante, quindi non sono sicuro di dove arrivi C # o Java o C ++.

Questo non è vero in generale. L'HPC classico stava facendo algebra lineare con numeri di precisione della macchina. Tuttavia, l'HPC moderno utilizza sempre più i supercomputer per una più ampia varietà di scricchiolii, come calcoli simbolici con espressioni matematiche arbitrarie anziché numeri di precisione della macchina. Questo pone caratteristiche abbastanza diverse sugli strumenti che usi e non è raro usare linguaggi di programmazione diversi da Fortran perché il calcolo simbolico può essere proibitivo in modo proibitivo senza GC e altri tipi di compilatore di ottimizzazione come il compilatore di pattern matching ottimizzato di OCaml.

Ad esempio, leggi questo articolo di Fischbacher et al. che dice "gli autori hanno forti ragioni per credere che questo potrebbe essere il più grande calcolo simbolico eseguito finora".

Fortran, per alcuni buoni e alcuni non così buoni motivi. Per i pesanti calcoli matematici, una buona ragione è che ci sono ampie librerie (BLAS, LAPACK) di subroutine collaudate, tutte scritte in Fortran (anche se quelle possono essere chiamate da C e C ++).

Un motivo non proprio buono è il presunto vantaggio prestazionale di Fortran su C / C ++. Gli ottimizzatori sono piuttosto buoni e poche persone capiscono che il vantaggio di ottimizzare un pezzo di codice è proporzionale alla percentuale di tempo in cui è occupato, che in quasi tutto il codice è quasi zero.

Un'altra ragione non molto buona è il divario culturale tra programmatori CS e non CS. I programmatori scientifici tendono a ricevere cattive abitudini a Fortran e a guardare in basso i programmatori CS e le cattive abitudini che sono state loro insegnate e che guardano dall'alto in basso.

Fondamentalmente, tutti i programmi che svolgono il vero lavoro di scricchiolio dei numeri sono ancora FORTRAN (i vecchi blas, lapack, arnoldi ecc. Sono ancora quelli utilizzati) ... Tuttavia, quando si tratta di strutture di livello superiore ... le persone usano sempre più C ++.

La complessità della simulazione implica un enorme codice e ottenere qualsiasi tipo di beneficio dalla scrittura è renderlo riutilizzabile. Inoltre, anche i concetti utilizzati sono diventati molto complessi. È quasi una follia rappresentare quell'informazione usando FORTRAN. È qui che entra in gioco C ++ poiché supporta intrinsecamente la progettazione orientata agli oggetti. Tuttavia, il polimorfismo run-time è raramente preferito. Le persone invece usano quasi sempre il polimorfismo statico (che è implementato in C ++ con meta-programmazione di template)

Inoltre, ora i compilatori sono davvero buoni, quindi molta ottimizzazione è lasciata ai compilatori.

Esistono due tipi di problemi che devono essere affrontati nelle applicazioni HPC: uno è il numero che si scricchiola e l'altro è la gestione dei calcoli. Il primo è di solito affrontato con il codice scritto in Fortran, C o C ++ a causa della velocità e del fatto che ci sono già molti algoritmi scientifici scritti in questi linguaggi. La gestione dei calcoli è implementata in modo più conveniente nelle lingue di livello superiore. Python è un linguaggio "colla" di scelta per gestire la logica dell'applicazione e le estensioni di chiamata implementate in linguaggi compilati. Java viene spesso utilizzato da progetti in cui è essenziale la gestione di reti e l'elaborazione distribuita.