C ++ vs Fortran til HPC

Som så ofte afhænger valget af (1) det problem, du prøver at løse, (2) de færdigheder, du har, og (3) de mennesker, du arbejder med (medmindre det er et solo-projekt). Jeg vil lade (3) være til side for øjeblikket, fordi det afhænger af alles individuelle situation.

Problemafhængighed: Fortran udmærker sig ved array-behandling. Hvis dit problem kan beskrives i form af enkle datastrukturer og især arrays, er Fortran godt tilpasset. Fortran-programmører ender med at bruge arrays selv i ikke-åbenlyse tilfælde (f.eks. Til at repræsentere grafer). C ++ er bedre egnet til komplekse og meget dynamiske datastrukturer.

Færdighedsafhængighed: det tager meget mere programmeringserfaring at skrive gode C ++ programmer end at skrive gode Fortran-programmer. Hvis du starter med lidt program Hvis du har erfaring og kun har så meget tid til at lære det aspekt af dit job, får du sandsynligvis et bedre afkast på investering i Fortran end at lære C ++. Under forudsætning af, selvfølgelig, at dit problem passer til Fortran.

Der er dog mere ved programmering end bare Fortran og C ++. Jeg vil anbefale alle, der går i beregningsvidenskab, at starte med en dynamisk høj -niveau sprog som Python. Husk altid, at din tid er mere værdifuld end CPU-tid!

Kommentarer

• ” Husk altid, at din tid er mere værdifuld end CPU-tid! ” Som en person, der arbejder i HPC, er jeg uenig med den del; alt andet er perfekt.
• ” Husk altid, at din tid er mere værdifuld end CPU-tid! ” Som nogen, der arbejder inden for videnskabelig forskning, kunne jeg ikke ‘ ikke være mere enig med den del.
• ” Husk altid, at din tid er mere værdifuld end CPU-tid! ” – Jeg ‘ vil gerne kaste mine 2 cent ind – ved hjælp af flere hundrede noder, hver med 10+ kerner til at køre et program i flere uger kan fortolkes som et forfærdeligt spild af en mest værdifuld ressource, hvis et par uger mere kunne producere en kode, der kun kører på et par dage. Disse HPC-klynger er en sjælden og dyr fælles ressource.
• ” Husk altid, at din tid er mere værdifuld end CPU-tid! “, kode i en uge, men kør i en måned, denne ‘ er helt almindelig sir!
• ” Husk altid, at din tid er mere værdifuld end CPU-tid! “, jeg vil hellere kode i en måned og køre om en uge! – mere kan gøres, når koden er skrevet, og andre finder også den kode, du skriver, mere nyttigt.

Jeg synes, at både C ++ og Fortran er gode nok og fungerer godt.

Men jeg tror, at Fortran er bedre til numerisk videnskabelig computing, for algoritmer, der kan udtrykkes ved hjælp af arrays og behøver ikke andre sofistikerede datastrukturer, så i felter som endelige forskelle / elementer, PDE-løsere, elektroniske strukturberegninger. Fortran er et domænespecifikt sprog. Jeg synes især, det er lettere at skrive hurtigt programmer i Fortran end i C ++, af en videnskabsmand (ikke nødvendigvis en datalogisk ekspert).

C ++ er et generelt sprog, så man kan udtrykke enhver algoritme i det, og det er bestemt bedre for algoritmer, der ikke kan udtrykkes ved hjælp af arrays, fra HPC-feltet sandsynligvis nogle grafer, mesh-generatorer, symbolsk manipulation og så videre.

Det er også muligt at skrive arra y-algoritmer i C ++, men efter min erfaring kræver det meget mere datalogisk viden og generelt mere arbejde (dvs. man har brug for at oprette eller genbruge klasser til arraymanipulation og håndtere hukommelsesstyring manuelt eller ved hjælp af et bibliotek som Teuchos fra Trilinos). Ikke-eksperter har tendens til at skrive temmelig gode Fortran-programmer, men forfærdelige C ++ – programmer (taler ud fra min egen erfaring).

Ansvarsfraskrivelse: Jeg kan personligt lide Fortran meget, og jeg foretrækker det frem for C ++ til numerisk computing. Jeg har brugt over 2 år med programmering i C ++ dagligt og næsten et år programmering i moderne Fortran dagligt (inden for begrænsede elementer). Jeg bruger også Python og Cython meget.

