C ++ vs Fortran för HPC (Svenska)

Som så ofta beror valet på (1) det problem du försöker lösa, (2) färdigheter du har, och (3) personerna du arbetar med (såvida det inte är ett solo-projekt). Jag lämnar (3) åt sidan för tillfället eftersom det beror på allas individuella situation.

Problemberoende: Fortran utmärker sig vid arraybearbetning. Om ditt problem kan beskrivas i termer av enkla datastrukturer och i synnerhet matriser är Fortran väl anpassad. Fortran-programmerare slutar använda matriser även i icke uppenbara fall (t.ex. för att representera grafer). C ++ är bättre lämpad för komplexa och mycket dynamiska datastrukturer.

Skicklighetsberoende: det tar mycket mer programmeringserfarenhet att skriva bra C ++ – program än att skriva bra Fortran – program. Om du börjar med lite program erfarenhet och bara har så mycket tid att lära sig den aspekten av ditt jobb, får du förmodligen en bättre avkastning på investeringen Fortran än att lära dig C ++. Självklart förutsätter jag att ditt problem passar Fortran.

Men det är mer att programmera än bara Fortran och C ++. Jag skulle rekommendera alla som går in i datavetenskap att börja med en dynamisk hög -nivåspråk som Python. Kom alltid ihåg att din tid är mer värdefull än CPU-tid!

Kommentarer

• ” Kom alltid ihåg att din tid är mer värdefull än CPU-tid! ” Som någon som arbetar i HPC håller jag inte med den delen; allt annat är på plats.
• ” Kom alltid ihåg att din tid är mer värdefull än CPU-tid! ” Som någon som arbetar med vetenskaplig forskning, jag kunde inte ’ inte håller mer med den delen.
• ” Kom alltid ihåg att din tid är mer värdefull än CPU-tid! ” – Jag ’ vill kasta in mina 2 cent – med flera hundra noder, vardera med 10+ kärnor för att köra något program i flera veckor kan tolkas som ett hemskt slöseri med en mycket värdefull resurs, om ett par veckor till kan producera en kod som går på bara ett par dagar. Dessa HPC-kluster är en sällsynt och dyr vanlig resurs.
• ” Kom alltid ihåg att din tid är mer värdefull än CPU-tid! ”, kodar i en vecka men kör i en månad, den här ’ är ganska vanligt herr!
• ” Kom alltid ihåg att din tid är mer värdefull än CPU-tid! ”, jag vill hellre koda i en månad och springa på en vecka! – mer kan göras när koden skrivs och andra kommer att hitta koden du skriver också mer användbar.

Jag tycker att både C ++ och Fortran är tillräckligt bra och fungerar bra.

Men jag tycker att Fortran är bättre för numerisk vetenskaplig beräkning, för algoritmer som kan uttryckas med arrays och behöver inte andra sofistikerade datastrukturer, så i fält som ändliga skillnader / element, PDE-lösare, elektroniska strukturberäkningar. Fortran är ett domänspecifikt språk. Jag tror särskilt att det är lättare att skriva snabbt program i Fortran än i C ++, av en forskare (inte nödvändigtvis en datavetenskapsexpert).

C ++ är ett allmänt språk, så man kan uttrycka vilken algoritm som helst i det, och det är definitivt bättre för algoritmer som inte kan uttryckas med hjälp av matriser, från HPC-fältet antagligen några grafer, nätgeneratorer, symbolisk manipulation och så vidare.

Det är också möjligt att skriva arra y-algoritmer i C ++, men enligt min erfarenhet kräver det mycket mer datavetenskaplig kunskap och i allmänhet mer arbete (dvs. man måste skapa eller återanvända klasser för arraymanipulation och hantera minneshantering för hand eller använda något bibliotek som Teuchos från Trilinos). Icke-experter brukar skriva ganska bra Fortran-program, men hemska C ++ – program (talar av min egen erfarenhet).

Ansvarsfriskrivning: Jag gillar Fortran mycket och jag föredrar det framför C ++ för numerisk datoranvändning. Jag har tillbringat mer än 2 år med programmering i C ++ dagligen och nästan ett år programmering i modern Fortran dagligen (i området med begränsade element). Jag använder också Python och Cython mycket.

