C ++ vs Fortran per HPC


56

Nel mio programma di dottorato in scienze computazionali, stiamo lavorando quasi esclusivamente in C ++ e Fortran. Sembra che alcuni professori preferiscano l'uno all'altro. Mi chiedo quale sia "migliore" o se uno sia migliore dell'altro in una determinata circostanza.


12
A mio avviso, un mix di un linguaggio di alto e basso livello è meglio che utilizzare esclusivamente uno dei due. Ad esempio, uso Python + C ++.
Faheem Mitha,

2
Le risposte a questa domanda saranno quasi puramente soggettive e quindi non sono sicuro che questa domanda sia appropriata.
Jeff,

Risposte:


62

Come spesso accade, la scelta dipende da (1) il problema che stai cercando di risolvere, (2) le abilità che hai e (3) le persone con cui lavori (a meno che non sia un progetto solista). Lascerò (3) da parte per il momento perché dipende dalla situazione individuale di tutti.

Dipendenza da problemi: Fortran eccelle nell'elaborazione dell'array. Se il tuo problema può essere descritto in termini di semplici strutture dati e in particolari array, Fortran è ben adattato. I programmatori Fortran finiscono per usare le matrici anche in casi non ovvi (ad esempio per rappresentare i grafici). Il C ++ è più adatto per strutture dati complesse e altamente dinamiche.

Dipendenza da abilità: ci vuole molta più esperienza di programmazione per scrivere buoni programmi C ++ che per scrivere buoni programmi Fortran. Se inizi con poca esperienza di programmazione e hai solo così tanto tempo per imparare quell'aspetto del tuo lavoro, probabilmente otterrai un ritorno sull'investimento migliore imparando Fortran che imparando C ++. Supponendo, ovviamente, che il tuo problema sia adatto a Fortran.

Tuttavia, c'è di più nella programmazione oltre a Fortran e C ++. Consiglierei a chiunque vada nella scienza computazionale di iniziare con un linguaggio dinamico di alto livello come Python. Ricorda sempre che il tuo tempo è più prezioso del tempo della CPU!


17
"Ricorda sempre che il tuo tempo è più prezioso del tempo della CPU!" Come qualcuno che lavora in HPC non sono d'accordo con quella parte; tutto il resto è perfetto.
Levi Morrison,

19
"Ricorda sempre che il tuo tempo è più valido di quello della CPU!" Come qualcuno che lavora nella ricerca scientifica, non potrei essere più d'accordo con quella parte.
decade il

3
"Ricorda sempre che il tuo tempo è più prezioso del tempo della CPU!" - Vorrei inserire i miei 2 centesimi - utilizzando diverse centinaia di nodi, ognuno con oltre 10 core per eseguire un programma per diverse settimane, può essere interpretato come uno spreco orribile di una risorsa preziosa, se un paio di settimane in più potrebbero produrre un codice che viene eseguito solo un paio di giorni. Quei cluster HPC sono una risorsa comune rara e costosa.
Dani_l,

"Ricorda sempre che il tuo tempo è più valido di quello della CPU!", Codice per una settimana ma corsa per un mese, è abbastanza normale signore!
fronthem

6
"Ricorda sempre che il tuo tempo è più prezioso del tempo della CPU!", Preferirei programmare per un mese e correre tra una settimana! - si può fare di più una volta che il codice è stato scritto e altri troveranno il codice che scrivi anche più utile.
Charles,

37

Penso che sia C ++ che Fortran siano abbastanza buoni e funzionino bene.

Tuttavia, penso che Fortran sia migliore per il calcolo scientifico numerico , per gli algoritmi che possono essere espressi usando array e non necessitano di altre strutture di dati sofisticate, quindi in campi come differenze / elementi finiti, solutori PDE, calcoli di strutture elettroniche. Fortran è una lingua specifica del dominio. In particolare, penso che sia più facile scrivere programmi veloci in Fortran che in C ++, da uno scienziato (non necessariamente un esperto di informatica).

Il C ++ è un linguaggio generico, quindi si può esprimere qualsiasi algoritmo in esso, ed è sicuramente meglio per gli algoritmi che non possono essere espressi usando array, dal campo HPC probabilmente alcuni grafici, generatori di mesh, manipolazione simbolica e così via.