Kommentarer

• En op til det første svar er afbalanceret. Jeg tror, at C ++ og Fortran langtfra ikke er de eneste muligheder i moderne HPC. Jeg synes, det er godt at kende styrken og de svage punkter, når du beslutter dig for Fortran, C ++ eller Python (eller hvad du vil). Jeg har set 20.000 linjer Fortran i en enkelt fil, økologisk dyrket gennem nogle årtier. Jeg personligt ville ikke bruge andet end isoleret tung array-computing. Ikke engang for noget relateret til output. Indtil videre for en forudindtaget kommentar.
• Jeg kunne ikke ‘ ikke være mere uenig i dette svar. Vores endelige elementkode ville ikke have været muligt at skrive i Fortran. Faktisk startede det for 15 år siden som en blanding af almindelig C og Fortran (sidstnævnte er for de numerisk intensive dele af metoden), og den flyttede gradvist til ren C og derefter til C ++ i løbet af flere år. Koden blev konsekvent kortere, hurtigere og lettere at forstå, og den var mere i stand efter hver iteration. Jeg er enig med andre, der påpeger, at C ++ giver dig masser af reb at skyde dig selv med. Vælg det sprog, du ‘ er mest fortrolig med.
• Bill, brugte du moderne Fortran (90 og senere tilføjelser?). Dette er meget vigtigt (jeg skulle have været mere eksplicit i mit svar om dette). Selvfølgelig er ” 20.000 linjer i Fortran ” eller f77 normalt ikke bedre end velskrevet C ++.
• @ OndřejČert í k: Jeg tror, at hvis du mener, at moderne endelige elementprogrammer bruger ” simpelt ” datastrukturer, så har du ikke ‘ t set på nogen af dem for nylig. Prøv at implementere adaptive endelige elementer, hp-metoder eller multigrid på ustrukturerede masker ved hjælp af enkle datastrukturer. Bill er spot on, og jeg tror, at jeg kan tale for ham ved at sige, at brug af ” moderne Fortran ” næppe ville have gjort mere end en lille forskel.
• @WolfgangBangerth, se for eksempel Phaml ( math.nist.gov/phaml ) for en Fortran-implementering af stort set alt, hvad der du nævnte.

Jeg kaster også mine to cent i slags sent, men jeg ” Jeg har kun lige set denne tråd, og jeg føler, at der for eftertiden er nogle få punkter, der desperat skal fremføres.

Bemærk i det følgende, at jeg vil tale om C og ikke C ++. Hvorfor? Nå, ellers er det æbler og appelsiner at sammenligne et fuldgyldigt dynamisk skrevet objektorienteret sprog med noget så statisk som Fortran. Ja, nogle moderne implementeringer af de nyeste Fortran-standarder kan gøre mere end bare det, men meget få mennesker faktisk Brug dem, og når vi taler om Fortran, tænker vi simpelt, statisk og bydende sprog. Det er her C er, så jeg erstatter C med C ++ for det følgende.

Første af alt, enhver diskussion af Fortran / C, der har bedre kompilatorer, er svær. Dedikeret C / Fortran-compilere hører fortiden til. Både gcc / gfortran og icc / ifc er bare forskellige frontendere til den samme back-end, dvs. dit program vil blive omdannet til en abstrakt beskrivelse af frontend og derefter optimeret og samlet af backend. Hvis du skriver semantisk den samme kode i Fortran eller i C, vil compileren i begge tilfælde producere den samme samling som løber lige så hurtigt.

Dette fører nu til mit andet punkt: hvorfor ser vi stadig forskellen erenser? Problemet er, at de fleste sammenligninger foretages af Fortran-programmører, der prøver noget i C eller omvendt. Har du nogensinde bemærket, hvordan de fleste forfattere eller digtere foretrækker at skrive på deres modersmål? Vil du gerne skrive poesi på et sprog, hvor du ikke føler dig helt selvsikker eller hjemme? Selvfølgelig ikke … Jeg anser selv C for at være mit “indfødte” programmeringssprog. Jeg brugte dog også tre år arbejder i en gruppe, der kun brugte Fortran, hvor jeg har opnået et vist flydende niveau. Jeg ville dog aldrig skrive noget alene i Fortran, da jeg er mere fortrolig med C og som følge heraf den resulterende kode vil være bedre uanset hvad du definerer det som.