Kommentarer

• En upp för det första svaret är balanserad. Jag tror att C ++ och Fortran inte är de enda möjligheterna i samtida HPC. Jag tycker att det är bra att känna styrka och svaga punkter när du bestämmer dig för Fortran, C ++ eller Python (eller vad du vill). Jag har sett 20 000 rader Fortran i en enda fil, ekologiskt odlade under några decennier. Jag personligen skulle inte använda något annat än isolerad tung matrisberäkning. Inte ens för någonting relaterat till utdata. Hittills för en partisk kommentar.
• Jag kunde inte ’ inte håller mer med detta svar. Vår finita elementkod skulle inte ha varit möjligt att skriva i Fortran. I själva verket började det för 15 år sedan som en blandning av vanlig C och Fortran (den senare är för de numeriskt intensiva delarna av metoden), och den flyttade gradvis till ren C och sedan till C ++ under flera år. Koden blev genomgående kortare, snabbare och lättare att förstå, och den var mer kapabel efter varje iteration. Jag håller med andra som påpekar att C ++ ger dig mycket rep att skjuta sig med. Välj det språk du ’ är bäst med.
• Bill, använde du modern Fortran (90 och senare tillägg?). Detta är mycket viktigt (jag borde ha varit mer tydlig i mitt svar om detta). Naturligtvis är ” 20.000 rader i Fortran ”, eller f77 vanligtvis inte bättre än välskriven C ++.
• @ OndřejČert í k: Jag tror att om du tror att moderna ändliga elementprogram använder ” enkel ” datastrukturer, då har du ’ inte tittat på någon av dem nyligen. Försök implementera adaptiva ändliga element, hp-metoder eller multigrid på ostrukturerade nät med enkla datastrukturer. Bill är på plats och jag tror att jag kan tala för honom genom att säga att att använda ” modern Fortran ” skulle ha gjort knappt mer än en liten skillnad.
• @WolfgangBangerth, se till exempel Phaml ( math.nist.gov/phaml ) för en Fortran-implementering av i stort sett allt som du nämnde.

Jag kastar också mina två cent i form av sent, men jag ” Jag har just sett den här tråden och jag känner att det för eftervärlden finns några punkter som desperat behöver göras.

Observera i det följande att jag kommer att prata om C och inte C ++. Varför? Tja, annars är det äpplen och apelsiner att jämföra ett fullfjädrat dynamiskt typat objektorienterat språk med något så statiskt som Fortran. Ja, vissa moderna implementeringar av de senaste Fortran-standarderna kan göra mer än bara det, men väldigt få människor faktiskt använd dem, och när vi talar om Fortran, tänker vi enkelt, statiskt och tvingande språk. Det är där C är också, så jag ersätter C med C ++ för följande.

Först av alla, alla diskussioner om Fortran / C med bättre kompilatorer är svåra. Dedikerade C / Fortran-kompilatorer hör till det förflutna. Både gcc / gfortran och icc / ifc är bara olika front-end till samma back-end, dvs ditt program kommer att omvandlas till en abstrakt beskrivning av front-end och sedan optimeras och monteras av back-end. Om du skriver, semantiskt, samma kod i Fortran eller i C, kommer kompilatorn, i båda fallen, att producera samma sammansättning som kommer att gå lika snabbt.

Detta leder nu till min andra punkt: varför ser vi fortfarande skillnad erenser? Problemet är att de flesta jämförelser görs av Fortran-programmerare som försöker något i C eller vice versa. Har du någonsin märkt hur de flesta författare eller poeter föredrar att skriva på sina modersmål? Vill du skriva poesi på ett språk där du inte känner dig helt säker eller hemma? Naturligtvis inte … Jag anser själv att C är mitt ”modersmål” programmeringsspråk. Jag tillbringade dock också tre år arbeta i en grupp som bara använde Fortran, där jag har uppnått en viss flyt. Jag skulle dock aldrig skriva någonting ensam i Fortran eftersom jag är mer bekväm med C och som en följd av den resulterande koden blir bättre , oavsett vad du definierar det som.

