C ++ vs Fortran a HPC-hez

Mint oly gyakran, a választás attól függ (1), hogy milyen problémát próbál megoldani, (2) készségei, és (3) azok az emberek, akikkel együtt dolgozol (kivéve, ha ez egy önálló projekt). Hagyok (3) egyelőre félre, mert mindenki egyéni helyzetétől függ.

Problémafüggőség: A Fortran kiváló a tömb feldolgozásában. Ha problémája egyszerű adatstruktúrák és különösen tömbök szempontjából leírható, a Fortran jól alkalmazkodik. A Fortran programozói végül nem nyilvánvaló esetekben is használnak tömböket (pl. Grafikonok ábrázolására). A C ++ jobban megfelel komplex és rendkívül dinamikus adatstruktúrák számára.

Képességfüggés: sokkal több programozási tapasztalat szükséges jó C ++ programok megírásához, mint jó Fortran programok megírásához. Ha kevés programmal indul és csak annyi idő áll rendelkezésére, hogy megtanulja munkájának ezt a szempontját, valószínűleg jobb megtérülést ér el a Fortran befektetési tanulásánál, mint a C ++ tanulása. Természetesen feltételezve, hogy problémája megfelel a Fortran-nak.

A programozás azonban nem csak a Fortran és a C ++ programban rejlik. Mindenkinek azt ajánlom, hogy aki számítástechnikába kezd, dinamikusan magasan kezdjen. – szintű nyelv, például a Python. Mindig emlékezzen arra, hogy az Ön ideje értékesebb, mint a CPU ideje!

Megjegyzések

• ” Mindig emlékezzen erre az Ön ideje értékesebb, mint a CPU ideje! ” Mivel valaki, aki HPC-ben dolgozik, nem értek egyet ezzel a résszel; minden más rajta van.
• ” Mindig emlékezzen arra, hogy az Ön ideje jobban oldható, mint a CPU ideje! ” As aki tudományos kutatásban dolgozik, nem tudnék ‘ jobban egyetérteni ezzel a résszel.
• ” Mindig emlékezzen arra az időd sokkal értékesebb, mint a CPU ideje! ” – Szeretném bedobni a 2 centemet – több száz csomópontot használva, mindegyiket Több mint 10 maggal több héten keresztül futtatni valamilyen programot úgy értelmezhetjük, mint a legértékesebb erőforrás szörnyű pazarlását, ha még pár hét képes létrehozni egy kódot, amely csak pár nap alatt fut le. Ezek a HPC-fürtök ritka és drága közös erőforrások.
• ” Mindig emlékezzen arra, hogy az Ön ideje jobban oldható, mint a CPU-idő! “, egy hét kód, de egy hónapig fut, ez a ‘ s nagyon szokásos uram!
• ” Mindig emlékezz arra, hogy az időd sokkal értékesebb, mint a CPU ideje! “, inkább egy hónapig kódolok, és egy hét múlva futok! – a kód megírása után többet lehet megtenni, és mások is hasznosabbnak találják az Ön által írt kódot.

Úgy gondolom, hogy a C ++ és a Fortran is elég jók és jól működnek.

Mindazonáltal úgy gondolom, hogy a Fortran jobban alkalmazható a numerikus tudományos számításokhoz, az algoritmusokhoz, amelyek segítségével kifejezhetők a tömbökhöz és nem szükségesek más kifinomult adatstruktúrák, így olyan területeken, mint a véges különbségek / elemek, a PDE megoldók, az elektronikus szerkezeti számítások. A Fortran egy tartományspecifikus nyelv. Különösen azt gondolom, hogy könnyebb gyors a tudós (nem feltétlenül informatikai szakértő) programjai Fortranban, mint C ++ nyelven.

A C ++ általános célú nyelv, így bármely algoritmust ki lehet fejezni benne, és ez mindenképpen jobb algoritmusok esetében, amelyeket nem lehet tömbökkel kifejezni, a HPC mezőből valószínűleg néhány grafikon, hálógenerátor, szimbolikus manipuláció és így tovább.

Arra is lehet írni y algoritmusok C ++ nyelven, de tapasztalatom szerint ez sokkal több informatikai tudást és általában több munkát igényel (azaz osztályokat kell létrehozni vagy újrafelhasználni a tömb manipulálásához, és kézzel kell kezelni a memóriakezelést, vagy valamilyen könyvtár használatával, például a Truchinos Teuchos). A nem szakértők általában nagyon jó Fortran programokat írnak, de szörnyű C ++ programokat (saját tapasztalataim szerint beszélve).

