C ++ vs Fortran for HPC

Som så ofte avhenger valget av (1) problemet du prøver å løse, (2) ferdigheter du har, og (3) menneskene du jobber med (med mindre det er et soloprosjekt). Jeg lar (3) være til side for øyeblikket fordi det avhenger av alles individuelle situasjon.

Problemavhengighet: Fortran utmerker seg ved array-behandling. Hvis problemet ditt kan beskrives i form av enkle datastrukturer og spesielt matriser, er Fortran godt tilpasset. Fortran-programmerere ender opp med å bruke arrays selv i ikke-åpenbare tilfeller (f.eks. For å representere grafer). C ++ er bedre egnet for komplekse og svært dynamiske datastrukturer.

Ferdighetsavhengighet: det tar mye mer programmeringserfaring å skrive gode C ++ -programmer enn å skrive gode Fortran-programmer. Hvis du starter med lite program erfaring og bare har så mye tid til å lære det aspektet av jobben din, vil du sannsynligvis få bedre avkastning på investeringslæringen Fortran enn å lære C ++. Forutsatt selvfølgelig at problemet ditt passer til Fortran.

Imidlertid er det mer å programmere enn bare Fortran og C ++. Jeg vil anbefale alle som går inn i beregningsvitenskap om å starte med en dynamisk høy -nivåspråk som Python. Husk alltid at tiden din er mer verdifull enn CPU-tid!

Kommentarer

• » Husk alltid at din tid er mer verdifull enn CPU-tid! » Som noen som jobber i HPC, er jeg uenig i den delen; alt annet er perfekt.
• » Husk alltid at tiden din er mer verdifull enn CPU-tiden! » Som noen som jobber med vitenskapelig forskning, kunne jeg ikke ‘ ikke være mer enig med den delen.
• » Husk alltid at din tid er mer verdifull enn CPU-tid! » – Jeg ‘ vil kaste inn mine 2 øre – ved hjelp av flere hundre noder, hver med 10+ kjerner for å kjøre noe program i flere uker kan tolkes som et fryktelig sløsing med en mest verdifulle ressurs, hvis et par uker til kunne produsere en kode som bare kjører på et par dager. Disse HPC-klyngene er en sjelden og kostbar vanlig ressurs.
• » Husk alltid at tiden din er mer verdifull enn CPU-tid! «, kode i en uke, men løp i en måned, denne ‘ er ganske vanlig sir!
• » Husk alltid at tiden din er mer verdifull enn CPU-tid! «, jeg vil helst kode i en måned og løpe om en uke! – mer kan gjøres når koden er skrevet, og andre vil også finne koden du skriver mer nyttig.

Jeg tror at både C ++ og Fortran er gode nok og fungerer bra.

Imidlertid tror jeg at Fortran er bedre for numerisk vitenskapelig databehandling, for algoritmer som kan uttrykkes ved hjelp av matriser og trenger ikke andre sofistikerte datastrukturer, så i felt som endelige forskjeller / elementer, PDE-løsere, elektroniske strukturberegninger. Fortran er et domenespesifikt språk. Spesielt tror jeg at det er lettere å skrive raskt programmer i Fortran enn i C ++, av en forsker (ikke nødvendigvis en datavitenskapelig ekspert).

C ++ er et språk for generell bruk, så man kan uttrykke hvilken som helst algoritme i det, og det er absolutt bedre for algoritmer som ikke kan uttrykkes ved hjelp av matriser, fra HPC-felt, sannsynligvis noen grafer, maskegeneratorer, symbolsk manipulasjon og så videre.

Det er også mulig å skrive arra y-algoritmer i C ++, men etter min erfaring krever det mye mer datavitenskapelig kunnskap og generelt mer arbeid (dvs. man trenger å lage eller gjenbruke klasser for arraymanipulering, og håndtere minneadministrasjon for hånd eller ved hjelp av noe bibliotek som Teuchos fra Trilinos). Ikke-eksperter har en tendens til å skrive ganske gode Fortran-programmer, men fryktelige C ++ – programmer (snakker fra min egen erfaring).

Ansvarsfraskrivelse: Jeg liker Fortran veldig mye, og jeg foretrekker det fremfor C ++ for numerisk databehandling. Jeg har brukt over 2 år med programmering i C ++ hver dag, og nesten et år på programmering i moderne Fortran daglig (i området med begrensede elementer). Jeg bruker også Python og Cython mye.