Så den största skillnaden är i programmeraren, inte språket. Så det finns inga skillnader? Tja, inte riktigt. Här är några exempel:

• SIMD: Oavsett om det är SSE, SSE3 eller AltiVec, om du vill använda dem i Fortran, hoppas du bättre och ber att kompilatorn gissar exakt vad du vill och gör det så. Lycka till. I C har du i allmänhet inneboende funktioner för varje arkitektur, eller, mer nyligen, allmänna SIMD-vektortyper i gcc . De flesta Fortran-kompilatorer använder bara SIMD-instruktioner för att rulla ut slingor, men om du har en kärna som fungerar på korta vektorer av data på ett icke-självklart sätt kommer kompilatorn med stor sannolikhet inte att se den.

• Olika hårdvaruarkitekturer: Hela CUDA-arkitekturen är uppbyggd kring kärnor i C. Ja, Portland-gruppen har nu en CUDA -capable fortran compiler också, men det är kommersiellt, och viktigast av allt, det kommer inte från NVIDIA. Detsamma gäller OpenCL, för vilket det bästa jag kunde hitta är ett nyligen projekt som bara stöder ett fåtal grundläggande samtal.

• Parallell programmering: Ja, både MPI och OpenMP fungerar bra med både C och Fortran. Men om du vill ha verklig kontroll över dina trådar, dvs. om du har en helt dynamisk delad minnesberäkning, kommer du att vara ute i kylan med Fortran. I C har du de vanliga trådarna som, även om de inte är varma och otydliga, ändå tar dig igenom stormen. I allmänhet betjänas de flesta beräkningar som är beroende av åtkomst till operativsystemet, t.ex. trådar, processer, filsystem osv … med C. Åh, och försök inte göra din egen nätverk med Fortran.

• Användarvänlighet: Fortran är närmare Matlab än C är. När du väl har kommit över alla olika nyckelord och hur man deklarerar variabler ser resten av koden ut som Matlab, vilket gör den mer tillgänglig för användare med begränsad programmeringserfarenhet.

• Driftskompatibilitet: När du skapar en struktur i C är layouten för den faktiska datan rakt fram och deterministisk. I Fortran, om du använder pekmatriser eller strukturerad data, är den faktiska layouten av data starkt beroende av kompilatorn, inte rakt framåt och vanligtvis helt papperslösa. Du kan ringa C från Fortran och tvärtom, men tänk inte på att det kan vara lika lätt att skicka något mer än en statisk matris från det ena till det andra och tillbaka.

Allt detta är lite nördiga saker på låg nivå, men det här är High-Performance Computing som vi pratar om, eller hur? Om du inte är intresserad av hur du bäst utnyttjar den underliggande hårdvaran paradigmer, dvs. implementera och / eller utveckla algoritmer som är bäst för delat / distribuerat minne, trådar, SIMD-vektorisering , GPU: er som använder SIMT och så vidare, då gör du bara matematik på en dator.

Detta har blivit mycket längre än vad jag har med, så här är en sammanfattning – en uppsättning ta hem meddelanden av olika slag:

• Du kommer att skriva den bästa koden du kan på det språk som du känner bäst.
• Det finns ingen skillnad i kvaliteten på koden som produceras av två kompilatorer som använder samma backend – det är oss som skriver dålig kod på ett eller annat språk.
• Trots att man känner sig mer lågnivå, är Fortran en ganska hög abstraktion och låter dig inte komma åt vissa hårdvaru- / OS-funktioner direkt, t.ex. SIMD, trådar, nätverk, etc …

Kommentarer