Så den største forskel er i programmøren, ikke sproget. Så der er ingen forskelle? Nå, ikke helt. Her er et par eksempler:

• SIMD: Uanset om det er SSE, SSE3 eller AltiVec, hvis du vil bruge dem i Fortran, må du hellere håbe og bede, at kompilatoren gætter nøjagtigt hvad du vil have og gør det så. Held og lykke. I C har du generelt iboende funktioner til hver arkitektur, eller for nylig generelt SIMD-vektortyper i gcc . De fleste Fortran-kompilatorer bruger kun SIMD-instruktioner til at udrulle sløjfer, men hvis du har en kerne, der fungerer på korte vektorer af data på en ikke-indlysende måde, vil compileren meget sandsynligt ikke se den.

• Forskellige hardwarearkitekturer: Hele CUDA-arkitekturen er bygget op omkring kerner i C. Ja, Portland-gruppen har nu en CUDA -capable fortran compiler også, men det er kommercielt, og vigtigst af alt, det er ikke fra NVIDIA. Det samme gælder OpenCL, hvor det bedste, jeg kunne finde, er et nyligt projekt , som kun understøtter et par grundlæggende opkald.

• Parallel programmering: Ja, både MPI og OpenMP fungerer fint med både C og Fortran. Men hvis du vil have reel kontrol over dine tråde, dvs. hvis du har en fuldt dynamisk beregning af delt hukommelse, vil du være ude i kulden med Fortran. I C har du standard pthreads, som, selvom de ikke er varme og uklare, vil får dig stadig igennem stormen. Generelt betjenes de fleste beregninger, der er afhængige af adgang til operativsystemet, f.eks. tråde, processer, filsystem osv … bedre med C. Åh, og prøv ikke at gøre dit eget netværk med Fortran.

• Brugervenlighed: Fortran er tættere på Matlab end C er. Når du først er kommet over alle de forskellige nøgleord og hvordan man deklarerer variabler, ser resten af koden ud som Matlab, hvilket gør den mere tilgængelig for brugere med begrænset programmeringsoplevelse.

• Interoperabilitet: Når du opretter en struktur i C, er layoutet af de aktuelle data ligetil og deterministisk. I Fortran, hvis du bruger markørarrays eller strukturerede data, er det faktiske layout af data stærkt afhængig af kompilatoren, ikke lige- fremad og normalt helt udokumenteret. Du kan ringe til C fra Fortran og omvendt, men tænk ikke, at det kan være lige så let at sende noget mere end et statisk array fra den ene til den anden og tilbage.

Dette er alt sammen noget nørdet, ting på lavt niveau, men dette er High-Performance Computing, vi taler om, ikke? Hvis du ikke er interesseret i, hvordan man bedst udnytter den underliggende hardware paradigmer, dvs. implementering og / eller udvikling af algoritmer, der er bedst til delt / distribueret hukommelse, tråde, SIMD-vektorisering , GPUer, der bruger SIMT og så videre, så laver du bare matematik på en computer.

Dette er blevet meget længere end alt hvad jeg havde med, så her er en oversigt – et sæt tage hjem beskeder af slags:

• Du skriver den bedste kode du kan på det sprog, som du kender bedst.
• Der er ingen forskel i kvaliteten af koden, der produceres af to kompilatorer, der bruger den samme back-end – det er os der skriver dårlig kode på et eller andet sprog.
• På trods af at det føles mere lavt niveau, er Fortran en ret høj abstraktion og vil ikke lade dig få adgang til visse hardware / OS-funktioner direkte, f.eks. SIMD, tråde, netværk osv …

Kommentarer

