C ++ vs Fortran voor HPC

Zoals zo vaak hangt de keuze af van (1) het probleem dat u probeert op te lossen, (2) het vaardigheden die je hebt, en (3) de mensen met wie je werkt (tenzij het een soloproject is). Ik laat (3) even terzijde omdat het afhangt van ieders individuele situatie.

Probleemafhankelijkheid: Fortran blinkt uit in array-verwerking. Als uw probleem kan worden beschreven in termen van eenvoudige datastructuren en in het bijzonder arrays, is Fortran goed aangepast. Fortran-programmeurs gebruiken arrays, zelfs in niet voor de hand liggende gevallen (bijvoorbeeld voor het weergeven van grafieken). C ++ is beter geschikt voor complexe en zeer dynamische datastructuren.

Vaardigheidsafhankelijkheid: er is veel meer programmeerervaring nodig om goede C ++ -programmas te schrijven dan om goede Fortran-programmas te schrijven. Als je begint met weinig programma Als u ervaring heeft en maar zo veel tijd hebt om dat aspect van uw baan te leren, krijgt u waarschijnlijk een beter rendement op uw investering door Fortran te leren dan door C ++ te leren. Ervan uitgaande, natuurlijk, dat uw probleem geschikt is voor Fortran.

Programmeren is echter meer dan alleen Fortran en C ++. Ik zou iedereen die in computerwetenschap gaat aanraden om te beginnen met een dynamische high -level taal zoals Python. Onthoud altijd dat uw tijd waardevoller is dan CPU-tijd!

Opmerkingen

• ” Onthoud dat altijd uw tijd is waardevoller dan CPU-tijd! ” Als iemand die in HPC werkt, ben ik het daar niet mee eens; al het andere is perfect.
• ” Onthoud altijd dat uw tijd waardevoller is dan CPU-tijd! ” Zoals iemand die in wetenschappelijk onderzoek werkt, kon ik ‘ niet meer akkoord gaan met dat deel.
• ” Onthoud dat altijd uw tijd is waardevoller dan CPU-tijd! ” – Ik ‘ zou graag mijn 2 cent erin willen gooien – met behulp van honderden knooppunten, elk met meer dan 10 cores om een programma gedurende meerdere weken uit te voeren, kan dit worden opgevat als een vreselijke verspilling van een kostbaarste bron, als een paar weken een code zou kunnen produceren die in slechts een paar dagen werkt. Die HPC-clusters zijn een zeldzame en dure algemene bron.
• ” Onthoud altijd dat uw tijd waardevoller is dan CPU-tijd! “, code voor een week maar draaien voor een maand, dit ‘ is heel gewoon meneer!
• ” Onthoud altijd dat uw tijd waardevoller is dan CPU-tijd! “, ik zou liever programmeren voor een maand en binnen een week draaien! – er kan meer worden gedaan als de code eenmaal is geschreven en anderen zullen de code die u schrijft ook nuttiger vinden.

Ik denk dat zowel C ++ als Fortran goed genoeg zijn en goed werken.

Ik denk echter dat Fortran beter is voor numeriek wetenschappelijk computergebruik, voor algoritmen die kunnen worden uitgedrukt met arrays en hebben geen andere geavanceerde datastructuren nodig, dus in velden zoals eindige verschillen / elementen, PDE-oplossers, elektronische structuurberekeningen. Fortran is een domeinspecifieke taal. In het bijzonder denk ik dat het gemakkelijker is om snel programmas in Fortran dan in C ++, door een wetenschapper (niet noodzakelijk een computerwetenschapper).

C ++ is een taal voor algemene doeleinden, dus men kan er elk algoritme in uitdrukken, en het is zeker beter voor algoritmen die “niet kunnen worden uitgedrukt met behulp van arrays, uit het HPC-veld waarschijnlijk enkele grafieken, mesh-generatoren, symbolische manipulatie enzovoort.

