C ++ vs Fortran pentru HPC

Ca atât de des, alegerea depinde de (1) problema pe care încercați să o rezolvați, (2) abilitățile pe care le aveți și (3) oamenii cu care lucrați (cu excepția cazului în care este „un proiect solo). Voi lăsa (3) deoparte pentru moment, deoarece depinde de situația individuală a tuturor.

Dependența de problemă: Fortran excelează la procesarea matricei. Dacă problema dvs. poate fi descrisă în termeni de structuri de date simple și în special matrici, Fortran este bine adaptat. Programatorii Fortran ajung să folosească matrici chiar și în cazuri neevidente (de exemplu, pentru reprezentarea graficelor). C ++ este mai potrivit pentru structuri de date complexe și extrem de dinamice.

Dependența abilităților: este nevoie de mult mai multă experiență de programare pentru a scrie programe C ++ bune decât pentru a scrie programe Fortran bune. Dacă începeți cu puțin program Dacă aveți experiență și aveți atât de mult timp să învățați acel aspect al locului dvs. de muncă, probabil veți obține o rentabilitate mai bună a investiției învățând Fortran decât învățând C ++. Presupunând, bineînțeles, că problema dvs. este potrivită pentru Fortran.

Cu toate acestea, există mai multe programe decât doar Fortran și C ++. Aș recomanda oricui care intră în știința calculelor să înceapă cu un nivel dinamic ridicat. – limbaj de nivel, cum ar fi Python. Amintiți-vă întotdeauna că timpul dvs. este mai valoros decât timpul procesorului!

Comentarii

• ” Amintiți-vă întotdeauna că timpul dvs. este mai valoros decât timpul CPU! ” Ca cineva care lucrează în HPC, nu sunt de acord cu acea parte; orice altceva este la fața locului.
• ” Amintiți-vă întotdeauna că timpul dvs. este mai valabil decât timpul CPU! ” cineva care lucrează în cercetarea științifică, nu aș putea ‘ să nu fiu mai de acord cu acea parte.
• ” Amintiți-vă întotdeauna că timpul tău este mai valoros decât timpul procesorului! ” – Îmi place ‘ să îmi arunc 2 cenți – folosind câteva sute de noduri, fiecare cu 10+ nuclee pentru a rula un program timp de câteva săptămâni poate fi interpretat ca o risipă oribilă a unei resurse foarte prețioase, dacă încă câteva săptămâni ar putea produce un cod care rulează în doar câteva zile. Acele clustere HPC sunt o resursă comună rară și costisitoare.
• ” Amintiți-vă întotdeauna că timpul dvs. este mai valabil decât timpul CPU! „, cod pentru o săptămână, dar pentru o lună, acest ‘ este destul de obișnuit domnule!
• ” Amintiți-vă întotdeauna că timpul dvs. este mai valoros decât timpul CPU! „, aș prefera să codific o lună și să rulez într-o săptămână! – se poate face mai mult odată ce codul este scris, iar alții vor găsi și mai util codul pe care îl scrieți.

Cred că atât C ++, cât și Fortran sunt suficient de bune și funcționează bine.

Cu toate acestea, cred că Fortran este mai bun pentru calculul științific numeric , pentru algoritmi care pot fi exprimați folosind matricele și nu au nevoie de alte structuri de date sofisticate, deci în domenii precum diferențe / elemente finite, solutori PDE, calcule de structură electronică. Fortran este un limbaj specific domeniului. În special, cred că este mai ușor să scrii rapid programe în Fortran decât în C ++, de către un om de știință (nu neapărat un expert în informatică).

C ++ este un limbaj cu scop general, deci se poate exprima orice algoritm în el și este cu siguranță mai bun pentru algoritmi care nu pot fi exprimați folosind matrici, din câmpul HPC probabil unele grafice, generatoare de rețele, manipulare simbolică și așa mai departe.

De asemenea, este posibil să scriem arra y algoritmi în C ++, dar, din experiența mea, necesită mult mai multe cunoștințe de informatică și, în general, mai multă muncă (adică trebuie să creați sau să refolosiți clase pentru manipularea matricei și să gestionați gestionarea memoriei manual sau folosind o bibliotecă precum Teuchos de la Trilinos). Non-experții tind să scrie programe Fortran destul de bune, dar programe oribile C ++ (vorbind din propria experiență).