• Godt svar. Jeg tror ikke ‘ men din endelige kommentar er nødvendigvis sand. Jeg ‘ er selv en C-programmerer, men du får adgang til ting på lavt niveau i Fortran gennem god programmeringspraksis. Den ideelle måde at bruge ting som SIMD ops på er at skrive kode, som stærkt antyder det (for eksempel blokering af sløjfer) og lade kompilatoren gøre det for dig. Til trådning skal du blot bruge openMP (pthreads kan også bruges med noget ekstra arbejde). Fortran har alle de ting, du nævner, det ‘ t, bare på et niveau, der betyder noget for den typiske bruger: numerisk.
• @ Reid.Atcheson: Nå , hvis du blokerer alt sådan, at compileren fanger det, så fungerer det automatisk både i C og i Fortran. Problemet er dog, hvor langt vil du have tillid til din kompilator? Og hvorfor vil du have tillid til det i tilfælde, hvor du ved nøjagtigt hvad du vil have gjort? OpenMP tråder, ja, men blokvis. Du kan narre det til at få forskellige trådpuljer til at gøre forskellige ting, men det er bare misbrug af OpenMP. Pthreads til Fortran er bare indpakninger til C-funktionerne. Jeg er dog enig i, at Fortran er lettere, hvis du ‘ ikke er i detaljerne.
• Sikker på at du ikke er ‘ t kommer til at blive fuldt blæst 99% spidseffektivitet afhængig af compileren, men du kan let komme ret tæt på. Ud over dette skal du enten bruge indre eller indbygget ASM. Du er nødt til at give indrømmelser et eller andet sted for generel programmeringseffektivitet, at ‘ hvorfor programmeringssprog eksisterer i første omgang. På det tidspunkt, hvor du faktisk er sindssyg nok til at komme ind i detaljerne med indre eller ASM (jeg har været et par gange), er Fortran ikke ‘ t en krykke. Du ‘ ved alligevel hvordan du skal linke i din samlede håndoptimerede kode.
• @ Reid.Atcheson: Nå, jeg ‘ d hævder, at for parallelle HPC-applikationer kan du godt ende med at være langt under 99% spidseffektivitet … Og gcc-vektortyperne gør brugen af intrinsics til et ikke-spørgsmål 🙂
• @ Pedro, Strålende post. Helt strålende. Mange tak for indlægget.Fandt det lige, mens jeg tilfældigt rodede gennem interessante tråde.

Fra mine 15 års tænkning om videnskabelig software : Hvis din kode kører 25% hurtigere, fordi du skriver den i Fortran, men det tager dig 4 gange så lang tid at skrive den (ingen STL, svært ved at implementere komplekse datastrukturer osv.), Så vinder Fortran kun, hvis du bruger en betydelig del af din dag snurrer tommelfingre og venter på, at dine beregninger er færdige. I betragtning af at for næsten alle os er den mest værdifulde ting vores egen tid, er konklusionen denne: Brug det sprog, der giver dig mulighed for at udvikle, debugge og teste din kode hurtigst, og med rimelighed ignorere at det kan være langsommere end måske muligt, hvis du skrev det i Fortran.

Min tilgang har været at bruge C ++ til alt andet end beregningskerner, som normalt er bedst skrevet i forsamlingen; dette køber dig al ydeevnen ved den traditionelle HPC-tilgang, men giver dig mulighed for at forenkle grænsefladen, fx ved at overbelaste beregningskerner som SGEMM / DGEMM / CGEMM / ZGEMM i en enkelt rutine, siger Gemm. Det er klart, at abstraktionsniveauet kan hæves meget højere ved at undgå rå pointer og skifte til uigennemsigtige klasser, men det er et godt første skridt.

Jeg finder den største ulempe ved C ++ som overvældende er stigningen i kompileringstid, men efter min erfaring kompenserer besparelserne i udviklingstid mere end det. En anden ulempe er, at leverandør C ++ – kompilatorer har tendens til at have flere fejl end leverandør C og Fortran-kompilatorer. I det forløbne år tror jeg, jeg er stødt på næsten ti bugs i C ++ – kompilatorer.

Med alt dette sagt tror jeg, at fortrydelsen af videnskabelige pakker skrevet på sprog på lavt niveau (og Fortran) er modviljen mod at udsætte praktiske grænseflader til sofistikerede datastrukturer: de fleste mennesker er tilfredse med Fortran BLAS-grænsefladen, da det kun kræver pegepunkter og førende dimensioner for at beskrive matricer, men få mennesker hævder, at den sædvanlige 40-heltal Fortran sparsom-direkte solver-grænseflade er noget tæt på praktisk (jf. UHM, SuperLU, PETSc og Trilinos).

Sammenfattende argumenterer jeg for at bruge samling til beregningskerner på lavt niveau, men sprog på højere niveau til alt andet, især når man arbejder på ikke-trivielle datastrukturer.

Bemærk at dette indlæg resulterede i denne sammenligning af ydeevnen for C og Fortran på kernen $ y: = \ alpha x + y $ .