• Bra svar. Jag tror inte ’ men din slutliga kommentar är nödvändigtvis sant. Jag ’ är själv en C-programmerare, men du får tillgång till saker på låg nivå i Fortran genom bra programmeringsmetoder. Det perfekta sättet att använda saker som SIMD ops är att skriva kod som starkt föreslår det (blockera slingor, till exempel) och låta kompilatorn göra det åt dig. För trådning använder du helt enkelt openMP (pthreads kan också användas med lite extra arbete). Fortran har alla de saker du nämner att den inte ’ t, bara på en nivå som är viktig för dess typiska användare: numerisk.
• @ Reid.Atcheson: Tja , om du blockerar allt så att kompilatorn kommer att fånga det, så fungerar det automatiskt både i C och i Fortran. Problemet är dock hur långt vill du lita på din kompilator? Och varför vill du behöva lita på det i fall där du vet exakt vad du vill göra? OpenMP träder, ja, men blockvis. Du kan lura det för att få olika trådpooler att göra olika saker, men det är bara felaktig användning av OpenMP. Pthreads för Fortran är bara omslag till C-funktionerna. Jag håller dock med om att Fortran är lättare om du ’ inte vill ha detaljerna.
• Visst är du inte ’ t kommer att bli fullblåst 99% toppeffektivitet beroende av kompilatorn, men du kan lätt komma ganska nära. Utöver detta måste du antingen använda inneboende eller inbyggd ASM. Du måste göra eftergifter någonstans för övergripande programmeringseffektivitet, det är ’ varför programmeringsspråk finns i första hand. I det skede att du faktiskt är galen för att komma in i detaljerna med inneboende eller ASM (jag har varit några gånger), är Fortran inte ’ t en krycka. Du ’ vet hur du länkar i din sammansatta handoptimerade kod ändå.
• @ Reid.Atcheson: Jo, jag ’ d argumenterar att för parallella HPC-applikationer kan du mycket väl hamna långt under 99% toppeffektivitet … Och gcc-vektortyperna gör att intrinsics är ett icke-problem 🙂
• @Pedro, Lysande inlägg. Helt briljant. Tack så mycket för inlägget.Hittade precis det medan jag slumpmässigt grumlade i intressanta trådar.

Från mina 15 år av tanke på vetenskaplig programvara : Om din kod går 25% snabbare eftersom du skriver den i Fortran, men det tar dig fyra gånger så lång tid att skriva den (ingen STL, svårigheter att implementera komplexa datastrukturer, etc), så vinner Fortran bara om du spenderar en betydande del av din dag tvinnar tummen och väntar på att dina beräkningar ska avslutas. Med tanke på att för nästan alla av oss är det mest värdefulla vår egen tid, slutsatsen är denna: använd språket som gör att du kan utveckla, felsöka och testa din kod snabbast, med anledning att ignorera att det kan vara långsammare än kanske möjligt om du skrev det i Fortran.

Min inställning har varit att använda C ++ för allt utom beräkningskärnor, som vanligtvis är bäst skrivna i församlingen; detta köper dig all prestanda för det traditionella HPC-tillvägagångssättet men låter dig förenkla gränssnittet, t.ex. genom att överbelasta beräkningskärnor som SGEMM / DGEMM / CGEMM / ZGEMM i en enda rutin, säger Gemm. Uppenbarligen kan abstraktionsnivån höjas mycket högre genom att undvika råa pekare och byta till ogenomskinliga klasser, men det är ett trevligt första steg.

Jag tycker att den största nackdelen med C ++ är överväldigande ökningen av sammanställningstiden, men, enligt min erfarenhet, sparar utvecklingen mer än det. En annan nackdel är att leverantörens C ++ kompilatorer tenderar att ha fler buggar än kompilatorer för leverantör C och Fortran. Under det senaste året tror jag att jag har stött på nästan tio buggar i C ++ – kompilatorer.

Med allt detta sagt tror jag att ångra vetenskapliga paket skrivna på lågnivåspråk (och Fortran) är oviljan att exponera bekväma gränssnitt för sofistikerade datastrukturer: de flesta är nöjda med Fortran BLAS-gränssnittet, eftersom det bara kräver pekare och ledande dimensioner för att beskriva matriser, men få människor hävdar att det vanliga 40-heltalet Fortran gles-direkt-lösningsgränssnitt är något nära bekvämt (jfr. UHM, SuperLU, PETSc och Trilinos).

Sammanfattningsvis argumenterar jag för att använda sammansättning för beräkningskärnor på låg nivå, men språk på högre nivå för allt annat, särskilt när man arbetar på icke-triviala datastrukturer.