Het is ook mogelijk om arra te schrijven y-algoritmen in C ++, maar in mijn ervaring vereist het veel meer computerwetenschappelijke kennis en in het algemeen meer werk (d.w.z. men moet klassen maken of hergebruiken voor array-manipulatie, en geheugenbeheer met de hand afhandelen of een bibliotheek zoals Teuchos van Trilinos gebruiken). Niet-experts hebben de neiging om redelijk goede Fortran-programmas te schrijven, maar vreselijke C ++ -programmas (sprekend vanuit mijn eigen ervaring).

Disclaimer: Ik vind Fortran persoonlijk erg leuk en ik geef er de voorkeur aan boven C ++ voor numeriek computergebruik. Ik heb dagelijks meer dan 2 jaar in C ++ geprogrammeerd, en bijna een jaar dagelijks in het moderne Fortran (op het gebied van eindige elementen). Ik gebruik Python en Cython ook veel.

Reacties

• Een voor het eerste antwoord is evenwichtig. Ik denk dat C ++ en Fortran verreweg niet de enige mogelijkheden zijn in de hedendaagse HPC. Ik denk dat het goed is om de sterke en zwakke plekken te kennen wanneer je kiest voor Fortran, C ++ of Python (of wat je maar wilt). Ik heb 20.000 regels Fortran in één enkel bestand gezien, organisch gegroeid gedurende enkele decennia. Ik zou persoonlijk niets anders gebruiken dan geïsoleerde zware array-computing. Zelfs niet voor iets dat met output te maken heeft. Tot zover een bevooroordeelde opmerking.
• Ik kon ‘ niet meer oneens zijn met deze reactie. Onze eindige-elementencode zou niet in Fortran kunnen worden geschreven. In feite begon het 15 jaar geleden als een mix van gewone C en Fortran (de laatste is voor de numeriek intensieve delen van de methode), en het ging geleidelijk over naar pure C en vervolgens naar C ++ in de loop van enkele jaren. De code werd consequent korter, sneller en gemakkelijker te begrijpen, en was beter in staat na elke iteratie. Ik ben het eens met anderen die erop wijzen dat C ++ je genoeg touw geeft om jezelf mee te schieten. Kies de taal waarmee je ‘ het meest vertrouwd bent.
• Bill, heb je het moderne Fortran gebruikt (90 en latere toevoegingen?). Dit is erg belangrijk (ik had hierover explicieter moeten zijn in mijn antwoord). Natuurlijk, ” 20.000 regels Fortran “, of f77 is meestal niet beter dan goed geschreven C ++.
• @ OndřejČert í k: ik denk dat als je gelooft dat moderne eindige-elementenprogrammas ” eenvoudig ” datastructuren, dan heb je ‘ niet onlangs naar een van deze structuren gekeken. Probeer adaptieve eindige elementen, hp-methoden of multigrid te implementeren op ongestructureerde meshes met behulp van eenvoudige gegevensstructuren. Bill is perfect en ik denk dat ik voor hem kan spreken door te zeggen dat het gebruik van ” moderne Fortran ” nauwelijks meer zou hebben opgeleverd dan een kleine verschil.
• @WolfgangBangerth, zie bijvoorbeeld Phaml ( math.nist.gov/phaml ) voor een Fortran-implementatie van vrijwel alles dat je noemde.

Ik “gooi ook mijn twee cent een beetje laat in, maar ik” ik heb deze thread nog maar net gezien en ik heb het gevoel dat er voor het nageslacht een paar punten zijn die dringend moeten worden gemaakt.

Merk in het volgende op dat ik het zal hebben over C en niet over C ++. Waarom? Nou, anders zijn het appels en peren om een volwaardige, dynamisch getypeerde objectgeoriënteerde taal te vergelijken met zoiets statisch als Fortran. Ja, sommige moderne implementaties van de nieuwste Fortran-standaarden kunnen meer dan dat, maar eigenlijk zijn er maar heel weinig mensen gebruiken ze, en dus als we het hebben over Fortran, denken we aan simpele, statische en imperatieve taal. Dat is waar C ook is, dus ik zal C vervangen door C ++ voor het volgende.