Kommentarer

• Hvorfor ville ‘ ikke stole på en standard C-kompilator med passende optimering aktiveret til kompilering af små kerner? På dette niveau af kodestørrelse og kompleksitet er forskellen i, hvad en kompilator kunne trække ud af det, uklar.
• Jeg har talt med flere mennesker, der har fortalt mig, at deres Fortran selv med passende begrænsning af brugen var stadig hurtigere end deres C og / eller C ++ kode for nogle operationer som en eksplicit matrix transponere. Jeg ‘ siger ikke, at det ‘ er umuligt at gøre C- eller C ++ -koden så hurtig, men at Fortran-kompilatoren har tendens til at gøre et bedre job.
• Jeg har den samme erfaring med ” begrænser ” nøgleordet (min enkle Fortran-kode var altid lidt hurtigere). Men min ekspertise er begrænset, og jeg har simpelthen ikke ‘ ikke tid til at investere i at forstå den genererede samling fra gcc. Så jeg bruger simpelthen Fortran, det ‘ er simpelt, og det ‘ er hurtigt.
• @JackPoulson: Compileren argument er noget, jeg hører en hel del fra Fortran-samfundet. Desværre er de fleste compilere, f.eks. gcc eller ifc / icc, brug forskellige sprog-frontend til den samme back-end. Maskineriet, der foretager optimering og kodegenerering, er identisk, og forskellene i resultaterne skyldes sandsynligvis forskelle i programmørens fortrolighed med det underliggende sprog …
• Bare for at give lidt perspektiv på det ofte gentagne, sjældent validerede påstand om, at Fortran er hurtigere på numeriske kerner: For længe siden bemærkede vi, at den sparsomme matrixvektor formere sig i Trilinos ‘ Epetra-pakken var 30% langsommere end den i aftalen.II. Førstnævnte blev skrevet i lige frem Fortran 77, sidstnævnte i lige fremad C uden brug af ‘ begræns ‘. Begge havde omkring 10-15 linjer kode. I dag bruger Trilinos det stykke kode, der er hejst fra deal.II. Jeg ‘ er sikker på, at man kan finde mange tilfælde, hvor F77 er hurtigere end C. Pointen er, at det ikke er ‘ t så mere i dag.

Da jeg er ny her, så jeg gennem gamle spørgsmål og fandt denne. Forhåbentlig er det ikke tabu at svare på gamle!

Da ingen andre har nævnt dette, regnede jeg med at gøre det. Fortran 2003 er næsten fuldt ud understøttet af de fleste af de store kompilatorer (intel, ibm, cray, NAG, PCG) endda gcc med (snart kommende) nyeste udgivelse 4.7. Fortran 2003 (og 2008) er et objektorienteret sprog, omend lidt mere detaljeret end C ++. En af de ting, som jeg synes er pænt ved Fortran, er det faktum, at standardkomiteen ser “den videnskabelige databehandling som sin primære målgruppe (jeg takker Damian Rouson for at have påpeget dette for mig den anden dag).

Jeg bringer det hele ikke op, så C ++ – programmører bliver Fortran-programmører, men så Fortran-folk ved, at de nu har flere muligheder udover at skifte til C ++ eller efterligne objektorienterede koncepter i Fortran 90/95.

En advarsel, jeg vil tilføje, er at der er en omkostning ved at være på den blødende kant af, hvad der implementeres i kompilatorerne. Hvis du påtager dig et større projekt i Fortran 2003 lige nu, vil du snuble over fejl og løbende har brug for at opdatere din kompilator (især hvis du bruger gcc), selvom dette er blevet væsentligt bedre de seneste par måneder!

Problemet med C ++ er at du har mange chancer for at ødelægge ydeevnen, for eksempel ved blindt at bruge STL, undtagelser, klasser (virtuel overhead plus alignm ent-problemer), overbelastning af operatører (overflødige nye / sletninger) eller skabeloner (uendelig kompilering og kryptiske fejl synes godartede, men du kan spilde timer på denne måde).

Men mere får du bedre adgang til generelle biblioteker og muligvis synlighed af din kode (selvom dette stærkt afhænger af feltet, og du stadig har ren C). Og du kan stadig kompensere Fortrans manglende fleksibilitet ved at indpakke koden på et script sprog som R, Lush, Matlab / Scilab eller endda Python, Ruby eller Lua.

