C ++ vs Fortran pro HPC

Volba tak často závisí na (1) problému, který se snažíte vyřešit, (2) dovednosti, které máte, a (3) lidé, se kterými pracujete (pokud to není sólový projekt). V tuto chvíli (3) nechám stranou, protože to záleží na individuální situaci každého.

Závislost problému: Fortran vyniká zpracováním pole. Pokud lze váš problém popsat z hlediska jednoduchých datových struktur a zejména polí, je Fortran dobře přizpůsoben. Programátoři Fortranu nakonec používají pole i v případech, které nejsou zřejmé (např. Pro reprezentaci grafů). C ++ je vhodnější pro složité a vysoce dynamické datové struktury.

Závislost na dovednostech: psaní dobrých programů v C ++ vyžaduje mnohem více programovacích zkušeností než psaní dobrých programů ve Fortranu. Pokud začnete s malým programem ing ing experience and only have much much time to learn that aspect of your job, you probably get a better return on investment learning Fortran than learning C ++. Samozřejmě za předpokladu, že váš problém je vhodný pro Fortran.

Programování však má více než jen Fortran a C ++. Doporučuji každému, kdo jde do výpočetní vědy, aby začal s dynamickým vysokým -úrovňový jazyk, jako je Python. Vždy pamatujte, že váš čas je cennější než čas CPU!

Komentáře

• “ Vždy si to zapamatujte váš čas je cennější než čas CPU! “ Jako někdo, kdo pracuje v HPC, s touto částí nesouhlasím; všechno ostatní je na místě.
• “ Vždy pamatujte, že váš čas je více než čas CPU! “ Jak někdo, kdo pracuje ve vědeckém výzkumu, nemohl jsem ‚ s touto částí více souhlasit.
• “ Vždy si to pamatujte váš čas je cennější než čas CPU! “ – rád bych hodil své 2 centy – pomocí několika stovek uzlů, každý s 10+ jádry na spuštění nějakého programu po dobu několika týdnů lze chápat jako hrozné plýtvání nejcennějším zdrojem, pokud by pár dalších týdnů mohlo vytvořit kód, který běží jen za pár dní. Tyto klastry HPC jsou vzácným a nákladným běžným zdrojem.
• “ Vždy si pamatujte, že váš čas je platnější než čas CPU! „, kód na týden, ale běží měsíc, tento ‚ je docela obvyklý pane!
• “ Vždy si pamatujte, že váš čas je cennější než čas CPU! „, raději bych kódoval měsíc a běžel za týden! – po napsání kódu lze udělat více a ostatním se kód, který napíšete, bude hodit také.

Myslím, že C ++ i Fortran jsou dostatečně dobré a fungují dobře.

Nicméně si myslím, že Fortran je lepší pro numerické vědecké výpočty, pro algoritmy, které lze vyjádřit pomocí pole a nepotřebují další sofistikované datové struktury, takže v oblastech, jako jsou konečné rozdíly / prvky, řešiče PDE, výpočty elektronických struktur. Fortran je jazyk specifický pro doménu. Zejména si myslím, že je snazší psát rychle programy ve Fortranu než v C ++, vědec (nemusí to být nutně odborník na počítačové vědy).

C ++ je obecný jazyk, takže v něm lze vyjádřit jakýkoli algoritmus a je rozhodně lepší pro algoritmy, které nelze vyjádřit pomocí polí, z pole HPC pravděpodobně nějaké grafy, generátory sítí, symbolická manipulace atd.

Je také možné zapsat pole y algoritmy v C ++, ale podle mých zkušeností to vyžaduje mnohem více znalostí počítačových věd a obecně více práce (tj. je třeba vytvořit nebo znovu použít třídy pro manipulaci s poli a zvládnout správu paměti ručně nebo pomocí nějaké knihovny, jako je Teuchos od Trilinos). Neodborníci mají tendenci psát docela dobré Fortranské programy, ale příšerné C ++ programy (mluvím z vlastní zkušenosti).

Zřeknutí se odpovědnosti: Osobně mám Fortran hodně rád a pro numerické výpočty ho preferuji před C ++. Denně jsem strávil více než 2 roky programováním v C ++ a téměř rok programováním v moderním Fortranu denně (v oblasti konečných prvků). Hodně používám také Python a Cython.

Komentáře