Ten eerste allemaal, elke discussie over het hebben van betere compilers voor Fortran / C is betwistbaar. Dedicated C / Fortran-compilers behoren tot het verleden. Zowel gcc / gfortran als icc / ifc zijn gewoon verschillende front-ends voor dezelfde back-end, dat wil zeggen uw programma wordt door de front-end omgezet in een abstracte beschrijving en vervolgens geoptimaliseerd en geassembleerd door de back-end. Als u semantisch dezelfde code in Fortran of in C schrijft, produceert de compiler in beide gevallen dezelfde assembly die net zo snel zal lopen.

Dit leidt nu tot mijn tweede punt: waarom zien we nog steeds diff erences? Het probleem is dat de meeste vergelijkingen worden gemaakt door Fortran-programmeurs die iets in C proberen of vice versa. Ooit opgevallen hoe de meeste schrijvers of dichters het liefst in hun moedertaal schrijven? Zou je poëzie willen schrijven in een taal waarin je je niet helemaal zelfverzekerd voelt of thuis bent? Natuurlijk niet … Ik beschouw C zelf als mijn moedertaal programmeertaal. Ik heb echter ook drie jaar doorgebracht werken in een groep die alleen Fortran gebruikte, waarin ik een bepaald niveau van spreekvaardigheid heb bereikt. Ik zou echter nooit zelf iets schrijven in Fortran, omdat ik meer op mijn gemak ben met C en, als gevolg daarvan, de resulterende code zal beter zijn, hoe je dat ook definieert.

Dus het belangrijkste verschil zit in de programmeur, niet in de taal. Er zijn dus geen verschillen? Nou, niet helemaal. Hier zijn een paar voorbeelden:

• SIMD: Of het nu SSE, SSE3 of AltiVec is, als je ze in Fortran wilt gebruiken, kun je maar beter hopen en bidden dat de compiler raadt precies wat je wilt en doet het. Veel succes. In C heb je over het algemeen intrinsieke functies voor elke architectuur, of, recenter, algemene SIMD-vectortypen in gcc De meeste Fortran-compilers zullen alleen SIMD-instructies gebruiken om loops uit te rollen, maar als je een kernel hebt die op een niet voor de hand liggende manier op korte gegevensvectoren werkt, zal de compiler deze waarschijnlijk niet zien.

• Verschillende hardware-architecturen: de hele CUDA-architectuur is gebouwd rond kernels in C. Ja, de Portland Group heeft nu een CUDA -capabele fortran-compiler ook, maar het is commercieel, en vooral niet van NVIDIA. Hetzelfde geldt voor OpenCL, waarvoor het beste dat ik kon vinden een recent project is dat slechts een paar basisaanroepen ondersteunt.

• Parallel programmeren: Ja, zowel MPI als OpenMP werken prima met zowel C als Fortran. Als je echter echte controle over je threads wilt, dwz als je een volledig dynamische berekening hebt met gedeeld geheugen, sta je in de kou met Fortran. In C heb je de standaard pthreads die, hoewel niet warm en wazig, wel helpen je nog steeds door de storm heen. In het algemeen zijn de meeste berekeningen die afhankelijk zijn van toegang tot het besturingssysteem, bijv. threads, processen, bestandssysteem, enz … beter gediend met C. Oh, en probeer niet je eigen netwerken met Fortran.

• Gebruiksgemak: Fortran is dichter bij Matlab dan C. Als je eenmaal alle verschillende trefwoorden hebt doorgenomen en hoe je variabelen moet declareren, ziet de rest van de code eruit als Matlab, waardoor het toegankelijker wordt voor gebruikers met beperkte programmeerervaring.

• Interoperabiliteit: wanneer u een structuur maakt in C, is de lay-out van de feitelijke gegevens rechttoe rechtaan en deterministisch. Als u in Fortran pointer-arrays of gestructureerde gegevens gebruikt, is de feitelijke lay-out van de gegevens sterk afhankelijk van de compiler, niet rechtlijnig. doorsturen, en meestal volledig ongedocumenteerd. Je kunt C bellen vanuit Fortran en vice versa, maar begin niet te denken dat het misschien net zo gemakkelijk is om meer dan een statische array van de ene naar de andere en terug te sturen.