Declinare de responsabilitate: Personal, îmi place Fortran mult și îl prefer în locul C ++ pentru calculul numeric. Am petrecut peste 2 ani programând în C ++ zilnic și aproape un an programând zilnic în Fortran modern (în zona elementelor finite). Și eu folosesc Python și Cython.

Comentarii

• Unul pentru primul răspuns fiind echilibrat. Cred că C ++ și Fortran nu sunt de departe singurele posibilități în HPC contemporan. Cred că este bine să cunoașteți puterea și punctele slabe atunci când decideți pentru Fortran, C ++ sau Python (sau orice vă place). Am văzut 20.000 de linii de Fortran într-un singur fișier, crescut organic în câteva decenii. Eu personal nu aș folosi pentru altceva decât calculul cu matrice grele izolat. Nici măcar pentru nimic legat de ieșire. Până acum pentru un comentariu părtinitor.
• Nu aș putea ‘ să nu fiu mai de acord cu acest răspuns. Codul nostru de element finit nu ar fi fost posibil să se scrie în Fortran. De fapt, a început în urmă cu 15 ani ca un amestec de C simplu și Fortran (acesta din urmă fiind pentru părțile numerice intensive ale metodei) și s-a mutat treptat la C pur și apoi la C ++ în decursul câtorva ani. Codul a fost în mod constant mai scurt, mai rapid și mai ușor de înțeles și a fost mai capabil după fiecare iterație. Sunt de acord cu alții care subliniază că C ++ îți oferă o mulțime de frânghie cu care să te împuști. Alegeți limba cu care ‘ vă convine cel mai bine.
• Bill, ați folosit Fortran modern (90 și versiuni ulterioare?). Acest lucru este foarte important (ar fi trebuit să fiu mai explicit în răspunsul meu despre acest lucru). Desigur, ” 20.000 de linii de Fortran „, sau f77, de obicei, nu este mai bun decât C ++ bine scris.
• @ OndřejČert í k: cred că dacă credeți că programele moderne cu elemente finite folosesc ” simplu ” structuri de date, atunci ‘ nu te-ai uitat recent la vreuna dintre ele. Încercați să implementați elemente finite adaptive, metode hp sau multigrid pe ochiuri nestructurate folosind structuri de date simple. Bill este la fața locului și cred că pot vorbi pentru el spunând că folosirea ” Fortran modern ” ar fi făcut cu greu mai mult decât un mic diferență.
• @WolfgangBangerth, vezi de exemplu Phaml ( math.nist.gov/phaml ) pentru o implementare Fortran de aproape tot ceea ce ai menționat.

De asemenea, îmi arunc cei doi cenți într-un fel târziu, dar eu ” Tocmai am văzut acest fir și simt că, pentru posteritate, există câteva puncte care trebuie disperate să fie făcute.

Observați în cele ce urmează că voi vorbi despre C și nu despre C ++. De ce? Ei bine, altfel este merele și portocalele să comparăm un limbaj orientat obiect, complet tipărit dinamic, cu ceva la fel de static ca Fortran. Da, unele implementări moderne ale celor mai recente standarde Fortran pot face mai mult decât atât, dar foarte puțini oameni de fapt folosiți-le, și atunci când vorbim despre Fortran, ne gândim la un limbaj simplu, static și imperativ. „Acolo este și C, așa că voi înlocui C cu C ++ pentru următoarele.

toate, orice discuție despre Fortran / C care are compilatoare mai bune este discutabilă. Compilatoarele dedicate C / Fortran fac parte din trecut. Atât gcc / gfortran, cât și icc / ifc sunt doar frontend-uri diferite față de același back-end, adică programul dvs. va fi transformat într-o descriere abstractă de către front-end și apoi optimizat și asamblat de back-end. Dacă scrieți, semantic, același cod în Fortran sau în C, compilatorul va produce, în ambele cazuri, același ansamblu care va rula la fel de repede.