• Jeden pro vyvážení první odpovědi. Myslím, že C ++ a Fortran nejsou zdaleka jediné možnosti v současném HPC. Myslím, že je dobré znát silné a slabé stránky, když se rozhodnete pro Fortran, C ++ nebo Python (nebo cokoli chcete). Viděl jsem 20 000 řádků Fortranu v jednom souboru, organicky pěstovaném po několik desetiletí. Já osobně bych nepoužil pro nic jiného než izolované těžké pole. Ani pro cokoli, co souvisí s výstupem. Zatím pro zaujatý komentář.
• Nemohl jsem ‚ s touto odpovědí více nesouhlasit. Náš kód konečných prvků by nebylo možné zapsat do Fortranu. Ve skutečnosti to začalo před 15 lety jako směsice prostého C a Fortranu (druhý je pro numericky náročné části metody) a v průběhu několika let se postupně přesunul do čistého C a poté do C ++. Kód byl trvale kratší, rychlejší a srozumitelnější a po každé iteraci byl schopnější. Souhlasím s ostatními, kteří poukazují na to, že C ++ vám dává spoustu provazu, se kterým si můžete střílet. Vyberte jazyk, který vám ‚ nejlépe vyhovuje.
• Bille, použili jste moderní Fortran (90 a novější dodatky?). To je velmi důležité (měl jsem být ve své odpovědi o tomto podrobnější). Samozřejmě “ 20 000 řádků Fortran “ nebo f77 obvykle není lepší než dobře napsaný C ++.
• @ OndřejČert í k: Myslím, že pokud věříte, že moderní programy s konečnými prvky používají “ jednoduché “ datové struktury, pak jste se ‚ v poslední době na žádnou z nich nepodívali. Zkuste implementovat adaptivní konečné prvky, metody hp nebo multigrid na nestrukturované sítě pomocí jednoduchých datových struktur. Bill je na místě a věřím, že za něj mohu mluvit, když řeknu, že použití “ moderního Fortranu “ by bylo těžko víc než jen malý rozdíl.
• @WolfgangBangerth, viz například Phaml ( math.nist.gov/phaml ) pro Fortranskou implementaci skoro všeho, co zmínil jste se.

Také hodím své dva centy nějak pozdě, ale já “ Toto vlákno jsem právě viděl a mám pocit, že pro potomky existuje několik bodů, které je zoufale potřeba udělat.

V následujícím textu si povím, že budu hovořit o C a ne o C ++. Proč? Jinak je srovnávání plnohodnotného objektově orientovaného jazyka s dynamickým typem a něčím tak statickým, jako je Fortran, jablka a pomeranče. Ano, některé moderní implementace nejnovějších standardů Fortran mohou dělat víc než jen to, ale jen velmi málo lidí použijte je, a tak když mluvíme o Fortranu, myslíme si jednoduchý, statický a imperativní jazyk. To je také místo, kde je C, takže C nahradím C ++ za následující.

První z vše, jakákoli diskuse o tom, že Fortran / C má lepší kompilátory, je diskutabilní. Vyhrazené kompilátory C / Fortran jsou věcí minulosti. Oba gcc / gfortran a icc / ifc jsou jen odlišná front-endy ke stejnému back-endu, tj. váš program bude front-endem transformován do abstraktního popisu a poté optimalizován a sestaven back-endem. Pokud píšete sémanticky stejný kód ve Fortranu nebo v C, kompilátor v obou případech vytvoří stejnou sestavu který poběží stejně rychle.

Toto nyní vede k mému druhému bodu: proč stále vidíme rozdíl erence? Problém je v tom, že většinu srovnání provádějí programátoři Fortranu, kteří zkoušejí něco v jazyce C nebo naopak. Všimli jste si někdy, jak většina autorů nebo básníků dává přednost psaní v jejich rodných jazycích? Chcete psát poezii v jazyce, ve kterém se necítíte úplně sebevědomě nebo doma? Samozřejmě že ne … já sám považuji C za svůj „rodný“ programovací jazyk. Strávil jsem však také tři roky pracovat ve skupině, která používala pouze Fortran, ve které jsem dosáhl určité úrovně plynulosti. Nikdy bych však ve Fortranu sám nic nenapsal, protože mi vyhovuje C a v důsledku toho i výsledný kód bude lepší , ať už to definujete jakkoli.

Hlavní rozdíl je tedy v programátoru, nikoli v jazyce. Takže neexistují žádné rozdíly? No, ne tak docela. Zde je několik příkladů:

• SIMD: Ať už je to SSE, SSE3 nebo AltiVec, pokud je chcete použít ve Fortranu, doufejte a modlete se, aby kompilátor hádal přesně co chcete a dělá to tak. Hodně štěstí. V jazyce C máte obecně vnitřní funkce pro každou architekturu, nebo v poslední době obecné typy vektorů SIMD. v gcc . Většina překladačů Fortran použije k odmotání smyček pouze instrukce SIMD, ale pokud máte jádro, které pracuje na krátkých vektorech dat nejasným způsobem, kompilátor to velmi pravděpodobně neuvidí.

• Různé hardwarové architektury: Celá architektura CUDA je postavena na jádrech v jazyce C. Ano, skupina Portland má nyní CUDA -kompatibilní překladač Fortran , ale je to komerční a co je nejdůležitější, nepochází od NVIDIA. Totéž platí pro OpenCL, pro který je to nejlepší, co jsem našel, nedávný projekt , který podporuje pouze několik základních hovorů.

• Paralelní programování: Ano, MPI i OpenMP fungují dobře jak s C, tak s Fortranem. Pokud však chcete mít nad svými vlákny skutečnou kontrolu, tj. Pokud máte plně dynamický výpočet sdílené paměti, budete s Fortranem venku v chladu. V C máte standardní pthreads, která, i když nejsou teplá a fuzzy, budou stále vás provede bouří. Obecně platí, že většině výpočtů, které se spoléhají na přístup k operačnímu systému, např. vlákna, procesy, souborový systém atd., je lépe vyhovovat s C. Oh, a nepokoušejte se udělat si vlastní síť s Fortranem.

• Snadné použití: Fortran je blíže Matlabu než C. Jakmile jste se dostali přes všechna různá klíčová slova a jak deklarovat proměnné, zbytek kódu vypadá jako Matlab, takže je přístupnější uživatelům s omezenými zkušenostmi s programováním.

• Interoperabilita: Když vytvoříte strukturu v jazyce C, je rozložení skutečných dat přímočaré a deterministické. Ve Fortranu, pokud používáte pole ukazatelů nebo strukturovaná data, je skutečné rozložení dat silně závislé na kompilátoru, nikoli přímo – dopředu a obvykle zcela nezdokumentováno. Můžete volat C z Fortranu a naopak, ale nezačněte si myslet, že může být stejně snadné předat cokoli jiného než statické pole z jednoho na druhé a zpět.

Jedná se o poněkud podivínské věci na nízké úrovni, ale jedná se o vysoce výkonné počítače, o kterých mluvíme, že? Pokud vás nezajímá, jak nejlépe využít základní hardware paradigmata, tj. implementace a / nebo vývoj algoritmů, které jsou nejlepší pro sdílenou / distribuovanou paměť, vlákna, vektorizace SIMD „GPU využívající SIMT a tak dále, pak„ jen děláte matematiku na počítači.

Tím se dost prodlužuje všechno, co jsem zamýšlel, takže zde je shrnutí – sada vzít si domů druhy zpráv:

• Napíšete nejlepší kód můžete v jazyce, který vy znáte nejlépe.
• Neexistuje žádný rozdíl v kvalitě kódu vytvořeného dvěma překladači, kteří používají stejný back-end – to je my , kdo píše špatný kód v jednom či druhém jazyce.
• Navzdory pocitu více nízké úrovně je Fortran celkem abstrakcí na vysoké úrovni a neumožňuje přímý přístup k určitým funkcím hardwaru / OS, např. SIMD, vlákna, síť atd.

Komentáře