Kommentarer

• Det er generelt en dårlig idé at anvende teknikker på lavt niveau på sprog på højt niveau. For eksempel er STL designet til at fungere på et meget abstrakt niveau. Man skal være opmærksom på, hvad grænsefladen er er designet til, brug det til denne opgave, og kom derefter ud af compilers måde.
• Jeg tror, at både mbq ‘ s og Martin ‘ s point er uretfærdige. Ja, der er måder at skyde dig selv i foden, hvis du prøver at implementere en numerisk vektor til lineære algebraformål ved hjælp af std :: list < dobbelt >. Men at ‘ er et fjollet argument: mindst C ++ har en sammenkædet listeklasse, som du kan bruge, mens Fortran ikke ‘ t. Det ‘ er som at sige ” Biler kører i så høj hastighed, at du kan kollidere med en mur og komme til skade; du skal bruge hestevogne i stedet. ” Det ‘ er bare en fjollet idé at kaste et sprog på højt niveau, der også understøtter lavt -niveau ting (f.eks. C ++) til at have funktioner på højt niveau.
• @WolfgangBangerth Nej, nu gør du ondt af Fortran – det er som ” lavt niveau ” som bakterier er ” mindre udviklet ” så mennesker . Hvis du vil have en bilanalogi, skal det være mere som “, du kan bruge både Jeep og Lexus til at krydse en sumpet vej, men at bruge den første gør mindre ondt “.
• Jeg sætter pris på din mening, men jeg fastholder, at Fortran ikke er ‘ t så udviklet som C ++ er: -)

Tre fakta:

• F77-stil n-dimensionel arrays i C: Intet problem ved hjælp af CnD (ganske vist et skamløst stik)

• F90 “s modulsystem er dårligt designet og fjendtligt at opbygge miljøer. (Et moduls navn behøver ikke at matche dets filnavn, f.eks.)

• Fortran understøtter ikke refactoring godt. Trækker noget af funktionaliteten ud af en funktion kræver, at du rører ved fire steder: Faktisk kode, variable erklæringer, argumenterklæringer og argumentliste. C kommer forbi med to steder at røre ved. Dette forener effekten af manglen på at administrere data godt (desc ribbet nedenfor): Da småskala modularitet er så smertefuld, skriver næsten alle gigantiske underrutiner.

Et personligt indtryk:

• Fortran fungerer ikke godt til styring af data. Prøv at returnere en markør til en bruger-uigennemsigtig datastruktur i F77 eller F90. (transfer(), her kommer vi)

Kommentarer

• Hej Andreas! CnD er interessant, jeg vidste ikke ‘ om det. Ah, du skrev det. 🙂 (f90 understøtter også udskæring, tildeles til arrays og vigtigst af alt – array-syntaks til multiplikation, tilføjelse og så videre.) Jeg bruger CMake med Fortran, og det fungerer godt sammen med moduler.Hvad er ” argumentlisten “? Jeg tror ikke ‘ at jeg bruger disse, så kun 3 steder er nødvendige for at ændre. I C skal du typisk ændre den faktiske kode, parametre og en headerfil, så den ‘ er også 3 steder (absolut i C ++). Ja, transfer () er ikke ‘ t super flot, men du behøver typisk ikke ‘ det i praksis.
• Refactoring af moderne fortran er trivielt med korrekte IDEer, som Photran i formørkelse.
• ” Et modul ‘ navn behøver ‘ ikke at matche dets filnavn, f.eks. ” Du skal joke, du kan have mange moduler i en fil. Nogle af dem spænder kun over et par linjer. De er meget nemmere at oprette, hvis du ikke behøver at oprette en fil til hver af dem.
• Ville bare føje til, hvad @ user389 sagde, mens Photran er fantastisk og er den eneste Fortran IDE, der tillader refaktorer, dens parser mislykkes hele tiden. På den anden side er der ‘ ikke behov for at kommentere det faktum, at Eclipse er hukommelsessulten.

Fortran er optimeret til array / matrix-beregninger og er en grundig smerte at arbejde med for enhver form for tekstparsing. C og C ++ matcher muligvis ikke Fortran i numerisk databehandling (det er tæt), men jeg finder det meget nemmere at behandle tekst og organisere data (dvs. brugerdefinerede datastrukturer) med C / C ++.

