Sto anche lanciando i miei due centesimi in ritardo, ma ho appena visto questo thread e sento che, per i posteri, ci sono alcuni punti che devono essere disperatamente fatti.
Nota di seguito che parlerò di C e non di C ++. Perché? Bene, altrimenti sono le mele e le arance a confrontare un linguaggio orientato agli oggetti a tutti gli effetti tipicamente dinamizzato con qualcosa di statico come Fortran. Sì, alcune implementazioni moderne degli ultimi standard Fortran possono fare molto di più, ma pochissime persone li usano davvero, e quindi quando parliamo di Fortran, pensiamo a un linguaggio semplice, statico e imperativo. Ecco dove si trova anche C, quindi sostituirò C con C ++ per quanto segue.
Prima di tutto, qualsiasi discussione su Fortran / C con compilatori migliori è discutibile. I compilatori C / Fortran dedicati appartengono al passato. Sia gcc / gfortran che icc / ifc sono solo front-end diversi per lo stesso back-end, ovvero il tuo programma verrà trasformato in una descrizione astratta dal front-end e quindi ottimizzato e assemblato dal back-end. Se si scrive, semanticamente, lo stesso codice in Fortran o in C, il compilatore produrrà, in entrambi i casi, lo stesso assembly che verrà eseguito altrettanto velocemente.
Questo ora porta al mio secondo punto: perché vediamo ancora differenze? Il problema è che la maggior parte dei confronti viene fatta dai programmatori Fortran che provano qualcosa in C o viceversa. Hai mai notato come la maggior parte degli autori o dei poeti preferisca scrivere nelle loro lingue native? Vorresti scrivere poesie in una lingua in cui non ti senti completamente sicuro o a casa? Certo che no ... io stesso considero C come il mio linguaggio di programmazione "nativo". Ho anche passato tre anni a lavorare in un gruppo che utilizzava solo Fortran, in cui ho raggiunto un certo livello di fluidità. Tuttavia, non scriverei mai nulla da solo in Fortran poiché mi sento più a mio agio con C e, di conseguenza, il codice risultante sarà migliore , qualunque cosa tu lo definisca.
Quindi la differenza principale sta nel programmatore, non nella lingua. Quindi non ci sono differenze? Bene, non proprio. Ecco alcuni esempi:
SIMD: Che si tratti di SSE, SSE3 o AltiVec, se si desidera utilizzarli in Fortran, è meglio sperare e pregare che il compilatore indovini esattamente ciò che si desidera e lo fa. In bocca al lupo. In C hai generalmente funzioni intrinseche per ogni architettura o, più recentemente, tipi di vettore SIMD generali in gcc . La maggior parte dei compilatori Fortran utilizzerà solo le istruzioni SIMD per srotolare i loop, ma se si dispone di un kernel che funziona su brevi vettori di dati in modo non ovvio, molto probabilmente il compilatore non lo vedrà.
Diverse architetture hardware: l'intera architettura CUDA è costruita attorno ai kernel in C. Sì, il gruppo Portland ora ha anche un compilatore fortran compatibile con CUDA , ma è commerciale e, soprattutto, non proviene da NVIDIA. Lo stesso vale per OpenCL, per cui il migliore che ho trovato è un progetto recente che supporta solo alcune chiamate di base.
Programmazione parallela: Sì, sia MPI che OpenMP funzionano perfettamente con C e Fortran. Tuttavia, se vuoi un controllo reale dei tuoi thread, cioè se hai un calcolo della memoria condivisa completamente dinamico, con Fortran sarai fuori nel freddo. In C hai i pthread standard che, sebbene non caldi e sfocati, ti faranno ancora passare la tempesta. In generale, la maggior parte dei calcoli che si basano sull'accesso al sistema operativo, ad esempio thread, processi, file system, ecc ... sono meglio serviti con C. Oh, e non provano a fare la propria rete con Fortran.
Facilità d'uso: Fortran è più vicino a Matlab di quanto lo sia C. Dopo aver superato tutte le diverse parole chiave e come dichiarare le variabili, il resto del codice assomiglia a Matlab, rendendolo più accessibile agli utenti con esperienza di programmazione limitata.
Interoperabilità: quando si crea una struttura in C, il layout dei dati effettivi è semplice e deterministico. In Fortran, se si utilizzano array di puntatori o dati strutturati, il layout effettivo dei dati è fortemente dipendente dal compilatore, non diretto e di solito completamente non documentato. Puoi chiamare C da Fortran e viceversa, ma non iniziare a pensare che potrebbe essere altrettanto semplice passare qualcosa di più di un array statico dall'uno all'altro e viceversa.
Questo è tutto un po 'geek, di basso livello, ma stiamo parlando di High Performance Performance Computing, giusto? Se non sei interessato a come sfruttare al meglio i paradigmi hardware sottostanti, ovvero implementare e / o sviluppare algoritmi che sono i migliori per memoria condivisa / distribuita, thread, vettorializzazione SIMD, GPU che usano SIMT e così via, allora sei sto facendo matematica su un computer.
Questo è diventato molto più lungo di qualsiasi cosa io abbia inteso, quindi ecco un riassunto - una serie di messaggi da portare a casa in qualche modo:
- Potrai scrivere il codice migliore che si può nella lingua che si conosce meglio.
- Non c'è differenza nella qualità del codice prodotto da due compilatori che utilizzano lo stesso back-end: siamo noi che scriviamo codice errato in una lingua o in un'altra.
- Nonostante si senta più a basso livello, Fortran è un'astrazione piuttosto di alto livello e non ti consente di accedere direttamente a determinate funzionalità hardware / OS, ad esempio SIMD, thread, reti, ecc ...