Jogi nyilatkozat: Én személy szerint nagyon szeretem a Fortran-t, és a numerikus számításhoz jobban szeretem a C ++ -ot. Több mint 2 évet töltöttem a napi C ++ programozással, és majdnem egy évet a modern Fortran napi programozással (véges elemek területén). A Python és a Cython is sokat használom.

Megjegyzések

• Az első válasz kiegyensúlyozott. Úgy gondolom, hogy a C ++ és a Fortran messze nem az egyetlen lehetőség a kortárs HPC-ben. Úgy gondolom, hogy jó tudni az erőt és a gyenge pontokat, amikor a Fortran, a C ++ vagy a Python mellett döntesz (vagy bármi más tetszik). 20.000 sor Fortran-t láttam egyetlen fájlban, amelyet organikusan növeltek néhány évtized alatt. Én személy szerint nem használnék másra, mint elszigetelt nehéz tömb számítástechnikára. Még a kimenettel kapcsolatos dolgokra sem. Eddig egy elfogult megjegyzéshez.
• Nem tudtam ‘ többet érteni ezzel a válasszal. A véges elem kódunkat nem lehetett volna Fortranban írni. Valójában 15 évvel ezelőtt kezdődött a sima C és a Fortran keverékeként (utóbbi a módszer numerikusan intenzív részeire vonatkozik), és több év alatt fokozatosan átállt a tiszta C-re, majd a C ++ -ra. A kód folyamatosan rövidebb, gyorsabb és könnyebben érthető, és minden iteráció után képes volt rá. Egyetértek másokkal, akik rámutatnak, hogy a C ++ rengeteg kötelet ad, amivel lőheted magad. Válassza ki azt a nyelvet, amelyikkel ‘ a legkényelmesebb.
• Bill, a modern Fortran-t (90 és későbbi kiegészítéseket?) Használta. Ez nagyon fontos (az erre adott válaszomban kifejezettebbnek kellett volna lennem). Természetesen a ” 20.000 sor Fortran ” vagy f77 általában nem jobb, mint a jól megírt C ++.
• @ OndřejČert í k: Úgy gondolom, hogy ha úgy gondolja, hogy a modern végeselemes programok ” simple ” adatstruktúrák, akkor ‘ egyiket sem nézte meg a közelmúltban. Próbálja meg adaptív véges elemeket, hp módszereket vagy multigridet megvalósítani strukturálatlan hálókon egyszerű adatszerkezetek segítségével. Bill rajta van, és azt hiszem, beszélhetek érte, mondván, hogy a ” modern Fortran használatával ” aligha lett volna több, mint egy kicsi különbség.
• @WolfgangBangerth, lásd például a Phaml-t ( math.nist.gov/phaml ) a Fortran megvalósításáról, nagyjából mindenről, ami te említetted.

Én is későn dobom a két centemet, de én ” Csak most láttam ezt a szálat, és úgy érzem, hogy az utókor számára néhány szempontot kétségbeesetten meg kell említenem. Miért? Nos, különben alma és narancs egy teljes értékű, dinamikusan gépelt objektumorientált nyelv összehasonlítása olyan statikus dologgal, mint a Fortran. Igen, a legújabb Fortran szabványok néhány modern megvalósítása nem csak ezt képes megtenni, de valójában nagyon kevesen használja őket, és így amikor Fortranról beszélünk, egyszerű, statikus és imperatív nyelvre gondolunk. Ez az a hely, ahol C is van, ezért a következőket a C-re cserélem C ++ -ra.

Először Mindenesetre a Fortran / C bármilyen vita tárgya jobb fordítókkal. A dedikált C / Fortran fordítók a múlté. Mind a gcc / gfortran, mind az icc / ifc csak különböző kezelőfelületek ugyanannak a háttérnek, azaz a programnak a kezelőfelület absztrakt leírássá alakítja, majd a háttér optimalizálja és összeállítja. Ha szemantikailag ugyanazt a kódot írja Fortranban vagy C-ben, a fordító mindkét esetben ugyanazt az összeállítást fogja létrehozni amely ugyanolyan gyorsan fog futni.