Som andre har nævnt, tæller ikke ud dynamiske fortolkede sprog (Python et al). De tilbyder muligvis ikke Fortans ansigtssmeltningshastighed foran, men de giver dig mulighed for at fokusere mere på at løse dit beregningsproblem end alle detaljer i implementeringen. Ofte kan du implementere en løsning i Python, og hvis ydeevnen er uacceptabel, skal du lave nogle profiler, identificere problemområderne og enten optimere den kode ved hjælp af Cython eller genimplementere hele programmet på et kompileret sprog. Når først problemløsningslogikken er uddybet, er resten bare implementering, og med en god forståelse af computerens grundlæggende skal det være let at repræsentere på alle forskellige programmeringssprog.

Kommentarer

• At ‘ er rigtigt. Til tekstparsing bruger jeg også Python.
• Du kan også implementere en del af et Python-script på et kompileret sprog, f.eks. C ++ og tilslut den. F.eks. Boost Python, Swig osv.

Jeg arbejder i øjeblikket på et af de nationale laboratorier. af folkene omkring mig er mekaniske ingeniører. Chatter med nogle af folkene i HPC-grupperne laver de mest Linux og mest C ++. Den gruppe, jeg er i øjeblikket i, bruger for det meste desktop-applikationer, og vi bruger Windows og i faldende rækkefølge: C #, FORTRAN, Python, VBA og VB (6, ikke .NET). Nogle af simuleringsmotorer , vi bruger, blev skrevet på andre nationale laboratorier i FORTRAN.

Undskyld for at grave op en gammel tråd, men det ser ud til, at selv i 2015 bruges Fortran meget.

Jeg stødte lige på dette (alternativ link ) liste, der grundlæggende er en liste over 13 koder, der er godkendt af DOEs OCLF-facilitet til at køre på 300-petaFLOPS Summit-maskinen, som vil blive gjort tilgængelig for forskere i 2018 Jeg forsøgte at finde det vigtigste sprog, der blev brugt til koden (baseret på en hurtig google-søgning), og her er hvad jeg fandt:

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å ud af 13 mindst 10 (baseret på min hurtige søgning) ser ud til at være skrevet i Fortran. Ikke dårligt for et 50 år gammelt sprog.

BEMÆRK: Jeg er godt klar over, at sprogsammenligninger er ubrugelige, men i betragtning af antallet af folk (specielt C ++ – brugere), der har dårlig mund Fortran, tænkte jeg, at det kunne være værd at nævne det.

Kommentarer

• Jeg er uenig, fordi min erfaring på de nationale laboratorier, hvis noget, har været det modsatte. De fleste af de nye projekter, jeg ser i Lawrence Livermore, er skrevet i C ++, og de fleste af de nye (eller aktivt vedligeholdte) avancerede open source-biblioteker i ODE-løsere, FEM-diskretiseringer og videnskabelige databehandlingsbiblioteker til almindelige formål synes at være i C eller C ++. Fortran synes primært at blive brugt i projekter, der bruger eksisterende / ældre biblioteker; Jeg ser ‘ ikke mange store, nye projekter ved hjælp af Fortran, uafhængigt af hvad jeg synes om sproget.
• Nogle tæthed funktionelle teorikoder også skrevet i Fortran inkluderer VASP og CASTEP , dog som @GeoffOxberry påpeger, ny projekter har måske en tendens til C ++.
• @blochwave Som du kan læse i linket, er projekterne til en ny maskine (med acceleratorer osv.), der vil være online i 2018.Så det er ikke som om de tager en 25-årig kode og kompilerer den i håb om at køre med god præstation. Jeg er helt sikker på, at store dele af koderne i ovenstående liste er eller er blevet omskrevet, som i ny kode. Et antal ” nye ” klimakoder findes også i Fortran og bruges af mange agenturer i en række lande.

Hvad Jack P. jeg tror forsøger at sige er, at du skal blande og matche. Et godt stykke software er omhyggeligt lagdelt. Forskellige lag kan kortlægges mere naturligt eller effektivt til forskellige sprog. Du skal vælge det mest passende sprog for hvert lag. Du skal også forstå, hvordan sprog kan fungere sammen, hvilket kan påvirke hvilket sprog du vælger til hvilket lag.

Et bedre spørgsmål er, hvilke eksempler på fremragende designet software derude, der er værd at studere for at lære om, hvordan man designer lagdelt software.