Observera att detta inlägg resulterade i denna jämförelse av prestanda för C och Fortran på kärnan $ y: = \ alpha x + y $ .

Kommentarer

• Varför skulle ’ inte lita på en standard C-kompilator med lämplig optimering aktiverad för att kompilera små kärnor? På den nivån av kodstorlek och komplexitet är skillnaden i vad en kompilator kan dra ut ur den oklar.
• Jag har pratat med flera personer som har sagt till mig att Fortran var, även med lämplig begränsning av användningen. fortfarande snabbare än deras C- och / eller C ++ -kod för vissa operationer som en explicit matristransponering. Jag ’ säger inte att det ’ är omöjligt att göra C- eller C ++ -koden lika snabbt, men att Fortran-kompilatorn tenderar att göra ett bättre jobb.
• Jag har samma erfarenhet av ” begränsa ” nyckelordet (min enkla Fortran-kod var alltid lite snabbare). Men min expertis är begränsad och jag har helt enkelt ’ inte tid att investera i att förstå den genererade församlingen från gcc. Så jag använder helt enkelt Fortran, det ’ är enkelt och det ’ är snabbt.
• @JackPoulson: Kompilatorn argument är något jag hör ganska mycket från Fortran-samhället. Tyvärr är de flesta kompilatorer, t.ex. gcc eller ifc / icc, använd olika språkgränssnitt för samma backend. Maskineriet som gör optimeringen och kodgenereringen är identisk och därför beror skillnaderna i resultaten troligen på skillnader i programmerarens bekantskap med det underliggande språket …
• Bara för att ge lite perspektiv på det ofta upprepade, sällan validerade påståendet att Fortran är snabbare på numeriska kärnor: För en stund tillbaka märkte vi att den glesa matrisvektorn förökas i Trilinos ’ Epetra-paketet var 30% långsammare än den i affären. II. Den förstnämnda skrevs i rakt fram Fortran 77, den senare i rakt fram C utan användning av ’ begränsar ’. Båda hade cirka 10-15 rader kod. Idag använder Trilinos koden som hissats från deal.II. Jag ’ är säker på att man kan hitta många fall där F77 är snabbare än C. Poängen är att inte ’ t universellt så mer idag.

Eftersom jag är ny här tittade jag igenom gamla frågor och hittade den här. Förhoppningsvis är det inte tabu att svara på gamla!

Eftersom ingen annan har nämnt detta, tänkte jag att jag skulle. Fortran 2003 stöds nästan fullt av av de flesta av de stora kompilatorerna (intel, ibm, cray, NAG, PCG) till och med gcc med (snart att vara) senaste versionen 4.7. Fortran 2003 (och 2008) är ett objektorienterat språk, om än lite mer ordentligt än C ++. En av saker som jag tycker är trevligt med Fortran är det faktum att standardkommittén ser ”den vetenskapliga databehandlingen som den primära publiken (jag tackar Damian Rouson för att han påpekade för mig häromdagen).

Jag tar upp allt detta inte så att C ++ programmerare blir Fortran-programmerare, utan så att Fortran-människor vet att de har fler alternativ nu förutom att byta till C ++ eller emulera objektorienterade koncept i Fortran 90/95.

En Förbehållet jag vill tillägga är att det är en kostnad att vara på den blödande kanten av vad som implementeras i kompilatorerna. Om du genomför ett större projekt i Fortran 2003 just nu kommer du att snubbla över buggar och kontinuerligt behöver uppdatera din kompilator (särskilt om du använder gcc), men det har blivit betydligt bättre de senaste månaderna!

Problemet med C ++ är att du har många chanser att förstöra prestanda, till exempel genom att blinda använda STL, undantag, klasser (virtuell overhead plus alignm ent-problem), operatörsöverbelastning (redundanta nya / raderade) eller mallar (oändlig kompilering och kryptiska fel verkar godartade, men du kan slösa timmar på detta sätt).

Men mer får du bättre tillgång till allmänna bibliotek och möjligen grater synlighet för din kod (även om detta starkt beror på fältet och du fortfarande har ren C). Och du kan fortfarande kompensera Fortrans brist på flexibilitet genom att lägga in koden på ett skriptspråk som R, Lush, Matlab / Scilab eller till och med Python, Ruby eller Lua.