Dit zijn allemaal ietwat nerds, low-level dingen, maar dit is High-Performance Computing waar we het over hebben, toch? Als je niet geïnteresseerd bent in hoe je de onderliggende hardware het beste kunt exploiteren paradigmas, dwz het implementeren en / of ontwikkelen van algoritmen die het beste zijn voor gedeeld / gedistribueerd geheugen, threads, SIMD-vectorisatie , GPUs die SIMT gebruiken, enzovoort, dan doe je gewoon wiskunde op een computer.

Dit is veel langer geworden dan alles wat ik bedoelde, dus hier is een samenvatting – een set om mee naar huis te nemen berichten van soorten:

• Je schrijft de beste code jij kunt in de taal die jij het beste kent.
• Er is geen verschil in de kwaliteit van de code die wordt geproduceerd door twee compilers die dezelfde back-end gebruiken – het zijn wij die slechte code in een of andere taal schrijven.
• Ondanks dat het gevoel meer laag is, is Fortran een abstractie van vrij hoog niveau en geeft het je geen directe toegang tot bepaalde hardware / OS-functies, bijv. SIMD, discussies, netwerken, enz …

Reacties

• Goede reactie. Ik denk niet dat ‘ niettemin uw laatste opmerking per se waar is. Ik ‘ ben zelf een C-programmeur, maar je krijgt toegang tot dingen op laag niveau in Fortran door goede programmeerpraktijken. De ideale manier om zaken als SIMD ops te gebruiken, is door code te schrijven die dit sterk suggereert (bijvoorbeeld door lussen te blokkeren) en de compiler het voor je te laten doen. Gebruik voor het inrijgen gewoon openMP (pthreads is ook bruikbaar met wat extra werk). Fortran heeft alle dingen die je noemt niet ‘ t, alleen op een niveau dat belangrijk is voor de typische gebruiker: numeriek.
• @ Reid.Atcheson: Nou , als je alles blokkeert zodat de compiler het opvangt, dan zal het automagisch werken, zowel in C als in Fortran. Het probleem is echter: in hoeverre wilt u uw compiler vertrouwen? En waarom wil je erop vertrouwen in gevallen waarin je precies weet wat je gedaan wilt hebben? OpenMP voert threading, ja, maar bloksgewijs. Je kunt het misleiden om verschillende threadpools te krijgen om verschillende dingen te doen, maar dat is gewoon een verkeerd gebruik van OpenMP. Pthreads voor Fortran zijn slechts wrappers voor de C-functies. Ik ben het er echter mee eens dat Fortran gemakkelijker is als je ‘ niet op de details ingaat.
• Natuurlijk ben je ‘ Het gaat niet om een volledig piekrendement van 99% te vertrouwen op de compiler, maar je kunt gemakkelijk heel dichtbij komen. Daarnaast moet u ofwel intrinsieke ofwel inline ASM gebruiken. Je moet ergens concessies doen voor de algehele efficiëntie van de programmeur, dat ‘ s waarom programmeertalen in de eerste plaats bestaan. In het stadium dat je echt gek genoeg bent om in de details van intrinsieke zaken of ASM te komen (ik ben er een paar keer geweest), is Fortran geen ‘ een kruk. U ‘ zou toch al weten hoe u uw samengestelde, met de hand geoptimaliseerde code moet koppelen.
• @ Reid.Atcheson: Nou, ik ‘ d argumenteren dat je voor parallelle HPC-applicaties misschien ver onder de 99% piekefficiëntie uitkomt … En de gcc-vectortypen maken het gebruik van intrinsiek een non-issue 🙂
• @Pedro, Briljante post. Absoluut fantastisch. Heel erg bedankt voor het posten.Ik heb het net gevonden terwijl ik willekeurig door interessante discussies snuffelde.

Van mijn 15 jaar denken over wetenschappelijke software : Als je code 25% sneller werkt omdat je hem in Fortran schrijft, maar het duurt 4 keer zo lang om hem te schrijven (geen STL, moeilijkheid om complexe datastructuren te implementeren, enz.), Dan wint Fortran alleen als je een aanzienlijk deel van de je dag duimen duimen en wachten tot je berekeningen zijn voltooid. Gezien het feit dat voor bijna iedereen het meest waardevolle ding onze eigen tijd is, is de conclusie deze: gebruik de taal waarmee u uw code het snelst kunt ontwikkelen, debuggen en testen, zonder redelijkerwijs te negeren dat het langzamer kan zijn dan misschien mogelijk is als je hebt het in Fortran geschreven.