Kommentarer

• En opp for det første svaret er balansert. Jeg tror C ++ og Fortran langt på vei ikke er de eneste mulighetene i moderne HPC. Jeg synes det er bra å vite styrken og de svake punktene når du bestemmer deg for Fortran, C ++ eller Python (eller hva du vil). Jeg har sett 20.000 linjer Fortran i en enkelt fil, økologisk dyrket i løpet av noen tiår. Jeg personlig ville ikke brukt til noe annet enn isolert tung matrise-databehandling. Ikke engang for noe relatert til produksjon. Så langt for en partisk kommentar.
• Jeg kunne ikke ‘ t er mer uenig i dette svaret. Vår endelige elementkode hadde ikke vært mulig å skrive i Fortran. Faktisk startet det for 15 år siden som en blanding av vanlig C og Fortran (sistnevnte var for de numerisk intensive delene av metoden), og den flyttet gradvis til ren C og deretter til C ++ i løpet av flere år. Koden ble konsekvent kortere, raskere og lettere å forstå, og den var mer i stand etter hver iterasjon. Jeg er enig med andre som påpeker at C ++ gir deg mye tau å skyte deg selv med. Velg språket du ‘ er mest komfortabel med.
• Bill, brukte du moderne Fortran (90 og senere tillegg?). Dette er veldig viktig (jeg burde ha vært mer eksplisitt i svaret mitt om dette). Selvfølgelig er » 20.000 linjer i Fortran «, eller f77 vanligvis ikke bedre enn godt skrevet C ++.
• @ OndřejČert í k: Jeg tror at hvis du mener at moderne endelige elementprogrammer bruker » enkel » datastrukturer, så har du ikke ‘ t sett på noen av dem nylig. Prøv å implementere adaptive endelige elementer, hp-metoder eller multigrid på ustrukturerte masker ved hjelp av enkle datastrukturer. Bill er perfekt, og jeg tror jeg kan snakke for ham når han sier at bruk av » moderne Fortran » ville ha gjort nesten ikke en liten forskjell.
• @WolfgangBangerth, se for eksempel Phaml ( math.nist.gov/phaml ) for en Fortran-implementering av stort sett alt som du nevnte.

Jeg kaster også de to øre mine sent, men jeg » Jeg har bare sett denne tråden, og jeg føler at det for ettertiden er noen punkter som sårt trenger å komme med.

Merk deg i det følgende at jeg vil snakke om C og ikke C ++. Hvorfor? Vel, ellers er det epler og appelsiner å sammenligne et fullverdig dynamisk skrevet objektorientert språk med noe så statisk som Fortran. Ja, noen moderne implementeringer av de nyeste Fortran-standardene kan gjøre mer enn bare det, men veldig få mennesker faktisk bruk dem, og så når vi snakker om Fortran, tenker vi enkelt, statisk og tvingende språk. Det er der C er også, så jeg erstatter C med C ++ for det følgende.

Først av alt, enhver diskusjon om Fortran / C å ha bedre kompilatorer er vanskelig. Dedikerte C / Fortran-kompilatorer er en saga blott. Både gcc / gfortran og icc / ifc er bare forskjellige frontender til samme back-end, dvs. programmet ditt vil bli forvandlet til en abstrakt beskrivelse av frontend og deretter optimalisert og samlet av back-end. Hvis du skriver semantisk den samme koden i Fortran eller i C, vil kompilatoren i begge tilfeller produsere den samme samlingen som vil løpe like fort.

Dette fører nå til mitt andre poeng: hvorfor ser vi fortsatt forskjell erenser? Problemet er at de fleste sammenligninger er gjort av Fortran-programmerere som prøver noe i C eller omvendt. Har du noen gang lagt merke til hvordan de fleste forfattere eller poeter foretrekker å skrive på morsmålet? Vil du skrive poesi på et språk der du ikke føler deg helt trygg eller hjemme? Selvfølgelig ikke … Selv anser jeg C for å være mitt «innfødte» programmeringsspråk. Jeg brukte imidlertid også tre år jobbet i en gruppe som bare brukte Fortran, der jeg har oppnådd en viss flyt. Jeg vil imidlertid aldri skrive noe alene på Fortran siden jeg er mer komfortabel med C og som en konsekvens av den resulterende koden vil være bedre , uansett hva du definerer det som.