Acest lucru duce acum la al doilea punct: de ce mai vedem diferențe erențe? Problema este că majoritatea comparațiilor sunt făcute de programatorii Fortran care încearcă ceva în C sau invers. Ați observat vreodată cum preferă cei mai mulți autori sau poeți să scrie în limbile lor materne? Ați dori să scrieți poezie într-un limbaj în care nu vă simțiți complet încrezători sau acasă? Desigur că nu … Eu însumi consider că C este limbajul meu de programare „nativ”. Totuși, am petrecut și trei ani lucrez într-un grup care folosea doar Fortran, în care am atins un anumit nivel de fluență. Totuși, nu aș scrie niciodată nimic pe cont propriu în Fortran, deoarece sunt „mai confortabil cu C și, în consecință, codul rezultat va fi mai bun , indiferent cum ați defini asta.

Deci, diferența principală este în programator, nu în limbaj. Deci nu există diferențe? Ei bine, nu chiar. Iată câteva exemple:

• SIMD: indiferent dacă este SSE, SSE3 sau AltiVec, dacă doriți să le utilizați în Fortran, mai bine sperați și vă rugați ca compilatorul să ghicească exact ce doriți și o face așa. Mult noroc. În C aveți, în general, funcții intrinseci pentru fiecare arhitectură sau, mai recent, tipuri de vector SIMD generale în gcc . Majoritatea compilatoarelor Fortran vor folosi instrucțiuni SIMD doar pentru derularea buclelor, dar dacă aveți un nucleu care funcționează pe vectori scurți de date într-un mod neevident, compilatorul probabil că nu îl va vedea.

• Arhitecturi hardware diferite: întreaga arhitectură CUDA este construită în jurul nucleelor din C. Da, Portland Group are acum un CUDA -capable fortran compilator , dar este comercial și, cel mai important, nu provine din NVIDIA. Același lucru este valabil și pentru OpenCL, pentru care cel mai bun lucru pe care l-am putut găsi este un proiect recent care acceptă doar câteva apeluri de bază.

• Programare paralelă: Da, atât MPI cât și OpenMP funcționează foarte bine atât cu C, cât și cu Fortran. Cu toate acestea, dacă doriți un control real al firelor dvs., adică dacă aveți un calcul complet dinamic al memoriei partajate, veți fi la rece cu Fortran. În C aveți pthreadurile standard care, deși nu sunt calde și neclare, vor fi În general, majoritatea calculelor care se bazează pe accesul la sistemul de operare, de ex. fire, procese, sistem de fișiere etc … sunt mai bine deservite cu C. Oh, și nu încercați să vă faceți propriile conectarea la rețea cu Fortran.

• Ușurința de utilizare: Fortran este mai aproape de Matlab decât este C. Odată ce ați trecut peste toate cuvintele cheie diferite și cum să declarați variabile, restul codului arată ca Matlab, făcându-l mai accesibil pentru utilizatorii cu experiență limitată în programare.

• Interoperabilitate: Când creați o structură în C, aspectul datelor reale este direct și determinist. În Fortran, dacă utilizați tablouri de pointer sau date structurate, aspectul real al datelor este puternic dependent de compilator, nu direct înainte, și de obicei complet nedocumentat. Puteți apela C de la Fortran și invers, dar nu începeți să credeți că poate fi la fel de ușor să treceți ceva mai mult decât o matrice statică de la unul la altul și înapoi.

Acest lucru este oarecum oarecum ciudat, la nivel scăzut, dar este vorba de calcul de înaltă performanță despre care vorbim, nu? Dacă nu vă interesează cum să exploatați cel mai bine hardware-ul de bază paradigme, adică implementarea și / sau dezvoltarea algoritmilor care sunt cele mai bune pentru memoria partajată / distribuită, fire, vectorizarea SIMD , GPU-urile care folosesc SIMT și așa mai departe, atunci faceți doar matematică pe computer.

Acest lucru a devenit mult mai lung decât orice am propus, așa că aici este un rezumat – un set de acasă tipuri de mesaje:

• Vei scrie cel mai bun cod pe care îl poți în limba pe care tu o cunoști cel mai bine.
• Nu există nicio diferență în calitatea codului produs de doi compilatori care utilizează același back-end – noi suntem cei care scriu coduri greșite într-o limbă sau alta.
• În ciuda faptului că se simte mult mai scăzut, Fortran este o abstracție destul de înaltă și nu vă va permite să accesați direct anumite caracteristici hardware / OS, SIMD, fire, rețea etc …