Ez most a második pontomhoz vezet: miért látunk még mindig diff erenciák? A probléma az, hogy a legtöbb összehasonlítást a Fortran programozói végzik valamivel C-ben vagy fordítva. Észrevetted már, hogy a szerzők vagy költők többsége hogyan szeret anyanyelvén írni? Szeretne verseket írni olyan nyelven, amelyen nem érzi magát teljesen magabiztosnak vagy otthon? Természetesen nem … Magam is a C-t tartom “anyanyelvi” programozási nyelvemnek. Ugyanakkor három évet is töltöttem egy olyan csoportban dolgozom, amely csak a Fortran-t használta, amelyben elértem egy bizonyos szintű folyékonyságot. Én azonban soha nem írnék semmit Fortranban, mivel jobban érzem magam a C-vel és ennek következtében az ebből eredő kóddal jobb lesz, bármit is definiálsz.

Tehát a fő különbség a programozóban van, nem pedig a nyelvben. Tehát nincsenek különbségek? Nos, nem egészen. Íme néhány példa:

• SIMD: Legyen szó SSE-ről, SSE3-ról vagy AltiVec-ről, ha Fortranban szeretné használni őket, akkor jobb, ha reméli és imádkozik, hogy a fordító kitalálja pontosan amit akarsz, és ezt megteszi. Sok szerencsét. A C-ben általában belső funkciók vannak az egyes architektúrákhoz, vagy újabban általános SIMD vektortípusok a gcc fájlban . A legtöbb Fortran-fordító csak a SIMD utasításait használja a ciklusok kibontásához, de ha van olyan rendszermagod, amely rövid adatvektorokon nem nyilvánvaló módon működik, akkor a fordító valószínűleg nem fogja látni.

• Különböző hardverarchitektúrák: A teljes CUDA architektúra a C magjai köré épül. Igen, a Portland Group rendelkezik CUDA -képes fortran fordító , de ez kereskedelmi, és ami a legfontosabb, nem az NVIDIA-tól származik. Ugyanez vonatkozik az OpenCL-re is, amelyre a legjobbat egy legutóbbi projekt találta, amely csak néhány alapvető hívást támogat.

• Párhuzamos programozás: Igen, mind az MPI, mind az OpenMP jól működik mind a C-vel, mind a Fortrannal. Azonban, ha valódi irányítást akarsz a szálaid felett, azaz ha teljesen dinamikusan osztott memóriával rendelkezel, akkor a hidegben leszel a Fortrannal. A C-ben vannak a szokásos pthread-ek, amelyek ugyan nem melegek és fuzzyak, de Általában az operációs rendszerhez való hozzáférésre támaszkodó számítások többségét (pl. szálak, folyamatok, fájlrendszerek stb.) jobban szolgálják a C-vel. Ja, és ne próbálja meg megtenni a sajátját hálózatépítés a Fortrannal.

• Könnyű használat: A Fortran közelebb van a Matlab-hoz, mint a C. Miután túllépte az összes kulcsszót és a változók deklarálásának módját, a többi kód úgy néz ki, mint a Matlab, így hozzáférhetőbbé válik a korlátozott programozási tapasztalattal rendelkező felhasználók számára.

• Interoperabilitás: Amikor struktúrát hoz létre C-ben, a tényleges adatok elrendezése egyenes és determinista. A Fortranban, ha mutató tömböket vagy strukturált adatokat használ, az adatok tényleges elrendezése erősen fordítófüggő, nem egyenes Hívhatod C-t Fortranból és fordítva, de ne kezdd gondolni, hogy olyan egyszerű lehet átadni mást, mint egy statikus tömböt egyikről a másikra és vissza.

Ez kissé stréber, alacsony szintű dolgok, de ez egy nagy teljesítményű számítástechnika, amiről beszélünk, igaz? Ha nem érdekli, hogyan lehet a lehető legjobban kihasználni az alapul szolgáló hardvert paradigmák, azaz olyan algoritmusok megvalósítása és / vagy fejlesztése, amelyek a legjobbak a megosztott / elosztott memória, a szálak, a SIMD vektorizálásához , A SIMT-t használó GPU-k és így tovább, akkor csak számítógéppel matekozol.

Ez sokkal hosszabb lett, mint bármi, amit elvállaltam, így itt “összefoglaló – hazavihető készlet fajtájú üzenetek:

• A legjobb kódot tud írja azon a nyelven, amelyet Ön a legjobban ismer.
• Nincs különbség az azonos hátteret használó két fordító által létrehozott kód minőségében – mi ek vagyunk azok, akik rossz kódokat írnak egyik vagy másik nyelven.
• Annak ellenére, hogy alacsonyabb szintűnek érzi magát, a Fortran meglehetősen magas szintű absztrakció, és nem engedi meg közvetlenül elérni bizonyos hardver / operációs rendszerek funkcióit, pl. SIMD, szálak, hálózatépítés stb. …

Megjegyzések

• Jó válasz. Nem ‘ nem gondolom, hogy a végső megjegyzésed feltétlenül igaz. Magam vagyok ‘ C programozó, de jó programozási gyakorlatok révén hozzáférhetsz alacsony szintű dolgokhoz Fortranban. Az olyan dolgok ideális felhasználási módja, mint a SIMD opok, az, ha olyan kódot írunk, amely erősen javasolja (például blokkolja a hurkokat), és hagyjuk, hogy a fordító megtegye helyetted. A menetfűzéshez egyszerűen használja az openMP-t (a pthreads némi extra munkával is használható). A Fortran mindazokkal a dolgokkal rendelkezik, amelyeket említ, nem ‘ t, csak a tipikus felhasználó számára fontos szinten: numerikus.
• @ Reid.Atcheson: Nos , ha mindent blokkol, hogy a fordító elkapja, akkor ez automatikusan működik C-ben és Fortran-ban is. A probléma azonban az, hogy mennyire akar megbízni a fordítójában? És miért akarja, hogy megbízzon abban az esetben, amikor pontosan tudja, mit akar tenni? Az OpenMP szálkásít, igen, de tömbönként. Becsaphatja, hogy különböző szálkészleteket kapjon különböző dolgok elvégzésére, de ez csak az OpenMP helytelen használata. A Fortran Pthreadjei csak a C függvények burkolói. Abban azonban egyetértek, hogy a Fortran könnyebb, ha ‘ nem tér ki a részletekre.
• Biztos, hogy nem vagy ‘ T teljes fordulatszámú 99% -os csúcsteljesítményt kap a fordítóra támaszkodva, de könnyen közel kerülhet. Ezen túlmenően vagy intrinsicset vagy inline ASM-et kell használnia. Valahol engedményeket kell tennie a programozó hatékonysága érdekében, hogy ‘ miért léteznek eleve a programozási nyelvek. Abban a szakaszban, hogy valójában eléggé őrült vagy ahhoz, hogy belemerülj az intrinsics vagy az ASM részleteibe (már voltam néhányszor), a Fortran nem egy div mankó. ‘ Tudod, hogyan lehet linkelni az összeszerelt, kézzel optimalizált kódban.
• @ Reid.Atcheson: Nos, én ‘ d azzal érvelnek, hogy párhuzamos HPC alkalmazások esetén jóval 99% -os csúcsteljesítmény alatt maradhat … És a gcc vektortípusok nem jelentenek problémát az intrinsics használatával 🙂
• @Pedro, Zseniális poszt. Abszolút brilliáns. Nagyon köszönöm a hozzászólást.Most találtam rá, miközben véletlenszerűen turkáltam érdekes szálakon.

A tudományos szoftverekről való 15 éves gondolkodásom óta : Ha a kódod 25% -kal gyorsabban fut, mert a Fortran-ba írod, de négyszer annyi időbe telik, amíg megírod (nincs STL, nehézségekbe ütközik az összetett adatstruktúrák stb.), Akkor a Fortran csak akkor nyer, ha a a napod hüvelykujjokkal ficánkolva várja a számításaid befejezését. Tekintettel arra, hogy szinte mindannyiunk számára a legértékesebb dolog a saját időnk, a következtetés a következő: használja azt a nyelvet, amely lehetővé teszi a leggyorsabb fejlesztését, hibakeresését és tesztelését, ésszerűségen belül figyelmen kívül hagyva, hogy ez lassabb lehet, mint lehet, ha lehetséges a Fortran-ban írtad.

A megközelítésem az volt, hogy a C ++ -ot mindenre használom, csak a számítási kernelekre, amelyek általában a legjobbak közgyűlésben írva; ez megvásárolja a hagyományos HPC-megközelítés teljes teljesítményét, de lehetővé teszi az interfész egyszerűsítését, például azáltal, hogy az olyan számítási kerneleket túlterheli egyetlen rutinba, mondja az SGEMM / DGEMM / CGEMM / ZGEMM – mondja Gemm. Nyilvánvaló, hogy az absztrakciós szint sokkal magasabbra emelhető a nyers mutatók elkerülése és az átlátszatlan osztályokra való áttérés révén, de ez egy szép első lépés.