Så den største forskjellen er i programmereren, ikke språket. Så det er ingen forskjeller? Vel, ikke helt. Her er noen eksempler:

• SIMD: Enten det er SSE, SSE3 eller AltiVec, hvis du vil bruke dem i Fortran, må du bedre håpe og be om at kompilatoren gjetter nøyaktig hva du vil og gjør det slik. Lykke til. I C har du generelt egne funksjoner for hver arkitektur, eller, nylig, generelle SIMD-vektortyper i gcc . De fleste Fortran-kompilatorer vil bare bruke SIMD-instruksjoner for å rulle ut løkker, men hvis du har en kjerne som fungerer på korte vektorer med data på en ikke-åpenbar måte, vil kompilatoren sannsynligvis ikke se den.

• Ulike maskinvarearkitekturer: Hele CUDA-arkitekturen er bygget rundt kjerner i C. Ja, Portland-gruppen har nå en CUDA -kapabel fortran kompilator også, men den er kommersiell, og viktigst av alt, den er ikke fra NVIDIA. Det samme gjelder OpenCL, der det beste jeg kunne finne er et nylig prosjekt som bare støtter noen få grunnleggende samtaler.

• Parallell programmering: Ja, både MPI og OpenMP fungerer helt fint med både C og Fortran. Men hvis du vil ha reell kontroll over trådene dine, dvs. hvis du har en full dynamisk beregning av delt minne, vil du være ute i kulden med Fortran. I C har du standard pthreads som, selv om de ikke er varme og uklare, vil fremdeles får deg gjennom stormen. Generelt sett betjenes de fleste beregninger som er avhengige av tilgang til operativsystemet, f.eks. tråder, prosesser, filsystemer osv. med C. Å, og ikke prøv å gjøre ditt eget nettverk med Fortran.

• Brukervennlighet: Fortran er nærmere Matlab enn C er. Når du har kommet over alle de forskjellige nøkkelordene og hvordan du deklarerer variabler, ser resten av koden ut som Matlab, noe som gjør den mer tilgjengelig for brukere med begrenset programmeringserfaring.

• Interoperabilitet: Når du oppretter en struktur i C, er utformingen av de faktiske dataene rett fram og deterministisk. I Fortran, hvis du bruker pekerarrayer eller strukturerte data, er den faktiske utformingen av data sterkt avhengig av kompilatoren, ikke rett fremover, og vanligvis helt papirløst. Du kan ringe C fra Fortran og omvendt, men begynn ikke å tenke at det kan være like enkelt å overføre noe mer enn en statisk matrise fra den ene til den andre og tilbake.

Dette er alt litt nerdete ting på lavt nivå, men dette er High-Performance Computing vi snakker om, ikke sant? Hvis du ikke er interessert i hvordan du best kan utnytte den underliggende maskinvaren paradigmer, dvs. implementering og / eller utvikling av algoritmer som er best for delt / distribuert minne, tråder, SIMD-vektorisering , GPUer som bruker SIMT og så videre, så gjør du bare matte på en datamaskin.

Dette har blitt mye lengre enn alt jeg hadde med meg, så her er et sammendrag – et sett med hjem meldinger av slags:

• Du vil skrive den beste koden du kan på det språket som du kjenner best.
• Det er ingen forskjell i kvaliteten på koden produsert av to kompilatorer som bruker samme backend – det er oss som skriver dårlig kode på ett eller annet språk.
• Til tross for at han føler seg mer lavt nivå, er Fortran ganske abstrakt på høyt nivå, og vil ikke la deg få tilgang til visse maskinvare / OS-funksjoner direkte, f.eks. SIMD, tråder, nettverk osv …

Kommentarer