Comentarii

• Răspuns bun. Nu ‘ cred că totuși comentariul dvs. final este neapărat adevărat. Eu ‘ sunt eu însumi programator C, dar aveți acces la lucruri de nivel scăzut din Fortran prin bune practici de programare. Modul ideal de a utiliza lucruri precum opțiunile SIMD este să scrieți cod care să-l sugereze puternic (blocarea buclelor, de exemplu) și lăsați compilatorul să o facă pentru dvs. Pentru threading, pur și simplu utilizați openMP (pthreads este, de asemenea, utilizabil cu unele lucrări suplimentare). Fortran are toate lucrurile pe care le menționați, nu ‘ t, doar la un nivel care contează pentru utilizatorul său tipic: numeric.
• @ Reid.Atcheson: Ei bine , dacă blocați totul astfel încât compilatorul să-l prindă, atunci va funcționa automat atât în C, cât și în Fortran. Totuși, problema este cât de mult doriți să aveți încredere în compilatorul dvs.? Și de ce vrei să ai încredere în ea în cazurile în care știi exact ce vrei să faci? OpenMP face threading, da, dar bloc. Puteți să-l păcăliți pentru a obține diferite grupuri de fire pentru a face lucruri diferite, dar asta este doar utilizarea greșită a OpenMP. Pthread-urile pentru Fortran sunt doar împachetări pentru funcțiile C. Sunt de acord, însă, că Fortran este mai ușor dacă ‘ nu intrați în detalii.
• Sigur nu sunteți ‘ Nu veți obține o eficiență de vârf de 99%, bazându-vă pe compilator, dar vă puteți apropia cu ușurință. Dincolo de aceasta, fie trebuie să utilizați intrinseci, fie ASM inline. Trebuie să faceți concesii undeva pentru eficiența generală a programatorului, tocmai de aceea ‘ este motivul pentru care există în primul rând limbaje de programare. În stadiul în care sunteți suficient de nebuni pentru a intra în detaliile intrinseci sau ASM (am fost de câteva ori), Fortran nu este o cârjă. ‘ știați cum să conectați oricum codul optimizat manual asamblat.
• @ Reid.Atcheson: Ei bine, eu ‘ susținem că pentru aplicațiile HPC paralele, puteți ajunge cu mult sub 99% eficiență maximă … Și tipurile de vectori gcc fac din utilizarea intrinsecelor o problemă 🙂
• @Pedro, Post strălucitor. Absolut briliant. Mulțumesc mult pentru postare.Tocmai l-am găsit în timp ce scotoceam în mod aleatoriu prin fire interesante.

Din cei 15 ani de gândire la software științific : Dacă codul tău rulează cu 25% mai repede pentru că îl scrii în Fortran, dar îți ia de 4 ori mai mult timp pentru a-l scrie (fără STL, dificultăți în implementarea unor structuri complexe de date etc.), atunci Fortran câștigă numai dacă cheltuiești o fracțiune semnificativă din ziua ta zvâcnind degetele mari și așteptând terminarea calculelor tale. Având în vedere că, pentru aproape toți, cel mai valoros lucru este timpul nostru, concluzia este următoarea: folosiți limbajul care vă permite să dezvoltați, să depanați și să testați codul cel mai rapid, ignorând motivul că poate fi mai lent decât poate dacă l-ai scris în Fortran.

Abordarea mea a fost să folosesc C ++ pentru orice, cu excepția nucleelor de calcul, care sunt de obicei cele mai bune scris în adunare; aceasta vă cumpără toate performanțele abordării tradiționale HPC, dar vă permite să simplificați interfața, de exemplu, prin supraîncărcarea nucleelor de calcul precum SGEMM / DGEMM / CGEMM / ZGEMM într-o singură rutină, spun Gemm. În mod clar, nivelul de abstractizare poate fi crescut mult mai mare evitând indicii brute și trecând la clase opace, dar este un prim pas frumos.

Consider că cel mai mare dezavantaj al C ++ este creșterea copleșitoare a timpului de compilare, dar, din experiența mea, economiile în timp de dezvoltare compensează mai mult decât aceasta. Un alt dezavantaj este că compilatoarele furnizorului C ++ tind să aibă mai multe erori decât compilatoarele furnizorului C și Fortran. În ultimul an, cred că am întâlnit aproape zece bug-uri în compilatoarele C ++.