Kommentarer

• Det är i allmänhet en dålig idé att tillämpa lågnivåtekniker på högnivåspråk. Till exempel är STL utformad för att fungera på en mycket abstrakt nivå. Man måste vara medveten om vad gränssnittet är är designad för, använd den för den här uppgiften och gå sedan ur kompilatorns sätt.
• Jag tror att både mbq ’ s och Martin ’ poäng är orättvisa. Ja, det finns sätt att skjuta sig i foten om du försöker implementera en numerisk vektor för linjära algebra ändamål med std :: list < dubbel >. Men att ’ är ett dumt argument: åtminstone C ++ har en länkad listklass som du kan använda, medan Fortran inte ’ t. Det ’ är som att säga ” Bilar kör i så hög hastighet att du kan krascha in i en vägg och skadas; du bör använda hästvagnar istället. ” Det ’ är bara en dum idé att skräpa ett språk på hög nivå som också stöder låg -nivå saker (t.ex. C ++) för att ha funktioner på hög nivå.
• @WolfgangBangerth Nej, nu skadar du Fortran – det är som ” lågnivå ” eftersom bakterier är ” mindre utvecklade ” sedan människor . Om du vill ha en bilanalogi bör det vara mer som ” du kan använda både Jeep och Lexus för att korsa en sumpig väg, men att använda den första gör mindre ont ”.
• Jag uppskattar din åsikt, men jag hävdar att Fortran inte är ’ t så utvecklat som C ++ är: -)

Tre fakta:

• F77-stil n-dimensionell matriser i C: Inga problem med CnD (en skamlös plugg, visserligen)

• F90 ”s modulsystem är dåligt utformad och fientlig att bygga miljöer. (En moduls namn behöver inte matcha filnamnet, t.ex.)

• Fortran stöder inte refactoring bra. Att dra ut lite funktionalitet för en funktion kräver att du trycker på fyra platser: Faktisk kod, variabla deklarationer, argumentdeklarationer och argumentlista. C klarar sig med två ställen att röra vid. Detta förenar effekten av misslyckandet med att hantera data väl (beskriv ribbad nedan): Eftersom småskalig modularitet är så smärtsam, skriver nästan alla gigantiska underrutiner.

Ett personligt intryck:

• Fortran fungerar inte bra för hantering av data. Försök att returnera en pekare till en användar-ogenomskinlig datastruktur i F77 eller F90. (transfer(), här kommer vi)

Kommentarer

• Hej Andreas! CnD är intressant, jag visste inte ’ om det. Ah, du skrev det. 🙂 (f90 stöder också skivning, kan allokeras för matriser och viktigast av allt – array-syntax för multiplikation, addition och så vidare.) Jag använder CMake med Fortran och det fungerar bra med moduler.Vad är ” argumentlista ”? Jag tror inte ’ att jag använder dessa, så det behövs bara 3 platser för att ändra. I C måste du vanligtvis ändra den faktiska koden, parametrarna och en rubrikfil så att den ’ också är 3 platser (definitivt i C ++). Ja, transfer () är inte ’ t super trevligt, men vanligtvis behöver du inte ’ det i praktiken.
• Refactoring modern fortran är trivial med rätt IDE, som Photran i förmörkelse.
• ” En modul ’ s namn måste ’ inte matcha filnamnet, t.ex. ” Du måste skämta, du kan ha många moduler i en fil. Några av dem sträcker sig bara över ett par rader. De är mycket lättare att skapa om du inte behöver skapa en fil för var och en av dem.
• Ville bara lägga till vad @ user389 sa det, medan Photran är bra och är det enda Fortran IDE som tillåter refaktorer misslyckas dess analysator hela tiden. Å andra sidan finns det ’ inget behov av att kommentera det faktum att Eclipse är minneshungrig.

Fortran är optimerad för array / matrisberäkningar och är en grundlig smärta att arbeta med för alla typer av textparsning. C och C ++ matchar kanske inte Fortran i numerisk beräkning (det är nära), men jag tycker att det är mycket lättare att bearbeta text och organisera data (dvs. anpassade datastrukturer) med C / C ++.