• God respons. Jeg tror ikke ‘ men den endelige kommentaren din er nødvendigvis sant. Jeg ‘ er selv en C-programmerer, men du får tilgang til ting på lavt nivå i Fortran gjennom god programmeringspraksis. Den ideelle måten å bruke ting som SIMD ops er å skrive kode som sterkt antyder det (for eksempel blokkering av sløyfer) og la kompilatoren gjøre det for deg. For threading, bruk bare openMP (pthreads er også brukbar med litt ekstra arbeid). Fortran har alle tingene du nevner, det ‘ t, bare på et nivå som betyr noe for den typiske brukeren: numerisk.
• @ Reid.Atcheson: Vel , hvis du blokkerer alt slik at kompilatoren får tak i det, vil det fungere automatisk både i C og i Fortran. Problemet er imidlertid hvor langt vil du stole på kompilatoren din? Og hvorfor vil du måtte stole på det i tilfeller når du vet nøyaktig hva du vil ha gjort? OpenMP tråder, ja, men blokkvis. Du kan lure det til å få forskjellige trådbassenger til å gjøre forskjellige ting, men det er bare å misbruke OpenMP. Pthreads for Fortran er bare innpakninger til C-funksjonene. Jeg er imidlertid enig i at Fortran er lettere hvis du ‘ ikke er interessert i detaljene.
• Sikker på at du ikke er ‘ t kommer til å bli fullblåst 99% toppeffektivitet avhengig av kompilatoren, men du kan lett komme ganske nær. Utover dette må du enten bruke indre eller innebygd ASM. Du må gjøre innrømmelser et eller annet sted for generell programmeringseffektivitet, det er ‘ hvorfor programmeringsspråk eksisterer i utgangspunktet. På det stadiet at du faktisk er sinnssyk nok til å komme inn i detaljene til egenart eller ASM (jeg har vært noen ganger), er Fortran ikke ‘ t en krykke. Du ‘ vet uansett hvordan du skal koble til den sammensatte håndoptimaliserte koden din.
• @ Reid.Atcheson: Vel, jeg ‘ d hevder at for parallelle HPC-applikasjoner kan du godt havne langt under 99% toppeffektivitet … Og gcc-vektortypene gjør bruk av egenart et ikke-problem 🙂
• @ Pedro, Strålende innlegg. Helt strålende. Tusen takk for innlegg.Fant det bare mens jeg tilfeldig rotet gjennom interessante tråder.

Fra mine 15 år med å tenke på vitenskapelig programvare : Hvis koden din kjører 25% raskere fordi du skriver den i Fortran, men det tar deg fire ganger så lang tid å skrive den (ingen STL, problemer med å implementere komplekse datastrukturer osv.), Så vinner Fortran bare hvis du bruker en betydelig brøkdel av dagen din snurrer tommelen og venter på at beregningene dine skal fullføres. Gitt at for nesten alle oss er det mest verdifulle er vår egen tid, er konklusjonen denne: bruk språket som lar deg utvikle, feilsøke og teste koden din raskest, med grunn til å ignorere at det kan være tregere enn kanskje mulig hvis du skrev det i Fortran.

Min tilnærming har vært å bruke C ++ til alt annet enn beregningskjerner, som vanligvis er best skrevet i forsamlingen; Dette kjøper all ytelsen til den tradisjonelle HPC-tilnærmingen, men lar deg forenkle grensesnittet, f.eks. ved å overbelaste beregningskjerner som SGEMM / DGEMM / CGEMM / ZGEMM i en enkelt rutine, sier Gemm. Det er klart at abstraksjonsnivået kan løftes mye høyere ved å unngå rå pekere og bytte til ugjennomsiktige klasser, men det er et fint første skritt. men, etter min erfaring, sparer utviklingen mer enn det. En annen ulempe er at leverandør C ++ – kompilatorer har en tendens til å ha flere feil enn leverandør C og Fortran kompilatorer. I løpet av det siste året tror jeg at jeg har løpt på nesten ti bugs i C ++ – kompilatorer.

Med alt dette sagt, tror jeg at angring av vitenskapelige pakker skrevet på lavnivåspråk (og Fortran) er motviljen mot å eksponere praktiske grensesnitt for sofistikerte datastrukturer: de fleste er fornøyd med Fortran BLAS-grensesnittet, da det bare krever pekere og ledende dimensjoner for å beskrive matriser, men få mennesker vil hevde at det vanlige 40-heltall Fortran sparsomme direkte løsningsgrensesnittet er noe nær praktisk (jf. UHM, SuperLU, PETSc og Trilinos).

Oppsummert argumenterer jeg for å bruke montering for beregningskjerner på lavt nivå, men språk på høyere nivå for alt annet, spesielt når du opererer på ikke-trivielle datastrukturer.