Cu toate acestea, cred că anularea pachetelor științifice scrise în limbaje de nivel scăzut (și Fortran) este reticența de a expune interfețe convenabile pentru structuri de date sofisticate: majoritatea oamenilor sunt mulțumiți de interfața Fortran BLAS, deoarece necesită doar indicatori și dimensiuni de conducere pentru a descrie matricile, dar puțini oameni ar susține că interfața obișnuită de rezolvare cu 40 de numere întregi Fortran este ceva aproape de convenabil (cf. UHM, SuperLU, PETSc și Trilinos).

În rezumat, argumentez pentru utilizarea asamblării pentru nucleele de calcul de nivel scăzut, dar limbaje de nivel superior pentru orice altceva, mai ales atunci când funcționează pe structuri de date non-banale.

Rețineți că acest lucru post a dus la această comparație a performanțelor lui C și Fortran pe nucleul $ y: = \ alpha x + y $ .

Comentarii

• De ce nu ‘ ai avea încredere într-un compilator C standard cu optimizare adecvată activată în scopul compilării nucleelor mici? La acel nivel de dimensiune și complexitate a codului, diferența în ceea ce un compilator ar putea scoate din acesta nu este clară.
• Am vorbit cu mai multe persoane care mi-au spus că, chiar și cu restricționarea adecvată a utilizării, încă mai rapid decât codul lor C și / sau C ++ pentru o operație cum ar fi o matrice explicită transpusă. Nu

Deoarece sunt nou aici, m-am uitat prin întrebări vechi și l-am găsit. Să sperăm că nu este tabu să răspunzi la cele vechi!

Deoarece nimeni altcineva nu a menționat acest lucru, mi-am dat seama că aș face-o. Fortran 2003 este aproape pe deplin acceptat de majoritatea compilatorilor majori (intel, ibm, cray, NAG, PCG) chiar și gcc cu (în curând) cea mai nouă versiune 4.7. Fortran 2003 (și 2008) este un limbaj orientat obiect, deși un pic mai detaliat decât C ++. Unul dintre lucrurile care cred că este frumos în legătură cu Fortran este faptul că comitetul standard consideră că informatica științifică este publicul principal (îi mulțumesc lui Damian Rouson că mi-a subliniat acest lucru zilele trecute). > Aduc totul în discuție nu pentru ca programatorii C ++ să devină programatori Fortran, ci pentru ca oamenii Fortran să știe că au acum mai multe opțiuni pe lângă trecerea la C ++ sau emularea conceptelor orientate pe obiecte în Fortran 90/95.

One avertismentul pe care îl voi adăuga este că există un cost pentru a fi la marginea a ceea ce este implementat în compilatoare. Dacă întreprindeți un proiect major în Fortran 2003 chiar acum vă veți întâlni cu bug-uri și va trebui să vă actualizați continuu compilatorul (în special dacă utilizați gcc), deși acest lucru s-a îmbunătățit semnificativ în ultimele luni!

Problema cu C ++ este că aveți numeroase șanse să distrugeți performanța, de exemplu folosind orbește STL, excepții, clase (cheltuieli generale virtuale plus alin probleme), supraîncărcarea operatorului (redundant nou / șterge) sau șabloane (compilarea nesfârșită și erorile criptice par benigne, dar puteți pierde ore în acest fel).

Cu toate acestea, veți obține un acces mai bun la bibliotecile generale și, eventual, vizibilitatea mai mare a codului dvs. (deși acest lucru depinde puternic de câmp și aveți în continuare C pur). Și puteți totuși să compensați lipsa de flexibilitate a lui Fortran prin împachetarea codului său într-un limbaj script precum R, Lush, Matlab / Scilab sau chiar Python, Ruby sau Lua.

Comentarii