Mijn benadering was om C ++ te gebruiken voor alles behalve computationele kernels, die meestal het beste zijn geschreven in montage; hiermee koop je alle prestaties van de traditionele HPC-benadering, maar kun je de interface vereenvoudigen, bijvoorbeeld door computationele kernels zoals SGEMM / DGEMM / CGEMM / ZGEMM in een enkele routine te overbelasten, bijvoorbeeld Gemm. Het is duidelijk dat het abstractieniveau veel hoger kan worden door onbewerkte verwijzingen te vermijden en over te schakelen naar ondoorzichtige klassen, maar het is een mooie eerste stap.

Ik vind het grootste nadeel van C ++ dat overweldigend de toename in compilatietijd is, maar, in mijn ervaring, maken de besparingen in ontwikkeltijd dit meer dan goed. Een ander nadeel is dat Vendor C ++ compilers meer bugs hebben dan Vendor C en Fortran compilers. In het afgelopen jaar denk ik dat ik bijna tien bugs ben tegengekomen in C ++ -compilers.

Met dat alles gezegd, denk ik dat het ongedaan maken van wetenschappelijke pakketten geschreven in talen op een laag niveau (en Fortran) is de terughoudendheid om handige interfaces voor geavanceerde datastructuren bloot te leggen: de meeste mensen zijn tevreden met de Fortran BLAS-interface, omdat het alleen pointers en leidende dimensies nodig heeft om matrices te beschrijven, maar weinig mensen zouden beweren dat de gebruikelijke 40-integer Fortran sparse-direct solver-interface is alles wat handig is (cf. UHM, SuperLU, PETSc en Trilinos).

Samenvattend pleit ik ervoor om assembly te gebruiken voor computationele kernels op laag niveau, maar talen van hoger niveau voor al het andere, vooral wanneer je werkt met niet-triviale datastructuren.

Merk op dat dit post resulteerde in deze vergelijking van de prestaties van C en Fortran op de kernel $ y: = \ alpha x + y $ .

Opmerkingen

• Waarom zou je niet ‘ een standaard C-compiler vertrouwen met de juiste optimalisatie ingeschakeld voor het compileren van kleine kernels? Op dat niveau van codegrootte en complexiteit is het verschil in wat een compiler eruit zou kunnen halen onduidelijk.
• Ik heb met verschillende mensen gesproken die me vertelden dat hun Fortran, zelfs met een gepast beperkt gebruik, nog steeds sneller dan hun C- en / of C ++ – code voor een bewerking zoals een expliciete matrixtranspose. Ik ‘ m zeg niet dat het ‘ s onmogelijk is om de C- of C ++ -code zo snel te maken, maar dat de Fortran-compiler dat wel doet een betere baan.
• Ik heb dezelfde ervaring met het ” restrict ” trefwoord (mijn eenvoudige Fortran-code was altijd een beetje sneller). Maar mijn expertise is beperkt, en ik heb ‘ gewoon geen tijd om te investeren in het begrijpen van de gegenereerde assembly van gcc. Dus ik gebruik gewoon Fortran, het ‘ is eenvoudig en het ‘ is snel.
• @JackPoulson: de compiler argument hoor ik nogal eens van de Fortran-gemeenschap. Helaas zijn de meeste compilers, b.v. gcc of ifc / icc, gebruik verschillende taal front-ends voor dezelfde back-end. De machine die de optimalisatie uitvoert en de code genereert, is identiek en daarom zijn de verschillen in de resultaten hoogstwaarschijnlijk te wijten aan verschillen in de bekendheid van de programmeur met de onderliggende taal …
• Om een beetje perspectief te geven over de vaak herhaalde, zelden gevalideerde bewering dat Fortran sneller is met numerieke kernels: een tijdje geleden merkten we dat de schaarse matrix-vector vermenigvuldiging in Trilinos ‘ Epetra-pakket 30% langzamer was dan degene in deal II. De eerste is geschreven in rechttoe rechtaan Fortran 77, de laatste in rechttoe rechtaan C zonder het gebruik van ‘ restrict ‘. Beiden hadden ongeveer 10-15 regels code. Tegenwoordig gebruikt Trilinos het stukje code dat uit de deal is gehesen.II. Ik ‘ weet zeker dat je veel gevallen kunt vinden waarin F77 sneller is dan C. Het punt is dat het niet ‘ universeel is, dus niet meer vandaag.