Merk at dette innlegg resulterte i denne sammenligningen av ytelsen til C og Fortran på kjernen $ y: = \ alpha x + y $ .

Kommentarer

• Hvorfor ville ‘ ikke stole på en standard C-kompilator med passende optimalisering aktivert for å kompilere små kjerner? På det nivået av kodestørrelse og kompleksitet er forskjellen i hva en kompilator kan trekke ut av den uklar.
• Jeg har snakket med flere mennesker som har fortalt meg at selv om de hadde begrenset bruk, var Fortran deres fremdeles raskere enn C- og / eller C ++ -koden for noen operasjoner som en eksplisitt matrise-transponering. Jeg ‘ sier ikke at det ‘ er umulig å gjøre C- eller C ++ -koden like rask, men at Fortran-kompilatoren har en tendens til å gjøre en bedre jobb.
• Jeg har samme erfaring med » begrense » søkeordet (min enkle Fortran-kode var alltid litt raskere). Men min ekspertise er begrenset, og jeg har rett og slett ikke ‘ ikke tid til å investere i å forstå den genererte forsamlingen fra gcc. Så jeg bruker ganske enkelt Fortran, det ‘ er enkelt og det ‘ er raskt.
• @JackPoulson: Kompilatoren argument er noe jeg hører ganske mye fra Fortran-samfunnet. Dessverre er de fleste kompilatorer, f.eks. gcc eller ifc / icc, bruk forskjellige språkgrensesnitt for samme back-end. Maskineriet som gjør optimalisering og kodegenerering er identisk, og derfor er forskjellene i resultatene sannsynligvis på grunn av forskjeller i kjennskapen til programmereren med det underliggende språket …
• Bare for å gi litt perspektiv på det ofte gjentatte, sjelden validerte påstanden om at Fortran er raskere på numeriske kjerner: For en stund tilbake la vi merke til at den sparsomme matrisevektoren formere seg i Trilinos ‘ Epetra-pakken var 30% tregere enn den i avtalen.II. Førstnevnte ble skrevet i rett frem Fortran 77, sistnevnte i rett frem C uten bruk av ‘ begrenser ‘. Begge hadde rundt 10-15 linjer med kode. I dag bruker Trilinos koden som er heist fra deal.II. Jeg ‘ er sikker på at man kan finne mange tilfeller der F77 er raskere enn C. Poenget er at det ikke er ‘ t så mer i dag.

Siden jeg er ny her, så jeg gjennom gamle spørsmål og fant denne. Forhåpentligvis er det ikke tabu å svare på gamle!

Siden ingen andre har nevnt dette, skjønte jeg at jeg ville. Fortran 2003 er nesten fullt støttet av de fleste av de store kompilatorene (intel, ibm, cray, NAG, PCG) til og med gcc med (snart å være) nyeste utgivelse 4.7. Fortran 2003 (og 2008) er et objektorientert språk, om enn litt mer ordentlig enn C ++. Noe av det jeg synes er hyggelig med Fortran, er det faktum at standardkomiteen ser på vitenskapelig databehandling som sitt primære publikum (jeg takker Damian Rouson for at hun påpekte dette for meg her om dagen).

Jeg tar ikke opp alt dette slik at C ++ programmerere blir Fortran-programmerere, men slik at Fortran-folk vet at de har flere muligheter nå i tillegg til å bytte til C ++ eller etterligne objektorienterte konsepter i Fortran 90/95.

En advarselen jeg vil legge til er at det er en kostnad å være på kanten av det som er implementert i kompilatorene. Hvis du gjennomfører et større prosjekt i Fortran 2003 akkurat nå, vil du snuble over feil og kontinuerlig trenger å oppdatere kompilatoren din (spesielt hvis du bruker gcc), selv om dette har blitt betydelig bedre de siste månedene!

Problemet med C ++ er at du har mange sjanser til å ødelegge ytelsen, for eksempel ved blindt å bruke STL, unntak, klasser (virtuell overhead pluss alignm problemer), overbelastning av operatøren (overflødig ny / sletter) eller maler (uendelig kompilering og kryptiske feil virker godartede, men du kan kaste bort timer på denne måten).

Men mer får du bedre tilgang til generelle biblioteker og muligens synlighet av koden din (selv om dette avhenger sterkt av feltet, og du har fortsatt ren C). Og du kan fortsatt kompensere Fortrans manglende fleksibilitet ved å pakke koden på et skriptspråk som R, Lush, Matlab / Scilab eller til og med Python, Ruby eller Lua.