A C ++ legnagyobb hátrányát a fordítási idő túlnyomó részének növekedése jelenti, de tapasztalatom szerint a fejlesztési idő megtakarítása nem csak pótolja. További hátrány, hogy a C ++ szállítói fordítók általában több hibát tartalmaznak, mint a C és a Fortran fordítók. Az elmúlt évben azt hiszem, közel tíz hibába ütköztem a C ++ fordítókban.

Mindezek alapján úgy gondolom, hogy az alacsony szintű nyelveken (és a Fortran) írt tudományos csomagok visszavonása vonakodás a kényelmes interfészek felfedéséhez a kifinomult adatstruktúrák számára: az emberek többsége elégedett a Fortran BLAS interfésszel, mivel csak mutatókat és vezető dimenziókat igényel a mátrixok leírásához, de kevesen állítják, hogy a szokásos 40 egész Fortran ritkán direkt megoldó felület bármi közeli a kényelmes (vö. UHM, SuperLU, PETSc és Trilinos).

Összefoglalva, azzal érvelek, hogy alacsony szintű számítási kerneleknél az assembly-t használom, de minden máshoz magasabb szintű nyelveket, különösen akkor, ha nem triviális adatstruktúrákon dolgozunk. a bejegyzés eredményeként C és Fortran $ y kernel teljesítményének összehasonlítását eredményezte.

Megjegyzések

• Miért nem ‘ miért bízna meg egy szabványos C fordítóban, megfelelő optimalizálással, amely lehetővé teszi a kernelek összeállítását? A kód méretének és összetettségének ezen szintjén nem egyértelmű a különbség abban, hogy egy fordító mit tud kihúzni belőle.
• Beszéltem már több emberrel, akik azt mondták nekem, hogy a megfelelő korlátozott használat mellett is a Fortranjuk volt még gyorsabb, mint a C és / vagy C ++ kódjuk valamilyen művelethez, például egy explicit mátrix transzponáláshoz.

Mivel új vagyok itt, régi kérdéseket néztem át, és megtaláltam ezt. Remélhetőleg nem tabu a régiekre válaszolni!

Mivel ezt senki más nem említette, gondoltam, hogy meg is teszem. A Fortran 2003 szinte teljes mértékben támogatott a legtöbb nagy fordító (intel, ibm, cray, NAG, PCG) által még a gcc-vel is a (hamarosan megjelenő) legújabb kiadás 4.7. A Fortran 2003 (és 2008) egy objektum-orientált nyelv, bár kicsit bőbeszédűbb, mint a C ++. Az egyik dolog, ami szerintem szép a Fortranban, az a tény, hogy a standard bizottság elsődleges közönségének tekinti a tudományos számítástechnikát (köszönöm Damian Rousonnak, hogy ezt a minap rámutatta).

Mindezt nem azért hozom fel, hogy a C ++ programozók Fortran programozókká váljanak, hanem azért, hogy a Fortran emberei tudják, hogy most több lehetőségük van a C ++ -ra váltáson vagy az objektumorientált koncepciók emulálásán kívül a Fortran 90/95-ben.

Figyelem: hozzáteszem, hogy költséges lehet a fordítóban lenni annak, amit a fordítókban megvalósítottak. Ha most egy nagy projektre vállalkozik a Fortran 2003-ban, akkor hibába ütközik, és folyamatosan frissítenie kell a fordítóját (különösen ha a gcc-t használod), bár ez az elmúlt hónapokban jelentősen javult!

A C ++ problémája: hogy számtalan esélyed van a teljesítmény tönkretételére, például vakon használva az STL-t, kivételeket, osztályokat (virtuális rezsi plusz alignm problémák), a kezelő túlterhelése (redundáns új / törlések) vagy sablonok (a véget nem érő fordítási és rejtjelezési hibák jóindulatúnak tűnnek, de így órákat pazarolhat).

Mindazonáltal jobban hozzáférhet az általános könyvtárakhoz, és valószínűleg áttekintheti a kódot (bár ez erősen függ a tereptől, és még mindig tiszta C-vel rendelkezik). És még mindig kompenzálhatja a Fortran rugalmasságának hiányát azáltal, hogy kódját olyan szkript nyelvre tekeri, mint az R, Lush, Matlab / Scilab, vagy akár Python, Ruby vagy Lua.

