Credo che un sacco di Fortran sia usato in HPC, ma non sono sicuro che sia solo per ragioni legacy.
Le caratteristiche dei moderni linguaggi di programmazione come la garbage collection o il polimorfismo di run-time non sono adatte per HPC poiché la velocità conta, quindi non sono sicuro di dove C # o Java o C ++ entrino.
Qualche idea?
Ho visto molto Java usato per HPC in aree in cui (1) c'è un piccolo codice legacy e (2) tempo di sviluppo e materia di qualità del codice. I domini applicativi tipici sono finanza, data mining o bioinformatica.
Dipende davvero dall'applicazione (c'è vita al di fuori dell'algebra lineare), ma le prestazioni delle JVM recenti sono spesso alla pari con il codice C. A volte più veloce quando la JVM è in grado di eseguire in fase di runtime ottimizzazioni intelligenti che i compilatori statici (C, Fortran) non possono fare. E sicuramente più veloce quando c'è un sacco di calcolo simbolico.
Data una quantità fissa di tempo per lo sviluppo del programma, il codice Java risultante è costantemente più veloce del codice C. HPC in Java ha decisamente senso quando il codice viene sviluppato o modificato di frequente. Un'altra importante caratteristica è la mobilità del codice su hardware diverso.
Troverai riferimenti in link
Per quanto riguarda l'ipotesi di Fortran che due indirizzi siano unici, stiamo lavorando a uno strumento di analisi statico che consentirà di ottimizzare in modo simile il codice nei linguaggi di alto livello, ma senza il bit "Le cose cattive potrebbero accadere". Contattami se interessato.
Nei miei anni di esperienza, fino a 5 anni fa, è sempre stato Fortran e C. Quale dipendeva principalmente dal fatto che la gente provenisse più dall'ingegneria o più dalla scuola di pensiero CS (io non sapere come metterlo meglio, okey?: -)
In quello che stavamo facendo, Fortran era usato quasi esclusivamente.
Da quello che leggo oggi, con i nuovi aggiornamenti della Standard F2003 / 08 e con l'introduzione dei Co-array, sembra che stia di nuovo prendendo piede.
Inoltre, un articolo se non in qualche modo distorto - The Ideal HPC Programming Language
Penso che per il vero pedale del metal, l'unica vera scelta sia Fortran. Il ragionamento è che la cosa più importante per lo sfruttamento dell'ILP di basso livello (Parallismo del livello di istruzione) è la disambiguazione dell'indirizzo di memoria. Le regole defacto in Fortran consentono al compilatore di determinare che due indirizzi sono unici (e quindi l'ordine di carichi e negozi, o anche di negozi e negozi possono essere scambiati senza il rischio di generare codice errato). C lascia troppo spazio per i puntatori che si sovrappongono al compilatore per estrarre tanto il parallelismo di basso livello dal codice.
Inoltre, allineamento di array, linee di cache w.r.t e limiti SSE / AVX è importante per la generazione e l'esecuzione di loop efficienti. Se gli array vengono passati tramite blocchi comuni, il compilatore / caricatore può assicurare che tutti gli array inizino sugli stessi limiti di allineamento degli indirizzi e più efficienti È possibile utilizzare i carichi e i negozi SSE / AVX. L'hardware più recente può 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, c'è un meccanismo per comunicare questo 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 desidera. Finora Fortran fa il miglior lavoro in questi due compiti.
Solo una nota aneddotica. Non ho fatto alcun calcolo ad alte prestazioni da solo.
Per i calcoli (numero crunching), Fortran e C. Sì, è per motivi legacy:
La tendenza attuale per il numero crunch è quella di scrivere generatori di programmi che automatizzano il tweaking del codice sorgente al fine di ottimizzare le prestazioni date le caratteristiche del cluster. Questi generatori spesso escono in C.
Una seconda tendenza è scrivere in qualche 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 su cluster di macchine "commodity" senza le costose attrezzature di rete personalizzate. Questo è solitamente chiamato "High Throughput Computing". E Python è la lingua n. 1 qui (usando la famosa Riduzione mappa). Prima di Python, i progetti di elaborazione batch possono essere scritti in qualsiasi lingua e vengono generalmente inviati da Condor .
Ho lavorato su un codice MOLTO calcolo intensivo in (gasp!) C #.
Sto costruendo un'implementazione GPGPU di FDTD per la modellazione ottica. Su un piccolo cluster (128 processori), molte delle nostre simulazioni impiegano settimane per essere eseguite. Le implementazioni della GPU, tuttavia, tendono a funzionare circa 50 volte più velocemente - e questo è su una scheda NVidia di livello consumer. Ora disponiamo di un server con due schede a doppio processore GTX295 (diverse centinaia di core) e riceviamo presto Tesla.
In che modo questo riguarda la tua lingua? Nello stesso modo in cui il codice FDTD C ++ che stavamo usando prima era legato alla CPU, questi sono vincolati alla GPU, quindi la differenza ( molto piccola) del codice gestito vs nativo non viene mai giocare. L'app C # funge da conduttore - carica i kernel OpenCL, trasferendo i dati da e verso le GPU, fornendo l'interfaccia utente, i rapporti, ecc. - tutte le attività che sono un rompicapo in C ++.
Negli anni passati, la differenza di prestazioni tra codice gestito e non gestito era abbastanza significativa che a volte valeva la pena affrontare il terribile modello a oggetti di C ++ per ottenere un'ulteriore percentuale 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 delle tue differenze in termini di prestazioni non deriveranno dalla tua lingua, ma dalle abilità del tuo sviluppatore. Alcune settimane fa, ho spostato un'operazione a singola divisione dall'interno di un ciclo a triplo nidificato (3D array traversal), che riduceva del 15% il tempo di esecuzione per un dato dominio computazionale. Questo è il risultato dell'architettura del processore: la divisione è lenta, che è una di quelle facce che hai appena bisogno di aver raccolto da qualche parte.
Fortran è più comune, principalmente a causa dell'eredità (le persone eseguono ancora il vecchio codice) e della familiarità (la maggior parte delle persone che fanno uso di HPC non ha familiarità con altri tipi di lingue).
Features of modern programming languages like garbage collection or run-time polymorphism are not suitable for HPC since speed matters so not sure where C# or Java or C++ come in.
Questo non è vero in generale. L'HPC classico stava principalmente facendo algebra lineare con numeri di precisione della macchina. Tuttavia, l'HPC moderno utilizza sempre più i supercomputer per una varietà più ampia di crunch, come i calcoli simbolici con espressioni matematiche arbitrarie invece dei numeri di precisione della macchina. Ciò pone caratteristiche molto diverse sugli strumenti che si usano e non è raro utilizzare linguaggi di programmazione diversi da Fortran perché il calcolo simbolico può essere proibitivo senza GC e altri tipi di compilatori ottimizzanti come il compiler di corrispondenza di ottimizzazione dei pattern di OCaml.
Ad esempio, leggi questo documento di Fischbacher et al. che dice "gli autori hanno forti motivi per ritenere che questo possa essere il più grande calcolo simbolico eseguito finora".
Fortran, per alcune buone e alcune buone ragioni. Per il pesante calcolo matematico, una buona ragione è che ci sono ampie librerie (BLAS, LAPACK) di subroutine provate e vere, tutte scritte in Fortran (anche se possono essere chiamate da C e C ++).
Una ragione non buona è il supposto vantaggio prestazionale di Fortran rispetto a C / C ++. Gli ottimizzatori sono abbastanza buoni e pochi 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 pari a zero.
Un altro motivo non-così-buono è un divario culturale tra i programmatori CS e quelli non CS. Ai programmatori scientifici tendono ad essere insegnate cattive abitudini in Fortran, e a guardare dall'alto in basso i programmatori CS e le cattive abitudini loro sono stati insegnati, e chi guarda dall'alto in basso.
Fondamentalmente, tutti i programmi che fanno il vero lavoro di number crunching sono ancora FORTRAN (i vecchi blas, lapack, arnoldi ecc sono ancora quelli usati) ... Tuttavia, quando si tratta di strutture di livello superiore ... persone usano sempre più C ++.
La complessità della simulazione coinvolge un codice enorme e per ottenere qualsiasi tipo di beneficio dallo scrivere uno è renderlo riutilizzabile. Inoltre, anche i concetti utilizzati sono diventati molto complessi. È quasi una follia rappresentare queste informazioni usando FORTRAN. È qui che entra in gioco C ++ dal momento che supporta intrinsecamente la progettazione orientata agli oggetti. Tuttavia, il polimorfismo Run-Time è raramente preferito. Le persone usano quasi sempre il polimorfismo statico (che è implementato in C ++ con la meta-programmazione del modello)
Inoltre, ora i compilatori sono veramente buoni, quindi molta ottimizzazione è lasciata ai compilatori.
Ci sono due tipi di problemi che devono essere affrontati nelle applicazioni HPC: uno è il numero di crunch e l'altro è la gestione dei calcoli. Il primo di solito viene affrontato con codice scritto in Fortran, C o C ++ a causa della velocità e del fatto che ci sono già molti algoritmi scientifici scritti in queste lingue. Lo sterzo dei calcoli è più facilmente implementato nei linguaggi di livello superiore. Python è un linguaggio "colla" di scelta per la gestione della logica delle applicazioni e delle estensioni di chiamata implementate in linguaggi compilati. Java è spesso utilizzato da progetti in cui è essenziale gestire la rete e il calcolo distribuito.
Leggi altre domande sui tag programming-languages