Aangezien ik hier nieuw ben, heb ik oude vragen doorgenomen en deze gevonden. Hopelijk is het geen taboe om oude te beantwoorden!

Aangezien niemand anders dit heeft genoemd, dacht ik dat ik het zou doen. Fortran 2003 wordt bijna volledig ondersteund door de meeste grote compilers (intel, ibm, cray, NAG, PCG) zelfs gcc met de (binnenkort te verschijnen) nieuwste release 4.7. Fortran 2003 (en 2008) is een objectgeoriënteerde taal, zij het iets meer uitgebreid dan C ++. Een van de dingen die ik leuk vind aan Fortran is het feit dat de standaardcommissie ‘wetenschappelijk computergebruik als het belangrijkste publiek’ beschouwt (ik bedank Damian Rouson dat hij me hier onlangs op heeft gewezen).

Ik breng dit allemaal naar voren, niet zodat C ++ programmeurs Fortran-programmeurs worden, maar zodat Fortran-mensen weten dat ze nu meer opties hebben naast het overschakelen naar C ++ of het emuleren van objectgeoriënteerde concepten in Fortran 90/95.

Een voorbehoud dat ik zal toevoegen, is dat er kosten zijn verbonden aan het op de voet volgen van wat er in de compilers is geïmplementeerd. Als u op dit moment een groot project in Fortran 2003 uitvoert, zult u bugs tegenkomen en moet u uw compiler voortdurend bijwerken (vooral als je gcc gebruikt), hoewel dit de afgelopen maanden aanzienlijk beter is geworden!

Het probleem met C ++ is dat je tal van kansen hebt om prestaties te verpesten, bijvoorbeeld door blindelings STL te gebruiken, uitzonderingen, klassen (virtuele overhead plus alignm ent problemen), operatoroverbelasting (overtollige nieuwe / verwijderde) of sjablonen (oneindige compilatie en cryptische fouten lijken goedaardig, maar je kunt op deze manier uren verspillen).

Meer krijg je echter een betere toegang tot algemene bibliotheken en mogelijk een grotere zichtbaarheid van je code (hoewel dit sterk afhankelijk is van het veld, en je nog steeds pure C hebt). En je kunt het gebrek aan flexibiliteit van de Fortran nog steeds compenseren door de code in een scripttaal te plaatsen zoals R, Lush, Matlab / Scilab of zelfs Python, Ruby of Lua.

Opmerkingen

• Het is over het algemeen een slecht idee om low-level technieken toe te passen in high-level talen. De STL is bijvoorbeeld ontworpen om op een zeer abstract niveau te werken. Men moet weten wat de interface is ontworpen voor, gebruik het voor deze taak en ga dan uit de weg van de compilers.
• Ik denk dat zowel mbq ‘ s en Martin ‘ s punten zijn oneerlijk. Ja, er zijn manieren om jezelf in de voet te schieten als je een numerieke vector probeert te implementeren voor lineaire algebra-doeleinden met std :: list < dubbel >. Maar dat ‘ is een dom argument: tenminste C ++ heeft een gekoppelde lijstklasse kan gebruiken, terwijl Fortran niet ‘ t. Het ‘ is als zeggen ” Autos rijden met zon hoge snelheid dat u tegen een muur kunt botsen en daarbij gewond kunt raken; gebruik in plaats daarvan paardenkoetsen. ” Het ‘ is gewoon een dom idee om een taal op hoog niveau te verwijderen die ook lage -level dingen (bijv. C ++) voor hebben high-level features.
• @WolfgangBangerth Nee, nu doe je Fortran pijn – het is als ” low-level ” aangezien bacteriën ” minder ontwikkeld ” dan mensen zijn . Als je een auto-analogie wilt, zou het meer moeten zijn als ” je kunt zowel Jeep als Lexus gebruiken om een moerassige zijweg over te steken, maar de eerste gebruiken doet minder pijn “.
• Ik stel uw mening op prijs, maar ik blijf erbij dat Fortran niet ‘ zo geëvolueerd is als C ++ is: -)