• În general, este o idee proastă să aplici tehnici de nivel scăzut în limbaje de nivel înalt. De exemplu, STL este conceput pentru a funcționa la un nivel foarte abstract. Trebuie să fii conștient de ce interfață este conceput pentru, folosiți-l pentru această sarcină și apoi ieșiți din compilatoare.
• Cred că atât mbq ‘ cât și Martin sunt nedrepte. Da, există modalități de a te împușca în picior dacă încerci să implementezi un vector numeric în scopuri de algebră liniară folosind std :: list < dublu >. Dar acel ‘ este un argument prostesc: cel puțin C ++ are o clasă de listă legată pe care o aveți poate folosi, în timp ce Fortran nu ‘ t. Este ‘ ca și cum ar spune ” Mașinile circulă cu o viteză atât de mare încât ai putea să te izbești de un perete și să te rănești; ar trebui să folosiți în schimb trăsuri trase de cai. ” Este ‘ doar o idee prostească să aruncați un limbaj la nivel înalt – lucruri la nivel (de exemplu, C ++) pentru caracteristici la nivel înalt.
• @WolfgangBangerth Nu, acum îl rănești pe Fortran – este la fel de ” nivel scăzut ” deoarece bacteriile sunt ” mai puțin evoluate ” atunci oamenii . Dacă doriți o analogie cu mașina, ar trebui să semene mai mult cu ” puteți folosi atât Jeep, cât și Lexus pentru a traversa o cale mlăștinoasă, dar folosirea primei doare mai puțin „.
• Vă apreciez părerea, dar susțin că Fortran nu este la fel de evoluat ca și C ++: -)

Trei fapte:

• n-dimensional în stil F77 tablouri în C: Nicio problemă la utilizarea CnD (un plug nerușinat, desigur)

• Sistemul de module F90 este slab conceput și ostil pentru a construi medii. (Numele unui modul nu trebuie să se potrivească cu numele fișierului său, de exemplu)

• Fortran nu acceptă refactorizarea bine. Extragerea unor funcționalități unei funcții necesită să atingeți patru locuri: cod real, declarații variabile, declarații de argumente și listă de argumente. C trece cu două locuri de atins. Acest lucru creează efectul eșecului de a gestiona bine datele (desc redată mai jos): Deoarece modularitatea la scară mică este atât de dureroasă, aproape toată lumea scrie subrutine gigantice.

O impresie personală:

• Fortran nu funcționează bine pentru gestionarea datelor. Încercați să returnați un pointer la o structură de date opacă pentru utilizator în F77 sau F90. (transfer(), aici venim)

Comentarii

• Bună Andreas! CnD este interesant, nu ‘ nu știam despre asta. Ah, ai scris-o. 🙂 (f90 suportă, de asemenea, tranșarea, alocabilă pentru tablouri și cel mai important – sintaxa matricei pentru multiplicare, adunare și așa mai departe.) Folosesc CMake cu Fortran și funcționează excelent cu modulele.Ce este exact ” listă de argumente ” Nu ‘ cred că le folosesc, deci sunt necesare doar 3 locuri pentru a le modifica. În C, trebuie în mod obișnuit să modificați codul real, parametrii și un fișier antet, așa că ‘ are și 3 locuri (cel mai sigur în C ++). Da, transfer () nu este ‘ t super frumos, dar de obicei nu aveți ‘ nevoie în practică.
• Refactorizarea fortranului modern este banală cu IDE adecvate, cum ar fi Photran în eclipsă.
• ” Un nume ‘ ‘ nu trebuie să se potrivească cu numele fișierului său, de ex. ” Trebuie să glumiți, puteți avea mai multe module într-un singur fișier. Unele dintre ele acoperă doar câteva linii. Sunt mult mai ușor de creat dacă nu trebuie să creați un fișier pentru fiecare dintre ele.
• Am vrut doar să adăugăm la ceea ce a spus @ user389, în timp ce Photran este minunat și este singurul IDE Fortran care permite refactorizări, analizorul său eșuează tot timpul. Pe de altă parte, nu ‘ nu este nevoie să comentăm faptul că Eclipse este înfometată de memorie.

Fortran este optimizat pentru calcule matrice / matrice și este foarte dureros să lucrezi cu orice tip de analiză a textului. C și C ++ s-ar putea să nu se potrivească cu Fortran în calcul numeric (este aproape), dar mi se pare mult mai ușor să procesez textul și să organizați date (adică structuri de date personalizate) cu C / C ++.