• Dobrá odpověď. ‚ si nemyslím, že váš poslední komentář je nutně pravdivý. Sám jsem ‚ programátor C, ale přístup k věcem na nízké úrovni ve Fortranu získáte pomocí dobrých programovacích postupů. Ideálním způsobem, jak využít věci jako SIMD ops, je napsat kód, který to silně naznačuje (například blokování smyček) a nechat kompilátor, aby to udělal za vás. Pro threading jednoduše použijte openMP (pthreads je také použitelný s nějakou prací navíc). Fortran má všechny věci, o kterých se zmíníte, ‚ t, jen na úrovni, která je pro jeho typického uživatele důležitá: numerická.
• @ Reid.Atcheson: No , pokud zablokujete vše tak, aby to kompilátor zachytil, bude to fungovat automaticky v C i ve Fortranu. Problém však je, do jaké míry chcete svému kompilátoru důvěřovat? A proč mu chcete důvěřovat v případech, kdy víte přesně , co chcete udělat? OpenMP dělá threading, ano, ale blokově. Můžete to přimět k získání různých fondů vláken, abyste mohli dělat různé věci, ale to je jen nesprávné použití OpenMP. Pthreads pro Fortran jsou jen obaly funkcí C. Souhlasím však s tím, že Fortran je jednodušší, pokud ‚ nejste v detailech.
• Určitě ‚ nebudeme mít úplnou 99% špičkovou účinnost spoléhající se na kompilátor, ale můžete se snadno dostat docela blízko. Kromě toho musíte buď použít vnitřní nebo vložený ASM. Kvůli celkové efektivitě programátoru musíte někde udělat ústupky, to je ‚ proč programovací jazyky vůbec existují. Ve fázi, kdy jste ve skutečnosti dost šílení, abyste se dostali do detailů vnitřní nebo ASM (byl jsem několikrát), Fortran není ‚ t berle. ‚ Stejně tak víte, jak propojit svůj sestavený ručně optimalizovaný kód.
• @ Reid.Atcheson: No, já ‚ Tvrdím, že u paralelních aplikací HPC můžete skončit hluboko pod 99% špičkovou účinností … A díky vektorovým typům gcc není použití vnitřních řešení problém 🙂
• @Pedro, Brilantní příspěvek. Naprosto geniální. Díky moc za zveřejnění příspěvku.Právě jsem to našel při náhodném procházení zajímavými vlákny.

Z mých 15 let přemýšlení o vědeckém softwaru : Pokud váš kód běží o 25% rychleji, protože jej píšete ve Fortranu, ale jeho napsání vám trvá 4krát déle (bez STL, potíže s implementací složitých datových struktur atd.), Fortran vyhraje, pouze pokud utratíte značnou část váš den krouží palce a čeká na dokončení výpočtů. Vzhledem k tomu, že téměř pro každého z nás je nejcennější náš vlastní čas, závěr je následující: použijte jazyk, který vám umožní vyvíjet, ladit a testovat váš kód nejrychleji, aniž byste ignorovali, že může být pomalejší, než by bylo možné, pokud napsal jsi to ve Fortranu.

Mým přístupem bylo použití C ++ pro všechno kromě výpočetních jader, které jsou obvykle nejlepší napsáno v sestavě; tím získáte veškerý výkon tradičního přístupu HPC, ale umožníte zjednodušit rozhraní, například přetížením výpočetních jader, jako je SGEMM / DGEMM / CGEMM / ZGEMM, do jediné rutiny, řekněme Gemm. Je zřejmé, že úroveň abstrakce lze zvýšit mnohem výše tím, že se vyhneme surovým ukazatelům a přejdeme na neprůhledné třídy, ale je to pěkný první krok.

Považuji za největší nevýhodu C ++ ohromně zvýšení času kompilace, ale podle mých zkušeností úspora času na vývoj více než vynahradit. Další nevýhodou je, že kompilátoři dodavatele C ++ mají tendenci mít více chyb než kompilátoři dodavatele C a Fortran. V uplynulém roce si myslím, že jsem narazil na téměř deset chyb v kompilátorech C ++.

Se vším, co bylo řečeno, si myslím, že zrušení vědeckých balíčků napsaných v nízkoúrovňových jazycích (a Fortranu) je neochota vystavit pohodlná rozhraní pro sofistikované datové struktury: většina lidí je spokojena s rozhraním Fortran BLAS, protože k popisu matic vyžaduje pouze ukazatele a úvodní dimenze, ale jen málo lidí by tvrdilo, že obvyklé 40-řádové rozhraní Fortran sparse-direct solver je něco blízkého pohodlnému (srov. UHM, SuperLU, PETSc a Trilinos).

Souhrnně se domnívám, že používám sestavu pro nízkoúrovňová výpočetní jádra, ale jazyky vyšší úrovně pro všechno ostatní, zejména při provozu na netriviálních datových strukturách.

Všimněte si, že toto výsledkem příspěvku je toto srovnání výkonu C a Fortran v jádře $ y: = \ alpha x + y $ .

Komentáře