Drie feiten:

• F77-stijl n-dimensionaal arrays in C: geen probleem met CnD (een schaamteloze plug, toegegeven)

• F90s modulesysteem is slecht ontworpen en vijandig om omgevingen te bouwen. (De naam van een module hoeft niet overeen te komen met de bestandsnaam, bijvoorbeeld)

• Fortran ondersteunt refactoring niet goed. Een stukje functionaliteit eruit halen van een functie vereist dat u vier plaatsen aanraakt: werkelijke code, variabeledeclaraties, argumentdeclaraties en argumentlijst. C komt langs met twee plaatsen om aan te raken. Dit vergroot het effect van het niet goed beheren van gegevens (beschr. hieronder geribbeld): aangezien kleinschalige modulariteit zo pijnlijk is, schrijft zowat iedereen gigantische subroutines.

Een persoonlijke indruk:

• Fortran werkt niet goed voor het beheren van gegevens. Probeer een pointer te retourneren naar een voor de gebruiker ondoorzichtige gegevensstructuur in F77 of F90. (transfer(), hier komen we)

Reacties

• Hallo Andreas! CnD is interessant, ik wist het niet ‘. Ah, je hebt het geschreven. 🙂 (f90 ondersteunt ook slicing, toewijsbaar voor arrays en vooral – array-syntaxis voor vermenigvuldigen, optellen enzovoort.) Ik gebruik CMake met Fortran en het werkt uitstekend met modules.Wat is precies ” argumentlijst “? Ik denk niet dat ik deze ‘ niet gebruik, dus er zijn maar 3 plaatsen nodig om aan te passen. In C moet je normaal gesproken de eigenlijke code, parameters en een header-bestand wijzigen, dus het ‘ bevat ook 3 plaatsen (zeker in C ++). Ja, transfer () is niet ‘ t super leuk, maar meestal heb je ‘ het in de praktijk niet nodig.
• Het herstructureren van moderne fortran is triviaal met de juiste IDEs, zoals Photran in eclipse.
• ” Een module ‘ s naam doesn ‘ t hoeft niet overeen te komen met de bestandsnaam, bijv. ” Je maakt een grapje, je kunt veel modules in één bestand hebben. Sommige beslaan slechts een paar regels. Ze zijn veel gemakkelijker te maken als je niet voor elk ervan een bestand hoeft aan te maken.
• Ik wilde gewoon iets toevoegen aan wat @ user389 zei dat, hoewel Photran geweldig is en de enige Fortran IDE is die het toestaat refactorings, de parser mislukt de hele tijd. Aan de andere kant is er ‘ s geen reden om commentaar te geven op het feit dat Eclipse geheugen-honger heeft.

Fortran is geoptimaliseerd voor array- / matrixberekeningen en het is erg lastig om mee te werken voor elk type tekstparsing. C en C ++ komen mogelijk niet overeen met Fortran in numeriek computergebruik (het komt in de buurt), maar ik vind het veel gemakkelijker om tekst te verwerken en gegevens (dwz aangepaste gegevensstructuren) te organiseren met C / C ++.

Als anderen hebben gezegd, tel dynamisch geïnterpreteerde talen niet mee (Python et al). Ze bieden misschien niet de gezichtssmeltende snelheid van Fortan van tevoren, maar ze stellen je in staat om je meer te concentreren op het oplossen van je computerprobleem dan op alle details van de implementatie. Vaak kun je een oplossing in Python implementeren en als de prestaties onaanvaardbaar zijn, kun je wat profilering doen, de probleemgebieden identificeren en die code optimaliseren met Cython of het hele programma opnieuw implementeren in een gecompileerde taal. Als je eenmaal de probleemoplossende logica hebt uitgewerkt, is de rest slechts implementatie en moet, met een goed begrip van de basisprincipes van computers, eenvoudig te vertegenwoordigen zijn in elke verscheidenheid aan programmeertalen.