alții au menționat că nu contează limbaje interpretate dinamic (Python și colab.). Este posibil să nu ofere viteza de topire a feței Fortan din față, dar vă permit să vă concentrați mai mult pe rezolvarea problemei dvs. de calcul decât toate detaliile implementării. Adesea puteți implementa o soluție în Python și, dacă performanța este inacceptabilă, faceți câteva profiluri, identificați zonele cu probleme și fie optimizați codul utilizând Cython, fie reimplementați întregul program într-un limbaj compilat. Odată ce ați rezolvat logica de rezolvare a problemelor, restul este doar implementarea și, cu o bună înțelegere a elementelor fundamentale de calcul, ar trebui să fie direct reprezentată în orice varietate de limbaje de programare.

Comentarii

• Așa este ‘. Pentru analiza textului folosesc și Python.
• De asemenea, puteți implementa o parte a unui script Python într-un limbaj compilat, de ex. C ++ și conectați-l. De ex. Boost Python, Swig etc.

În prezent lucrez la unul dintre laboratoarele naționale. Majoritatea dintre cei din jurul meu sunt ingineri mecanici. Discutând cu unii dintre cei din grupurile HPC, ei fac în principal Linux și mai ales C ++. Grupul în care mă aflu în prezent face în principal aplicații desktop și folosim Windows și în ordine descrescătoare: C #, FORTRAN, Python, VBA și VB (6, nu .NET). Unele din pe care le folosim au fost scrise la alte laboratoare naționale din FORTRAN.

Ne pare rău că am dezgropat un fir vechi, dar se pare că, chiar și în 2015, Fortran este folosit foarte mult.

Tocmai am dat peste acest lucru (alternativ link ) listă care este practic o listă de 13 coduri aprobate de facilitatea OCLF a DOE pentru a rula pe aparatul Summit 300-petaFLOPS care va fi pus la dispoziția cercetătorilor în 2018 . Am încercat să găsesc limba principală utilizată pentru cod (pe baza unei căutări rapide pe Google) și iată ce am găsit:

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 

Deci, din 13 coduri, cel puțin 10 (pe baza căutării mele rapide) par a fi scrise în Fortran. Nu e rău pentru o limbă de 50 de ani.

NOTĂ: Sunt foarte conștient de faptul că comparațiile lingvistice sunt inutile, dar având în vedere numărul de oameni (în special utilizatorii de C ++) care au o gură proastă Fortran, m-am gândit că ar fi util să o menționez.

Comentarii

• Nu sunt de acord, deoarece experiența mea la laboratoarele naționale a fost, dacă este ceva, opusul. Cele mai multe dintre noile proiecte pe care le văd la Lawrence Livermore sunt scrise în C ++ și majoritatea bibliotecilor cu sursă deschisă de ultimă generație (sau întreținute în mod activ) în soluții ODE, discretizări FEM și biblioteci de calcul științific cu scop general par a fi în C sau C ++. Fortran pare a fi utilizat în principal în proiecte care utilizează biblioteci existente / vechi; Nu ‘ nu văd o mulțime de proiecte noi, mari care folosesc Fortran, independent de ceea ce cred despre limbă.
• Unele coduri ale teoriei funcționale a densității, de asemenea, scrise în Fortran include VASP și CASTEP , deși așa cum subliniază @GeoffOxberry, nou proiectele tind probabil spre C ++.
• @blochwave După cum puteți citi în link, proiectele sunt pentru o nouă mașină (cu acceleratoare etc.) care va fi online în 2018.Deci nu este ca și cum ar lua un cod de 25 de ani și îl vor compila, sperând să ruleze cu performanțe bune. Sunt destul de sigur că părți mari din codurile din lista de mai sus au fost sau au fost rescrise, ca în codul nou. Un număr de ” coduri climatice noi ” sunt și în Fortran și sunt utilizate de multe agenții din mai multe țări.

Ceea ce încearcă să spună Jack P. cred că ar trebui să amesteci și să te potrivești. Un software bun este stratificat cu atenție. Diferite straturi pot fi mapate mai natural sau mai eficient la diferite limbi. Ar trebui să alegeți limba cea mai potrivită pentru fiecare strat. De asemenea, ar trebui să înțelegeți cum interoperă limbile, ceea ce poate afecta ce limbă alegeți pentru ce strat.

O întrebare mai bună este ce exemple de programe software excelent concepute care merită studiate pentru a afla cum să proiectați software stratificat.