Kommentarer

• Det er generelt en dårlig idé å bruke teknikker på lavt nivå på språk på høyt nivå. For eksempel er STL designet for å fungere på et veldig abstrakt nivå. Man må være klar over hva grensesnittet er er designet for, bruk den til denne oppgaven og kom deg ut av kompilatoren.
• Jeg tror både mbq ‘ s og Martin ‘ poeng er urettferdige. Ja, det er måter å skyte seg selv i foten hvis du prøver å implementere en numerisk vektor for lineære algebraformål ved hjelp av std :: list < dobbelt >. Men at ‘ er et dumt argument: i det minste har C ++ en lenket listeklasse som du kan bruke, mens Fortran ikke ‘ t. Det ‘ er som å si » Biler kjører i så høy hastighet at du kan krasje mot en vegg og bli skadet; du bør bruke hestevogner i stedet. » Det ‘ er bare en dum idé å kaste et språk på høyt nivå som også støtter lav -nivå ting (f.eks. C ++) for å ha funksjoner på høyt nivå.
• @WolfgangBangerth Nei, nå sårer du Fortran – det er som » lavt nivå » som bakterier er » mindre utviklet » så mennesker . Hvis du vil ha en bilanalogi, bør den være mer som «, du kan bruke både Jeep og Lexus til å krysse en sumpete vei, men å bruke den første gjør mindre vondt «.
• Jeg setter pris på din mening, men jeg fastholder at Fortran ikke er ‘ t så utviklet som C ++ er: -)

Tre fakta:

• F77-stil n-dimensjonal matriser i C: Ikke noe problem å bruke CnD (en skamløs plugg, riktignok)

• F90 «s modulsystem er dårlig designet og fiendtlig å bygge miljøer. (En moduls navn trenger ikke å matche filnavnet, f.eks.)

• Fortran støtter ikke refactoring godt. Å trekke litt funksjonalitet ut av en funksjon krever at du berører fire steder: Faktisk kode, variable erklæringer, argumenterklæringer og argumentliste. C får det med to steder å berøre. Dette forsterker effekten av manglende administrering av data godt (desc ribbet nedenfor): Siden småskala modularitet er så smertefull, skriver omtrent alle gigantiske underrutiner.

Ett personlig inntrykk:

• Fortran fungerer ikke bra for å administrere data. Prøv å returnere en peker til en bruker-ugjennomsiktig datastruktur i F77 eller F90. (transfer(), her kommer vi)

Kommentarer

• Hei Andreas! CnD er interessant, jeg visste ikke ‘ om det. Ah, du skrev det. 🙂 (f90 støtter også kutting, kan tildeles for arrays og viktigst av alt – array-syntaks for multiplikasjon, tillegg og så videre.) Jeg bruker CMake med Fortran og det fungerer bra med moduler.Hva er egentlig » argumentlisten «? Jeg tror ikke ‘ jeg bruker disse, så det er bare 3 steder som trengs for å endre. I C må du vanligvis endre den faktiske koden, parametrene og en headerfil, så den ‘ er også 3 steder (absolutt i C ++). Ja, overføring () er ikke ‘ t super fin, men du trenger vanligvis ikke ‘ i praksis.
• Refactoring moderne fortran er trivielt med riktige IDEer, som Photran i formørkelse.
• » En modul ‘ navn trenger ikke ‘ å matche filnavnet, f.eks. » Du må tulle, du kan ha mange moduler i en fil. Noen av dem spenner bare over et par linjer. De er mye lettere å lage hvis du ikke trenger å lage en fil for hver av dem.
• Ville bare legge til det @ user389 sa det, mens Photran er flott og er den eneste Fortran IDE som tillater refactorings, mislykkes parseren hele tiden. På den annen side er det ‘ ingen grunn til å kommentere det faktum at formørkelse er minnehungrig.

Fortran er optimalisert for matrise- / matriksberegninger og er en grundig smerte å jobbe med for alle typer tekstparsering. C og C ++ stemmer kanskje ikke overens med Fortran i numerisk databehandling (det er nært), men jeg synes det er mye lettere å behandle tekst og organisere data (dvs. tilpassede datastrukturer) med C / C ++.