Megjegyzések

• Általában rossz ötlet alacsony szintű technikákat alkalmazni magas szintű nyelveken. Például az STL-t úgy tervezték, hogy nagyon elvont szinten működjön. Tudatában kell lennie annak, hogy mi az interfész számára készült, használja ezt a feladatot, majd lépjen ki a fordítók útjából.
• Úgy gondolom, hogy az mbq ‘ s és Martin egyaránt pontok igazságtalanok. Igen, vannak olyan módszerek, amelyekkel lelőheted magad, ha megpróbálsz lineáris algebra céljából numerikus vektort megvalósítani az std :: list < dupla >. De ez a ‘ ostoba érv: legalább a C ++ rendelkezik csatolt listájával, amelyet Ön használhat, míg a Fortran nem ‘ t. ‘ olyan, mint ” A kocsik olyan nagy sebességgel közlekednek, hogy ütközhet egy falnak és megsérülhet; inkább lovas kocsikat kell használnia. ” Ez ‘ csak egy ostoba ötlet egy magas szintű, az alacsony -szintű dolgok (pl. C ++) a magas szintű funkciókkal
• @WolfgangBangerth Nem, most Fortrannak ártasz – ez ” alacsony szintű ” mivel a baktériumok ” kevésbé fejlődnek “, mint az emberek . Ha autó analógiát szeretne, annak inkább hasonlítania kell arra, hogy ” akkor a Jeep-et és a Lexust is használhatja egy mocsaras elágazás keresztezéséhez, de az első használata kevésbé fáj “.
• Nagyra értékelem a véleményét, de fenntartom, hogy a Fortran

Három tény:

• F77 stílusú n-dimenziós tömbök C-ben: Nem probléma a CnD használatával (szégyentelen dugó, igaz)

• F90 “modulrendszer rosszul van megtervezve és ellenséges a környezetek felépítéséhez. (A modul nevének nem kell egyeznie a fájlnevével, pl.)

• A Fortran nem támogatja a refaktorálást. Néhány funkció kihúzása Ha egy függvényhez négy helyet kell megérintenie: a tényleges kódot, a változó deklarációkat, az argumentum deklarációkat és az argumentumlistát. A C két hely megérintésével érhető el. Ez összevonja az adatok megfelelő kezelésének elmulasztásának hatását (desc alul bordázva): Mivel a kis léptékű modularitás annyira fájdalmas, szinte mindenki gigantikus szubrutint ír.

Egy személyes benyomás:

• a Fortran nem működik jól az adatok kezeléséhez. Próbáljon meg visszaadni egy mutatót a felhasználó számára átlátszatlan adatszerkezethez az F77 vagy az F90 formátumban. (transfer(), itt jövünk)

Kommentárok

• Szia Andreas! A CnD érdekes, nem tudtam róla ‘. Ah, te írtad. 🙂 (Az f90 támogatja a szeletelést, a tömbök számára allokálható és ami a legfontosabb – tömb szintaxisa a szorzáshoz, összeadáshoz és így tovább.) A CMake-et a Fortran-nal használom, és modulokkal nagyszerűen működik.Mi is pontosan a ” argumentumlista “? Nem hiszem, hogy ezeket használnám, ezért csak 3 helyre van szükség a módosításhoz. A

A Fortran tömb / mátrix számításokra van optimalizálva, és alapos fájdalmat okoz bármilyen típusú szövegelemzésnél. Lehet, hogy a C és a C ++ nem egyezik a Fortrannal a numerikus számításban (ez bezárul), de sokkal könnyebbnek tartom a szöveg feldolgozását és az adatok (azaz az egyedi adatstruktúrák) rendszerezését a C / C ++ segítségével. mások már említették, hogy nem számolnak dinamikusan értelmezett nyelveket (Python és mtsai). Lehet, hogy nem kínálják előre a Fortan arcolvadási sebességét, de lehetővé teszik, hogy jobban összpontosítson a számítási probléma megoldására, mint a megvalósítás minden részletére. Gyakran megvalósíthat egy megoldást a Pythonban, és ha a teljesítmény elfogadhatatlan, végezzen valamilyen profilalkotást, azonosítsa a problémás területeket, vagy vagy optimalizálja ezt a kódot a Cython segítségével, vagy valósítsa meg újra a teljes programot egy fordított nyelven. Miután elkészült a problémamegoldó logika, a többi csak megvalósítás, és a számítási alapismeretek megfelelő ismerete mellett egyértelműnek kell lennie, hogy bármilyen programozási nyelven megjelenjen.