Som andra har nämnt, räknar inte ut dynamiska tolkade språk (Python et al). De kanske inte erbjuder Fortans ansiktssmältningshastighet framåt, men de låter dig fokusera mer på att lösa ditt beräkningsproblem än alla detaljer i implementeringen. Ofta kan du implementera en lösning i Python, och om prestandan är oacceptabel, gör lite profilering, identifiera problemområdena och antingen optimera den koden med Cython eller implementera hela programmet på ett kompilerat språk. När du väl har klargjort problemlösningslogiken är resten bara implementering och med en god förståelse för datagrunderna bör det vara enkelt att representera på alla olika programmeringsspråk.

Kommentarer

• Det ’ är rätt. För textparsning använder jag också Python.
• Du kan också implementera en del av ett Python-skript på ett sammanställt språk, t.ex. C ++ och koppla in den. T ex. Boost Python, Swig etc.

Jag arbetar för närvarande på ett av de nationella laboratorierna. av folket runt mig är mekaniska ingenjörer. Chattar med några av folket i HPC-grupperna, de gör mestadels Linux och mestadels C ++. Gruppen jag är för närvarande i gör mestadels stationära applikationer och vi använder Windows och i fallande ordning: C #, FORTRAN, Python, VBA och VB (6, inte .NET). Några av simuleringsmotorer vi använder skrevs på andra nationella laboratorier i FORTRAN.

Ledsen för att gräva upp en gammal tråd men det verkar som att Fortran redan används mycket 2015.

Jag stötte precis på detta (alternativ länk ) lista som i grunden är en lista med 13 koder som godkänts av DOE: s OCLF-anläggning för att köras på 300-petaFLOPS Summit-maskinen som kommer att göras tillgänglig för forskare 2018 Jag försökte hitta huvudspråket som används för koden (baserat på en snabb google-sökning) och här är vad jag hittade:

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 åtminstone 10 (baserat på min snabba sökning) verkar vara skrivna i Fortran. Inte illa för ett 50 år gammalt språk.

OBS: Jag är väl medveten om att språkjämförelser är värdelösa men med tanke på antalet människor (speciellt C ++ -användare) som dålig mun Fortran, tänkte jag att det kan vara värt att nämna det.

Kommentarer

• Jag håller inte med, för min erfarenhet vid de nationella laboratorierna har, om något, varit motsatt. De flesta av de nya projekten jag ser på Lawrence Livermore är skrivna i C ++, och de flesta av de nya (eller aktivt underhållna) toppmoderna open source-biblioteken i ODE-lösare, FEM-diskretiseringar och allmänna vetenskapliga databibliotek verkar vara i C eller C ++. Fortran verkar främst användas i projekt som använder befintliga / äldre bibliotek; Jag ser ’ inte många stora, nya projekt som använder Fortran, oberoende av vad jag tycker om språket.
• Vissa densitetsfunktionella teorikoder är också skrivna i Fortran inkluderar VASP och CASTEP , men som @GeoffOxberry påpekar, ny -projekt tenderar kanske mot C ++.
• @blochwave Som du kan läsa i länken är projekten för en ny maskin (med acceleratorer etc.) som kommer att vara online 2018.Så det är inte som att de tar en 25-årskod och sammanställer den, i hopp om att köra med bra resultat. Jag är helt säker på att stora delar av koderna i listan ovan har skrivits om eller skrivits om, som i ny kod. Ett antal ” nya ” klimatkoder finns också i Fortran och används av många myndigheter i ett antal länder.

Vad Jack P. jag tror försöker säga är att du ska mixa och matcha. En bra mjukvara är noggrant lagrad. Olika lager kan kartläggas mer naturligt eller effektivt till olika språk. Du bör välja det språk som passar bäst för varje lager. Du bör också förstå hur språk kan fungera, vilket kan påverka vilket språk du väljer för vilket lager.

En bättre fråga är vilka exempel på utmärkt designad programvara som finns där som är värda att studera för att lära sig hur man utformar lagerprogramvara.