Opmerkingen

• Dat ‘ klopt. Voor het parseren van tekst gebruik ik ook Python.
• Je kunt ook een deel van een Python-script implementeren in een gecompileerde taal, bijvoorbeeld C ++ en sluit het aan. Bijv. Boost Python, Swig etc.

Ik werk momenteel in een van de nationale labs. van de mensen om me heen zijn werktuigbouwkundigen. Ze chatten met enkele van de mensen in de HPC-groepen, ze doen voornamelijk Linux en meestal C ++. De groep waar ik momenteel in zit, doet voornamelijk desktop-applicaties en we gebruiken Windows en in aflopende volgorde: C #, FORTRAN, Python, VBA en VB (6, niet .NET). Sommige van de simulatie engines die we gebruiken, zijn geschreven in andere nationale labs in FORTRAN.

Sorry voor het opgraven een oude thread, maar het lijkt erop dat Fortran zelfs in 2015 veel wordt gebruikt.

Ik kwam net this (alternate link ) lijst die in feite een lijst is van 13 codes die zijn goedgekeurd door de OCLF-faciliteit van DOE om te draaien op de 300-petaFLOPS Summit-machine die in 2018 beschikbaar zal worden gemaakt voor onderzoekers . Ik heb geprobeerd de hoofdtaal te vinden die voor de code wordt gebruikt (op basis van een snelle Google-zoekopdracht) en dit is wat ik vond:

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 

Dus van de 13 codes, tenminste 10 (op basis van mijn snelle zoekopdracht) lijken in Fortran te zijn geschreven. Niet slecht voor een 50 jaar oude taal.

OPMERKING: ik ben me er terdege van bewust dat taalvergelijkingen nutteloos zijn, maar gezien het aantal mensen (vooral C ++ -gebruikers) dat Fortran met een slechte mond heeft, dacht ik dat het de moeite waard zou zijn om het te vermelden.

Opmerkingen

• Ik ben het daar niet mee eens, omdat mijn ervaring bij de nationale laboratoria in ieder geval het tegenovergestelde was. De meeste van de nieuwe projecten die ik bij Lawrence Livermore zie, zijn geschreven in C ++, en de meeste nieuwe (of actief onderhouden) state-of-the-art open-sourcebibliotheken in ODE-oplossers, FEM-discretisaties en algemene wetenschappelijke computerbibliotheken lijken in C of C ++ te zijn. Fortran lijkt vooral gebruikt te worden in projecten die gebruik maken van bestaande / verouderde bibliotheken; Ik zie ‘ niet veel grote, nieuwe projecten met Fortran, onafhankelijk van wat ik van de taal vind.
• Sommige codes van de dichtheidsfunctionaaltheorie zijn ook geschreven in Fortran omvat VASP en CASTEP , hoewel, zoals @GeoffOxberry aangeeft, nieuw projecten neigen misschien naar C ++.
• @blochwave Zoals je in de link kunt lezen, zijn de projecten voor een nieuwe machine (met versnellers etc.) die in 2018 online komt.Het is dus niet alsof ze een code van 25 jaar nemen en deze compileren, in de hoop dat ze goed kunnen presteren. Ik ben er vrij zeker van dat grote delen van de codes in de bovenstaande lijst zijn of zijn herschreven, zoals in nieuwe code. Een aantal ” nieuwe ” klimaatcodes zijn ook in Fortran en worden door veel agentschappen in een aantal landen gebruikt.

Wat Jack P. volgens mij probeert te zeggen, is dat je moet mixen en matchen. Een goed stuk software is zorgvuldig gelaagd. Verschillende lagen kunnen natuurlijker of efficiënter worden toegewezen aan verschillende talen. U moet voor elke laag de meest geschikte taal kiezen. U moet ook begrijpen hoe talen kunnen samenwerken, wat van invloed kan zijn op de taal die u voor welke laag kiest.

Een betere vraag is welke voorbeelden van uitstekend ontworpen software er zijn die het bestuderen waard zijn om te leren hoe je gelaagde software kunt ontwerpen.