Megjegyzések

• Ennek ‘ igaza van. A szöveg elemzéséhez a Python-t is használom.
• A Python szkript egy részét fordított nyelven is megvalósíthatja, pl. C ++ és csatlakoztassa. Pl. Boost Python, Swig stb.

Jelenleg az egyik nemzeti laborban dolgozom. A legtöbb A körülöttem lévő emberek gépészmérnökök. A HPC-csoport néhány emberével beszélgetve főleg Linuxot és főleg C ++ -ot használnak. A jelenleg “I” csoport többnyire asztali alkalmazásokat használ, és a Windows rendszert használjuk csökkenő sorrendben: C #, FORTRAN, Python, VBA és VB (6, nem .NET). Néhány szimulációs motorokat a FORTRAN más nemzeti laboratóriumaiban írták.

Elnézést a feltárásért egy régi szál, de úgy tűnik, hogy még 2015-ben is sokat használják a Fortrant.

Most találkoztam ezzel (alternatív link ) lista, amely alapvetően egy 13 kód felsorolása, amelyet a DOE OCLF létesítménye jóváhagyott a 300 petaFLOPS Summit gépen való futtatásra, és amelyet 2018-ban a kutatók rendelkezésére bocsátanak. . Megpróbáltam megtalálni a kód fő nyelvét (egy gyors Google-keresés alapján), és itt találtam:

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 

Tehát 13-ból kódok, legalább 10 (a gyors keresés alapján) úgy tűnik, hogy Fortranban vannak írva. Nem rossz egy 50 éves nyelv számára.

MEGJEGYZÉS: Tisztában vagyok vele, hogy a nyelvek összehasonlítása haszontalan, de tekintettel a rossz szájú Fortran-ra (különösen a C ++ felhasználókra) számítottam, úgy gondoltam, érdemes lehet megemlíteni.

Hozzászólások

• Nem értek egyet, mert a nemzeti laborokban szerzett tapasztalataim, ha vannak ilyenek, ellentétesek voltak. A Lawrence Livermore-ban látott új projektek nagy része C ++ nyelven íródott, és az új (vagy aktívan fenntartott) legkorszerűbb nyílt forráskódú könyvtárak többsége ODE-megoldókban, FEM diszkretizációk és általános célú tudományos számítástechnikai könyvtárak úgy tűnik, hogy C vagy C ++. Úgy tűnik, hogy a Fortran-t elsősorban olyan projektekben használják, amelyek meglévő / régi könyvtárakat használnak; Nem látok sok nagy, új projektet a Fortran segítségével, függetlenül attól, hogy mit gondolok a nyelvről.
• Néhány sűrűségfunkciós elméleti kód is A Fortran tartalmazza a következőt: VASP és CASTEP , bár amire a @GeoffOxberry rámutat, új a projektek valószínűleg a C ++ felé fordulnak.
• @blochwave Amint a linken olvasható, a projektek egy új gépre vonatkoznak (gyorsítóval stb.), amely 2018-ban online lesz.Tehát nem mintha 25 év kódot vesznének és lefordítanák, remélve, hogy jó teljesítmény mellett futnak. Biztos vagyok benne, hogy a fenti listában szereplő kódok nagy részét átírták vagy átírták, akárcsak az új kódokban. Számos ” új ” klímakód található Fortranban is, és számos ország számos ügynöksége használja őket.

Jack P. szerintem azt akarja mondani, hogy keverni kell. Egy jó szoftver gondosan rétegzett. A különféle rétegek természetesebben vagy hatékonyabban tudják feltérképezni a különböző nyelveket. Minden réteghez meg kell választania a legmegfelelőbb nyelvet. Azt is meg kell értenie, hogy a nyelvek hogyan működhetnek együtt, ami befolyásolhatja, hogy milyen nyelvet milyen réteghez választ.

Jobb kérdés, hogy milyen kiválóan megtervezett szoftverek vannak olyan példák, amelyeket érdemes tanulmányozni, hogy megismerjék a réteges szoftverek tervezését.