È anche possibile scrivere algoritmi di array in C ++, ma nella mia esperienza, richiede molta più conoscenza informatica e in generale più lavoro (cioè è necessario creare o riutilizzare le classi per la manipolazione di array e gestire la gestione della memoria a mano o usando alcuni biblioteca come Teuchos di Trilinos). I non esperti tendono a scrivere programmi Fortran piuttosto buoni, ma orribili programmi C ++ (parlando per esperienza personale).

Disclaimer: personalmente mi piace molto Fortran e lo preferisco al C ++ per il calcolo numerico. Ho trascorso oltre 2 anni di programmazione in C ++ ogni giorno e quasi un anno di programmazione nel moderno quotidiano Fortran (nell'area degli elementi finiti). Uso anche Python e Cython.


1
Uno in alto per la prima risposta essendo equilibrato. Penso che C ++ e Fortran non siano di gran lunga le uniche possibilità nell'HPC contemporaneo. Penso che sia bene conoscere la forza e i punti deboli quando decidi per Fortran, C ++ o Python (o qualunque cosa ti piaccia). Ho visto 20.000 linee di Fortran in un unico file, coltivate biologicamente in alcuni decenni. Personalmente non userei per nient'altro che il calcolo ad array pesante isolato. Nemmeno per qualcosa legato all'output. Finora per un commento distorto.
shuhalo,

6
Non potrei essere più in disaccordo con questa risposta. Il nostro codice ad elementi finiti non sarebbe stato possibile scrivere in Fortran. In effetti, è iniziato 15 anni fa come un mix di C e Fortran semplici (quest'ultimo per le parti del metodo numericamente intense) e si è gradualmente spostato in C puro e poi in C ++ nel corso di diversi anni. Il codice è diventato costantemente più breve, più veloce e più facile da capire ed era più capace dopo ogni iterazione. Sono d'accordo con gli altri che sottolineano che C ++ ti dà molta corda per spararti. Scegli la lingua con cui ti senti più a tuo agio.
Bill Barth,

6
Bill, hai usato il moderno Fortran (90 e successive aggiunte?). Questo è molto importante (avrei dovuto essere più esplicito nella mia risposta al riguardo). Naturalmente, "20.000 righe di Fortran", o f77, di solito non è migliore del C ++ ben scritto.
Ondřej Čertík,

1
@ OndřejČertík: Penso che se credi che i moderni programmi ad elementi finiti utilizzino strutture di dati "semplici", non ne hai guardato nessuno di recente. Prova a implementare elementi finiti adattivi, metodi hp o multigrid su mesh non strutturate utilizzando semplici strutture dati. Bill è perfetto e credo di poter parlare al posto suo dicendo che l'uso del "moderno Fortran" non avrebbe fatto altro che una piccola differenza.
Wolfgang Bangerth,

6
@WolfgangBangerth, vedi ad esempio Phaml ( math.nist.gov/phaml ) per un'implementazione Fortran di praticamente tutto ciò che hai menzionato.
Ondřej Čertík,

31

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 ...

5
Esito positivo. Non credo tuttavia che il tuo commento finale sia necessariamente vero. Anch'io sono un programmatore C, ma puoi accedere a cose di basso livello in Fortran attraverso buone pratiche di programmazione. Il modo ideale per utilizzare cose come SIMD ops è scrivere codice che lo suggerisce fortemente (bloccando i loop, per esempio) e lasciare che il compilatore lo faccia per te. Per il threading, usa semplicemente openMP (pthreads è utilizzabile anche con qualche lavoro extra). Fortran ha tutte le cose che dici che non ha, solo a un livello che conta per il suo tipico utente: numerico.
Reid.Atcheson

@ Reid.Atcheson: Bene, se blocchi tutto ciò che il compilatore lo catturerà, allora funzionerà automagicamente sia in C che in Fortran. Il problema è, tuttavia, fino a che punto vuoi fidarti del tuo compilatore? E perché vuoi fidarti nei casi in cui sai esattamente cosa vuoi fare? OpenMP esegue il threading, sì, ma per quanto riguarda i blocchi. Puoi indurlo a fare in modo che pool di thread diversi facciano cose diverse, ma si tratta solo di utilizzare male OpenMP. I pthread per Fortran sono solo wrapper per le funzioni C. Sono d'accordo, tuttavia, che Fortran è più facile se non sei nei dettagli.
Pedro

1
Sicuramente non otterrai il massimo del 99% di efficienza di picco affidandoti al compilatore, ma puoi facilmente avvicinarti abbastanza. Oltre a ciò, è necessario utilizzare intrinseche o in linea ASM. Devi fare delle concessioni da qualche parte per l'efficienza complessiva del programmatore, ecco perché i linguaggi di programmazione esistono in primo luogo. Nella fase in cui sei abbastanza pazzo da entrare nei dettagli di intrinseci o ASM (sono stato un paio di volte), Fortran non è una stampella. Sapresti comunque come collegare il tuo codice assemblato ottimizzato a mano.
Reid.Atcheson

@ Reid.Atcheson: Beh, direi che per le applicazioni HPC parallele, potresti finire con un livello di efficienza molto inferiore al 99% ... E i tipi di vettore gcc rendono l'uso degli intrinseci un problema :)
Pedro

1
@Pedro, post brillante. Assolutamente brillante. Grazie mille per la pubblicazione. L'ho appena trovato mentre rovistava casualmente attraverso thread interessanti.
Inquiry

16

Dai miei 15 anni di riflessione sul software scientifico: se il tuo codice viene eseguito il 25% più veloce perché lo scrivi in ​​Fortran, ma ti impiega 4 volte a scriverlo (niente STL, difficoltà nell'implementare strutture di dati complesse, ecc.), Quindi Fortran vince solo se passi una frazione significativa della tua giornata a giocherellare con i pollici e ad aspettare che i tuoi calcoli finiscano. Dato che per quasi tutti noi la cosa più preziosa è il nostro tempo, la conclusione è questa: usare il linguaggio che ti consente di sviluppare, eseguire il debug e testare il tuo codice il più velocemente, ragionevolmente ignorando che potrebbe essere più lento del possibile se l'hai scritto in Fortran.


13

Il mio approccio è stato quello di utilizzare il C ++ per tutto tranne che per i kernel computazionali, che di solito sono meglio scritti in assembly; questo ti offre tutte le prestazioni del tradizionale approccio HPC ma ti consente di semplificare l'interfaccia, ad esempio sovraccaricando i kernel computazionali come SGEMM / DGEMM / CGEMM / ZGEMM in un'unica routine, ad esempio Gemm. Chiaramente il livello di astrazione può essere alzato molto più in alto evitando puntatori grezzi e passando a classi opache, ma è un bel primo passo.

Trovo che il più grande svantaggio del C ++ sia in modo schiacciante l'aumento dei tempi di compilazione, ma, nella mia esperienza, i risparmi nei tempi di sviluppo sono più che compensati. Un altro aspetto negativo è che i compilatori C ++ del fornitore tendono ad avere più bug rispetto ai compilatori C e Fortran del fornitore. L'anno scorso, penso di aver incontrato quasi dieci bug nei compilatori C ++.

Detto questo, penso che l'annullamento di pacchetti scientifici scritti in linguaggi di basso livello (e Fortran) sia la riluttanza a esporre interfacce convenienti per strutture di dati sofisticate: la maggior parte delle persone è soddisfatta dell'interfaccia BLAS di Fortran, poiché richiede solo puntatori e dimensioni iniziali per descrivere le matrici, ma poche persone sostengono che la solita interfaccia del solutore sparse-diretto Fortran a 40 numeri è qualcosa di molto vicino (cfr. UHM, SuperLU, PETSc e Trilinos).

In sintesi, sostengo per l'utilizzo dell'assembly per kernel computazionali di basso livello, ma linguaggi di livello superiore per tutto il resto, specialmente quando si opera su strutture di dati non banali.

Si noti che questo post ha portato a questo confronto delle prestazioni di C e Fortran sul kernely:=αx+y .


2
Perché non dovresti fidarti di un compilatore C standard con l'ottimizzazione appropriata abilitata allo scopo di compilare kernel piccoli? A quel livello di dimensioni e complessità del codice, la differenza in ciò che un compilatore potrebbe estrarre da esso non è chiara.
Peter Brune,

1
Ho parlato con diverse persone che mi hanno detto che, anche con un uso limitato, il loro Fortran era ancora più veloce del loro codice C e / o C ++ per alcune operazioni come una trasposizione matrice esplicita. Non sto dicendo che è impossibile rendere il codice C o C ++ più veloce, ma che il compilatore Fortran tende a fare un lavoro migliore.
Jack Poulson il

Ho la stessa esperienza con la parola chiave "limits" (il mio semplice codice Fortran era sempre un po 'più veloce). Ma la mia esperienza è limitata e semplicemente non ho tempo da dedicare alla comprensione dell'assemblaggio generato da gcc. Quindi uso semplicemente Fortran, è semplice ed è veloce.
Ondřej Čertík,

@JackPoulson: l'argomento del compilatore è qualcosa che sento abbastanza dalla comunità Fortran. Sfortunatamente, la maggior parte dei compilatori, ad esempio gcc o ifc / icc, usano front-end di lingua diversa per lo stesso back-end. Il macchinario che esegue l'ottimizzazione e la generazione del codice è identico e quindi le differenze nei risultati sono probabilmente dovute a differenze nella familiarità del programmatore con il linguaggio sottostante ...
Pedro

1
Giusto per dare un po 'di prospettiva sull'affermazione spesso ripetuta, raramente convalidata, secondo cui Fortran è più veloce sui kernel numerici: qualche tempo fa abbiamo notato che il vettore di matrice sparsa nel pacchetto Epetra di Trilinos era del 30% più lento di quello in deal.II. Il primo è stato scritto in Fortran 77, il secondo in C senza l'uso di "restringi". Entrambi avevano circa 10-15 righe di codice. Oggi, Trilinos utilizza il pezzo di codice sollevato da deal.II. Sono sicuro che si possono trovare molti casi in cui F77 è più veloce di C. Il punto è che non è più universalmente così oggi.
Wolfgang Bangerth,

8

Da quando sono nuovo qui, stavo guardando attraverso vecchie domande e ho trovato questo. Spero che non sia un tabù rispondere ai vecchi!

Dal momento che nessun altro ha menzionato questo, ho pensato che avrei fatto. Fortran 2003 è quasi completamente supportato dalla maggior parte dei principali compilatori (intel, ibm, cray, NAG, PCG) anche gcc con la (futura) nuova versione 4.7. Fortran 2003 (e 2008) è un linguaggio orientato agli oggetti, sebbene un po 'più dettagliato di C ++. Una delle cose che ritengo interessante per Fortran è il fatto che il comitato standard vede il calcolo scientifico come il pubblico principale (ringrazio Damian Rouson per avermelo segnalato l'altro giorno).

Ho sollevato tutto questo non in modo che i programmatori C ++ diventino programmatori Fortran, ma così che le persone Fortran sappiano che ora hanno più opzioni oltre a passare al C ++ o emulare concetti orientati agli oggetti in Fortran 90/95.

Un avvertimento che aggiungerò è che c'è un costo per essere al limite di ciò che è implementato nei compilatori. Se intraprendi un grande progetto in Fortran 2003 in questo momento ti imbatterai in bug e dovrai continuamente aggiornare il tuo compilatore (specialmente se usi gcc), anche se questo è migliorato significativamente negli ultimi mesi!


7

Il problema con C ++ è che hai molte possibilità di rovinare le prestazioni, ad esempio usando ciecamente STL, eccezioni, classi (sovraccarico virtuale più problemi di allineamento), sovraccarico dell'operatore (nuovo / eliminazioni ridondanti) o modelli (compilazione infinita ed errori criptici sembra benigno, ma puoi perdere ore in questo modo).

Tuttavia, più si ottiene un migliore accesso alle librerie generali e probabilmente si ottiene una maggiore visibilità del proprio codice (sebbene ciò dipenda fortemente dal campo e si abbia ancora C pura). E puoi ancora compensare la mancanza di flessibilità del Fortran avvolgendo il suo codice in un linguaggio di script come R, Lush, Matlab / Scilab o persino Python, Ruby o Lua.


1
È generalmente una cattiva idea applicare tecniche di basso livello in linguaggi di alto livello. Ad esempio, l'STL è progettato per funzionare a un livello molto astratto. Bisogna essere consapevoli del motivo per cui l'interfaccia è progettata, usarla per questo compito e quindi uscire dal compilatore.
shuhalo,

2
Penso che sia i punti di MBQ che quelli di Martin siano ingiusti. Sì, ci sono modi per spararti nel piede se provi a implementare un vettore numerico per scopi di algebra lineare usando std :: list <double>. Ma questo è un argomento sciocco: almeno C ++ ha una classe di elenco collegata che puoi usare, mentre Fortran no. È come dire "Le auto guidano a una velocità così elevata che potresti schiantarti contro un muro e ferirti; dovresti invece usare le carrozze trainate da cavalli". È solo un'idea stupida cestinare un linguaggio di alto livello che supporta anche cose di basso livello (ad es. C ++) per avere funzionalità di alto livello.
Wolfgang Bangerth,

@WolfgangBangerth No, ora stai facendo del male a Fortran - è tanto "di basso livello" quanto i batteri sono "meno evoluti" degli umani. Se vuoi un'analogia con un'auto, dovrebbe essere più simile a "puoi usare sia Jeep che Lexus per attraversare una palude, ma usare la prima fa meno male".
mbq,

1
Apprezzo la tua opinione, ma sostengo che Fortran non è così evoluto come C ++ :-)
Wolfgang Bangerth

7

Tre fatti:

  • Matrici n-dimensionali in stile F77 in C: nessun problema con CnD (una spina spudorata, è vero )

  • Il sistema di moduli F90 è mal progettato e ostile per costruire ambienti. (Il nome di un modulo non deve corrispondere al suo nome file, ad es.)

  • Fortran non supporta bene il refactoring. Per estrarre un po 'di funzionalità da una funzione è necessario toccare quattro posizioni: codice effettivo, dichiarazioni variabili, dichiarazioni argomento e elenco argomenti. C ci riesce con due punti da toccare. Ciò aggrava l'effetto dell'incapacità di gestire bene i dati (descritti di seguito): poiché la modularità su piccola scala è così dolorosa, quasi tutti scrivono gigantesche subroutine.

Un'impressione personale:

  • Fortran non funziona bene per la gestione dei dati. Prova a restituire un puntatore a una struttura dati opaca dell'utente in F77 o F90. ( transfer(), arriviamo)

Ciao Andreas! CnD è interessante, non lo sapevo. Ah, l'hai scritto tu. :) (f90 supporta anche lo slicing, allocabile per array e, soprattutto, la sintassi array per moltiplicazione, aggiunta e così via.) Uso CMake con Fortran e funziona perfettamente con i moduli. Che cos'è esattamente "elenco argomenti"? Non credo di usarli, quindi per modificarli sono necessari solo 3 posti. In C, in genere è necessario modificare il codice effettivo, i parametri e un file di intestazione, quindi sono anche 3 posti (sicuramente in C ++). Sì, transfer () non è molto bello, ma in genere non è necessario in pratica.
Ondřej Čertík,

3
Il refactoring del fortran moderno è banale con IDE adeguati, come Photran in eclissi.

2
"Il nome di un modulo non deve corrispondere al nome del file, ad es." Devi scherzare, puoi avere molti moduli in un unico file. Alcuni di essi coprono solo un paio di righe. Sono molto più facili da creare se non devi creare un file per ognuno di essi.
Vladimir F,

1
Volevo solo aggiungere a ciò che @ user389 ha detto che, mentre Photran è eccezionale ed è l'unico IDE Fortran che consente i refactoring, il suo parser fallisce continuamente. D'altra parte, non è necessario commentare il fatto che Eclipse ha fame di memoria.
astrojuanlu,

5

Fortran è ottimizzato per i calcoli di matrice / matrice ed è una vera seccatura con cui lavorare per qualsiasi tipo di analisi del testo. C e C ++ potrebbero non corrispondere a Fortran nel calcolo numerico (è vicino), ma trovo molto più semplice elaborare testi e organizzare i dati (ovvero strutture di dati personalizzate) con C / C ++.

Come altri hanno già detto, non contare i linguaggi interpretati dinamici (Python et al). Potrebbero non offrire la velocità di fusione frontale di Fortan in anticipo, ma ti consentono di concentrarti maggiormente sulla risoluzione del tuo problema computazionale rispetto a tutti i dettagli dell'implementazione. Spesso puoi implementare una soluzione in Python e, se le prestazioni sono inaccettabili, esegui un po 'di profilazione, identifica le aree problematiche e ottimizza quel codice usando Cython o implementa nuovamente l'intero programma in un linguaggio compilato. Una volta chiarita la logica di risoluzione dei problemi, il resto è solo implementazione e, con una buona conoscenza dei fondamenti dell'informatica, dovrebbe essere semplice da rappresentare in qualsiasi varietà di linguaggi di programmazione.


Giusto. Per l'analisi del testo uso anche Python.
Ondřej Čertík,

Puoi anche implementare parte di uno script Python in un linguaggio compilato, ad esempio C ++, e collegarlo. Ad esempio Boost Python, Swig ecc.
Faheem

4

Attualmente sto lavorando in uno dei laboratori nazionali. La maggior parte delle persone intorno a me sono ingegneri meccanici. Chattando con alcune delle persone nei gruppi HPC, stanno facendo principalmente Linux e principalmente C ++. Il gruppo in cui mi trovo attualmente fa principalmente applicazioni desktop e usiamo Windows e in ordine decrescente: C #, FORTRAN, Python, VBA e VB (6, non .NET). Alcuni dei motori di simulazione che utilizziamo sono stati scritti in altri laboratori nazionali di FORTRAN.


4

Ci scusiamo per aver scavato un vecchio thread, ma sembra che anche nel 2015 Fortran venga usato molto.

Mi sono appena imbattuto in questo elenco ( link alternativo ) che in sostanza è un elenco di 13 codici approvati dalla struttura OCLF del DOE per funzionare sulla macchina Summit 300-petaFLOPS che sarà resa disponibile per i ricercatori nel 2018. Ho cercato di trovare la lingua principale utilizzata per il codice (basato su una rapida ricerca su Google) ed ecco cosa ho trovato:

XGC Fortran

SPECFEM Fortran

ACME Fortran (Bunch of climate codes)

DIRAC Fortran (Mostly)

FLASH Fortran

GTC Fortran

HACC C/C++

LS-DALTON Fortran (some C)

NAMD C/C++

NUCCOR Fortran

NWCHEM Fortran

QMCPACK C++

RAPTOR Fortran

Quindi su 13 codici, almeno 10 (in base alla mia ricerca rapida) sembrano essere scritti in Fortran. Non male per una lingua di 50 anni.

NOTA: sono ben consapevole che i confronti linguistici sono inutili, ma dato il numero di persone (specialmente gli utenti C ++) che Fortran parla male, ho pensato che valesse la pena parlarne.


3
Non sono d'accordo, perché la mia esperienza nei laboratori nazionali è stata, al contrario, l'opposto. La maggior parte dei nuovi progetti che vedo a Lawrence Livermore sono scritti in C ++ e la maggior parte delle nuove (o mantenute attivamente) librerie open source all'avanguardia nei solutori ODE, discretizzazioni FEM e librerie di calcolo scientifico per scopi generali sembra essere in C o C ++. Fortran sembra essere utilizzato principalmente in progetti che utilizzano librerie esistenti / legacy; Non vedo molti grandi progetti nuovi che usano Fortran, indipendentemente da quello che penso sulla lingua.
Geoff Oxberry,

Alcuni codici di teoria funzionale della densità scritti anche in Fortran includono VASP e CASTEP , sebbene, come sottolinea @GeoffOxberry, i nuovi progetti tendano forse verso il C ++.
dr.blochwave,

@blochwave Come puoi leggere nel link, i progetti sono per una nuova macchina (con acceleratori ecc.) che sarà online nel 2018. Quindi non è come se prendessero un codice di 25 anni e lo compilassero, sperando che funzionino bene prestazione. Sono abbastanza sicuro che gran parte dei codici nell'elenco di cui sopra sono o sono stati riscritti, come nel nuovo codice. Un certo numero di "nuovi" codici climatici sono anche in Fortran e utilizzati da molte agenzie in numerosi paesi.
stali,

0

Quello che Jack P. penso stia cercando di dire è che dovresti mescolare e abbinare. Un buon software è accuratamente stratificato. Livelli diversi possono mappare in modo più naturale o efficiente a lingue diverse. Dovresti scegliere la lingua più appropriata per ogni livello. Dovresti anche capire come le lingue possono interagire, il che può influire sulla lingua scelta per quale livello.

Una domanda migliore è quali esempi di software progettato in modo eccellente sono là fuori che vale la pena studiare per imparare a progettare software a più livelli.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.