• Proč byste ‚ nedůvěřovali standardnímu kompilátoru C s povolenou vhodnou optimalizací pro účely kompilace malých jader? Na této úrovni velikosti a složitosti kódu není jasný rozdíl v tom, co z toho může kompilátor vytáhnout.
• Mluvil jsem s několika lidmi, kteří mi řekli, že i při vhodném omezení používání byl jejich Fortran stále rychlejší než jejich C a / nebo C ++ kód pro některé operace, jako je explicitní maticová transpozice. ‚ Neříkám, že je nemožné ‚ udělat kód C nebo C ++ tak rychle, ale že to kompilátor Fortran dělá lepší práci.
• Mám stejné zkušenosti s klíčovým slovem “ restrict “ (můj jednoduchý Fortranův kód byl vždy o něco rychlejší). Ale moje odbornost je omezená a prostě nemám ‚ čas na investování do porozumění generované sestavě z gcc. Takže jednoduše používám Fortran, je to ‚ jednoduché a ‚ rychlé.
• @JackPoulson: Kompilátor argument je něco, co dost slyším od Fortranské komunity. Bohužel většina překladačů, např. gcc nebo ifc / icc, pro stejný back-end použijte rozhraní frontend v různých jazycích. Strojní zařízení provádějící optimalizaci a generování kódu je identické, a proto jsou rozdíly ve výsledcích pravděpodobně způsobeny rozdíly ve znalostech programátora se základním jazykem …
• Jen pro malou perspektivu na často opakované, zřídka ověřené tvrzení, že Fortran je v numerických jádrech rychlejší: Před časem jsme si všimli, že řídký maticový vektor se množí v balíčku Trilinos ‚ Epetra byl o 30% pomalejší než ten v dohodě. II. První z nich byl napsán v přímém formátu Fortran 77, druhý v přímém formátu C bez použití ‚ restrict ‚. Oba měli kolem 10-15 řádků kódu. Dnes Trilinos používá část kódu získaného z dohody. II. Jsem si ‚ jistý, že se najde spousta případů, kdy je F77 rychlejší než C. Jde o to, že to není ‚ univerzálně, takže už ne dnes.

Jelikož jsem zde nový, hledal jsem staré otázky a našel jsem tuto. Doufejme, že není tabu odpovídat na staré!

Protože to nikdo jiný nezmínil, napadlo mě to. Fortran 2003 je téměř plně podporován většinou hlavních překladačů (intel, ibm, cray, NAG, PCG) dokonce i gcc s (brzy k dispozici) nejnovější vydání 4.7. Fortran 2003 (a 2008) je objektově orientovaný jazyk, i když o něco podrobnější než C ++. Jednou z věcí, které si myslím, že je na Fortranu hezké, je skutečnost, že standardní výbor vidí primární publikum „vědeckých výpočtů jako takové“ (děkuji Damianovi Rousonovi za to, že mi na to ten druhý den upozornil).

Uvedu to všechno ne proto, aby se programátoři C ++ stali programátory Fortranu, ale aby lidé z Fortranu věděli, že nyní mají více možností kromě přechodu na C ++ nebo emulace objektově orientovaných konceptů ve Fortranu 90/95.

Jeden Upozornění dodám, že stojí za to být na pokraji toho, co je implementováno v kompilátorech. Pokud se právě chystáte na velký projekt ve Fortranu 2003, narazíte na chyby a neustále budete muset svůj kompilátor aktualizovat (zejména pokud používáte gcc), i když se to za posledních několik měsíců výrazně zlepšilo!

Problém s C ++ je že máte četné šance zničit výkon, například slepým používáním STL, výjimek, tříd (virtuální režie plus alignm ent problems), přetížení operátora (redundantní new / deletes) nebo šablony (nekonečná kompilace a záhadné chyby se zdají neškodné, ale tímto způsobem můžete ztrácet hodiny).

Čím více však získáte lepší přístup k obecným knihovnám a možná lepší viditelnost svého kódu (i když to silně závisí na poli a stále máte čistý C). Stále můžete kompenzovat nedostatek flexibility Fortranu zabalením jeho kódu do skriptovacího jazyka, jako je R, Lush, Matlab / Scilab nebo dokonce Python, Ruby nebo Lua.

Komentáře