Som andre har nevnt, ikke telle ut dynamiske tolket språk (Python et al). De tilbyr kanskje ikke ansiktssmeltehastigheten til Fortan foran, men de lar deg fokusere mer på å løse beregningsproblemet enn alle detaljene i implementeringen. Ofte kan du implementere en løsning i Python, og hvis ytelsen er uakseptabel, gjør du noe profilering, identifiser problemområdene, og optimaliser den koden ved hjelp av Cython eller implementer hele programmet på nytt i et kompilert språk. Når du har utpekt problemløsningslogikken, er resten bare implementering, og med god forståelse av databehandling, bør det være greit å representere i alle forskjellige programmeringsspråk.

Kommentarer

• At ‘ er riktig. For tekstparsering bruker jeg også Python.
• Du kan også implementere deler av et Python-skript på et kompilert språk, f.eks. C ++ og hekt den inn. F.eks. Boost Python, Swig etc.

Jeg jobber for tiden på et av de nasjonale laboratoriene. av folkene rundt meg er mekaniske ingeniører. Chatter med noen av menneskene i HPC-gruppene, gjør de mest Linux og mest C ++. Gruppen jeg er for øyeblikket i, bruker for det meste skrivebordsprogrammer, og vi bruker Windows og i fallende rekkefølge: C #, FORTRAN, Python, VBA og VB (6, ikke .NET). Noen av simuleringsmotorer vi bruker ble skrevet på andre nasjonale laboratorier i FORTRAN.

Beklager at vi har gravd opp en gammel tråd, men det ser ut til at selv i 2015 brukes Fortran mye.

Jeg kom nettopp over dette (alternativ link ) liste som i utgangspunktet er en liste over 13 koder som er godkjent av DOEs OCLF-anlegg for å kjøre på 300-petaFLOPS Summit-maskinen som vil bli gjort tilgjengelig for forskere i 2018 Jeg prøvde å finne hovedspråket som ble brukt til koden (basert på et raskt google-søk), og her er det jeg fant:

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 

Så av 13 minst 10 (basert på mitt raske søk) ser ut til å være skrevet i Fortran. Ikke dårlig for et 50 år gammelt språk.

MERK: Jeg er godt klar over at språk sammenligninger er ubrukelige, men gitt antall personer (spesielt C ++ brukere) som har dårlig munn Fortran, trodde jeg det kunne lønne seg å nevne det.

Kommentarer

• Jeg er uenig, fordi min erfaring på de nasjonale laboratoriene, om noe, har vært det motsatte. De fleste av de nye prosjektene jeg ser på Lawrence Livermore er skrevet i C ++, og de fleste av de nye (eller aktivt vedlikeholdte) toppmoderne open source-biblioteker i ODE-løsere, FEM-diskretiseringer og generelle formål vitenskapelige databiblioteker ser ut til å være i C eller C ++. Fortran ser ut til å brukes hovedsakelig i prosjekter som bruker eksisterende / eldre biblioteker; Jeg ser ikke ‘ mange store, nye prosjekter ved hjelp av Fortran, uavhengig av hva jeg synes om språket.
• Noen tetthet funksjonelle teorikoder også skrevet i Fortran inkluderer VASP og CASTEP , men som @GeoffOxberry påpeker, ny prosjekter har kanskje en tendens mot C ++.
• @blochwave Som du kan lese i lenken, er prosjektene for en ny maskin (med akseleratorer osv.) som vil være online i 2018.Så det er ikke som om de tar en 25 års kode og kompilerer den, i håp om å kjøre med god ytelse. Jeg er ganske sikker på at store deler av kodene i listen ovenfor er eller er skrevet om, som i ny kode. Et antall » nye » klimakoder er også i Fortran og brukes av mange byråer i en rekke land.

Det Jack P. jeg tror prøver å si er at du skal blande og matche. Et godt stykke programvare er nøye lagdelt. Ulike lag kan kartlegge mer naturlig eller effektivt til forskjellige språk. Du bør velge det mest passende språket for hvert lag. Du bør også forstå hvordan språk kan fungere sammen, noe som kan påvirke hvilket språk du velger for hvilket lag.

Et bedre spørsmål er hvilke eksempler på utmerket utformet programvare der ute som er verdt å studere for å lære om hvordan du designer lagvis programvare.