• Obecně je špatný nápad používat techniky na nízké úrovni v jazycích na vysoké úrovni. Například STL je navržen tak, aby fungoval na velmi abstraktní úrovni. Je třeba si uvědomit, jaké rozhraní je určen pro, použijte jej pro tento úkol a pak se dostaňte z cesty překladačů.
• Myslím, že jak mbq ‚ sa Martin ‚ body jsou nespravedlivé. Ano, existují způsoby, jak si vystřelit do nohy, pokud se pokusíte implementovat numerický vektor pro účely lineární algebry pomocí std :: list < double >. Ale ten ‚ je hloupý argument: alespoň C ++ má třídu propojeného seznamu, kterou může použít, zatímco Fortran ‚ t. ‚ to rád říká “ Auta jezdí tak vysokou rychlostí, že byste mohli narazit do zdi a zranit se; místo toho byste měli používat kočáry tažené koňmi. “ ‚ Je to jen hloupý nápad vyhodit jazyk na vysoké úrovni, který podporuje i nízké – úroveň věcí (např. C ++) pro které mají funkce na vysoké úrovni.
• @WolfgangBangerth Ne, nyní ubližujete Fortranu – je to jako “ nízkoúrovňový “ protože bakterie jsou “ méně vyvinuté “ než lidé . Pokud chcete analogii s autem, mělo by to být spíše jako “ můžete použít Jeep i Lexus k překonání bažinaté odbočky, ale použití prvního z nich méně bolí „.
• Oceňuji váš názor, ale tvrdím, že Fortran není ‚ tak rozvinutý jako C ++: -)

Tři fakta:

• N-dimenzionální styl F77 pole v C: Žádný problém s použitím CnD (jistě nestydatá zástrčka)

• F90 je špatně navržen a je nepřátelský k vytváření prostředí. (Název modulu nemusí odpovídat jeho názvu souboru, například)

• Fortran nepodporuje dobře refaktorování. Vytáhne trochu funkčnosti funkce vyžaduje, abyste se dotkli čtyř míst: Skutečný kód, deklarace proměnných, deklarace argumentů a seznam argumentů. C se obejde se dvěma místy, kterých se má dotknout. To zvyšuje účinek selhání správy dat dobře (desc níže): Protože modularita v malém měřítku je tak bolestivá, téměř každý píše gigantické podprogramy.

Jeden osobní dojem:

• Fortran nefunguje dobře pro správu dat. Zkuste vrátit ukazatel na uživatelsky neprůhlednou datovou strukturu v F77 nebo F90. (transfer(), jsme tady)

Komentáře

• Ahoj Andreasi! CnD je zajímavý, nevěděl jsem o tom ‚. Ah, napsal jsi to. 🙂 (f90 také podporuje krájení, alokovatelné pro pole a co je nejdůležitější – syntaxe pole pro násobení, sčítání atd.) Používám CMake s Fortranem a funguje skvěle s moduly.Co přesně je “ seznam argumentů „? Nemyslím si ‚ že je používám, takže k úpravám stačí pouze 3 místa. V jazyce C obvykle potřebujete upravit skutečný kód, parametry a soubor záhlaví, takže ‚ s také 3 místa (rozhodně v C ++). Ano, transfer () není ‚ t super pěkný, ale v praxi to obvykle ‚ nepotřebujete.
• Refaktorování moderního Fortranu je triviální se správnými IDE, jako je Photran v zatmění.
• “ Název modulu ‚ nemusí ‚ odpovídat jeho názvu souboru, např. “ Musíte si dělat srandu, v jednom souboru můžete mít mnoho modulů. Některé z nich pokrývají jen pár řádků. Vytváření je mnohem snazší, pokud nemusíte pro každou z nich vytvořit soubor.
• Chtěl jsem jen přidat to, co @ user389 řekl, zatímco Photran je skvělý a je jediným Fortran IDE, který umožňuje refactorings, jeho parser neustále selhává. Na druhou stranu ‚ není třeba komentovat skutečnost, že Eclipse má velkou paměť.

Fortran je optimalizován pro maticové a maticové výpočty a je velmi obtížné s ním pracovat při jakémkoli typu syntaktické analýzy textu. C a C ++ se nemusí shodovat s Fortranem v numerických výpočtech (je to blízko), ale považuji za mnohem snazší zpracovávat text a organizovat data (tj. Vlastní datové struktury) pomocí C / C ++.

As jiní zmínili, nepočítají dynamicky interpretované jazyky (Python a kol.). Možná nenabízejí rychlost tání tváře Fortana předem, ale umožňují vám soustředit se více na řešení vašeho výpočetního problému než na všechny podrobnosti implementace. Často můžete implementovat řešení v Pythonu, a pokud je výkon nepřijatelný, proveďte nějaké profilování, identifikujte problémové oblasti a buď optimalizujte tento kód pomocí Cythonu, nebo znovu implementujte celý program v kompilovaném jazyce. Jakmile budete mít logiku řešení problémů rozpracovanou, zbytek bude jen implementace a s dobrým porozuměním základům výpočetní techniky by měla být přímá reprezentace v jakékoli řadě programovacích jazyků.

Komentáře

• To ‚ má pravdu. Pro analýzu textu používám také Python.
• Můžete také implementovat část skriptu Pythonu v kompilovaném jazyce, např. C ++ a připojte jej. Např. Zvyšte Python, Swig atd.

Momentálně pracuji v jedné z národních laboratoří. Většina lidí kolem mě jsou strojní inženýři. Chatují s některými lidmi ve skupinách HPC a dělají většinou Linux a většinou C ++. Skupina, v níž se aktuálně nacházím, dělá většinou desktopové aplikace a používáme Windows a v sestupném pořadí: C #, FORTRAN, Python, VBA a VB (6, ne .NET). Některé simulační nástroje , které používáme, byly napsány v jiných národních laboratořích ve FORTRANU.

Omlouvám se, že jsem se vyhrabal staré vlákno, ale zdá se, že i v roce 2015 se Fortran hodně používá.

Právě jsem narazil na toto (alternativní odkaz ) seznam, který je v zásadě seznam 13 kódů schválených zařízením OCLF DOE pro provoz na stroji Summit 300-petaFLOPS, který bude vědcům k dispozici v roce 2018 . Pokusil jsem se najít hlavní jazyk použitý pro kód (na základě rychlého vyhledávání google) a tady jsem našel:

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 

Takže ze 13 kódy, nejméně 10 (na základě mého rychlého vyhledávání) se zdá být napsáno ve Fortranu. To není špatné pro 50 let starý jazyk.

POZNÁMKA: Jsem si dobře vědom toho, že srovnání jazyků jsou k ničemu, ale vzhledem k počtu lidí (zejména uživatelů C ++), kteří mají špatný jazyk Fortran, jsem si myslel, že by stálo za zmínku.

Komentáře

• Nesouhlasím, protože moje zkušenost v národních laboratořích byla, pokud vůbec, opačná. Většina nových projektů, které vidím na Lawrence Livermore, je napsána v C ++ a většina nových (nebo aktivně udržovaných) nejmodernějších open-source knihoven v řešeních ODE, diskretizacích FEM a univerzálních knihovnách pro vědecké výpočty Zdá se, že jsou v C nebo C ++. Fortran se zdá být používán hlavně v projektech, které používají existující / starší knihovny; Nevidím ‚ mnoho velkých, nových projektů využívajících Fortran, nezávisle na tom, co si o tomto jazyce myslím.
• Některé kódy funkční teorie hustoty, také napsané v Mezi Fortran patří VASP a CASTEP , ačkoli, jak zdůrazňuje @GeoffOxberry, nový projekty možná směřují k C ++.
• @blochwave Jak si můžete přečíst v odkazu, projekty jsou pro nový stroj (s akcelerátory atd.), který bude online v roce 2018.Není to tak, jako by si vzali 25letý kód a zkompilovali ho, doufajíc, že s ním poběží při dobrém výkonu. Jsem si docela jistý, že velké části kódů ve výše uvedeném seznamu byly nebo byly přepsány, jako v novém kódu. Ve Fortranu je také řada “ nových “ klimatických kódů, které používá řada agentur v řadě zemí.

Jack P. Myslím, že se snaží říci, že byste měli kombinovat. Dobrý software je pečlivě vrstvený. Různé vrstvy mohou mapovat přirozeněji nebo efektivněji do různých jazyků. Měli byste zvolit nejvhodnější jazyk pro každou vrstvu. Měli byste také pochopit, jak mohou jazyky spolupracovat, což může ovlivnit, jaký jazyk si vyberete pro jakou vrstvu.

Lepší otázkou je, jaké příklady skvěle navrženého softwaru existují, které stojí za to studovat, abyste se dozvěděli, jak navrhovat vrstvený software.