Hlavní navigace

Názory k článku Fortran: Quo vadis?

  • Článek je starý, nové názory již nelze přidávat.
  • 27. 8. 2007 0:23

    petris (neregistrovaný)
    Soubor je v C reprezentovan taky cislem, protoze je tak reprezentovan v operacnim systemu. FILE je ze standardni knihovny a vnitre tez pouziva ta_cisla. Pokud chci pouzivat cisla muzu vyuzit dprintf a spol. (je to ale GNU rozsireni)

    A kdyz by se to vzalo do detailu, tak v aplikaci se pracuje s odkazem na FILE, takze to je v podstate taky cislo ;-)
  • 27. 8. 2007 10:38

    petris (neregistrovaný)
    Tim, ze je to cislo, jsem myslel, ze se da bezztratove prevest na zakladni celociselny typ ty architektury (a zpet).
  • 1. 9. 2007 11:20

    highegg
    Tým Johna Backuse, který za to mimochodem dostal spoustu cen (tedy ne přesně za tohle). Uvědomte si, že tenhle mechanismus je starší než kterýkoli jiný jazyk, a
    nikdo prostě ještě tehdy nevymyslel nic lepšího.
    Návrh na předělání tohoto mechanismu byl vznesen několikrát.
    Vzhledem k tomu, že je ale triviální napsat výše zmíněnou proceduru "alokuj číslo souboru", čímž se v podstatě všechny nedostatky odstraňují, nikdy neprošel. Škoda je jen, že tahle procedurka není vestavěná.
  • 27. 8. 2007 11:33

    pkm (neregistrovaný)
    Spíš v unixu, než v C. File descriptory (a jejich přidělování), to definuje unix. Proto taky iso C místo FD používá FILE.
  • 27. 8. 2007 11:46

    petris (neregistrovaný)
    Je to definováno POSIXem, takže na toto chování se lze u rozumných systémů spolehnout - musí ho umět emulovat, když by vnitřně využívaly jiný způsob.
  • 28. 8. 2007 11:21

    jsem pes (neregistrovaný)
    Clanek je prima, ale nezminuje v praxi dulezity problem novych kompilatoru Fortranu: uzivatelska zakladna je mala, a tak obsahuji znatelne vetsi mnozstvi chyb nez kompilatory C nebo C++, ktere pouzivaji tisice vyvojaru.

    Moje zkusenost je, ze "neprofesionalni" programatori, kteri v minulosti pouzivali Fortran 77, si zvykli, ze kompilatory vetsinou produkovaly korektni kod. Nezridka preskakovali testovaci fazi a rovnou kompilovali s optimalizaci. Kdyz se pak objevily kompilatory Fortranu 90/95 od Fujitsu, Intelu, PGI, Sunu, ... tak nastala kalamita. V lepsim pripade ty kompilatory nezkompilovaly kod vubec (spousta kodu nebyla napsana v cistem Fortranu 77, ale obsahovala ruzna rozsireni), v horsim pripade ho zkompilovaly spatne a kod pocital nesmysly. Pokud pouzivate metodu Monte Carlo (kde vysledky jsou nahodna cisla), pak detekovani takove chyby neni trivialni zalezitost.

    Profesionalni programatori to vedi davno, ale do studentu fyziky, kteri programovani pouzivaji jen jako nastroj, o ktery se hloubeji nezajimaji, se musi porad hustit: testovat, testovat a znovu testovat. I kompilatory obsahuji chyby.
  • 28. 8. 2007 14:14

    Pavel Tišnovský
    Mate na mysli opravdove chyby prekladace, tj. vytvori se kod, ktery ma semanticky jiny vyznam nez ten Fortranovsky? Nebo jde o chyby, ktere treba vychazi z toho, ze nejaka jazykova konstrukce ma v F77 jine pouziti nez v prekladacich podle nove normy? Chapu, ze puvodní Fortran byl dosti benevolentni (tu slavnou nejdrazsi programatorskou chybu uz nekdo zminoval), ale novejsi prekladace snad uz jsou hodne prisne, ne?

    V C++ prekladacich jsou taky nedostatky, ktere je mozne povazovat za chyby. V minulosti to byly napriklad vyjimky jineho typu, nez predepisuje norma, nevalna podpora sablon, implementace STL taky vetsinou pokulhavala za specifikaci atd. Cecko je na tom znatelne lepe, zejmena po prepnuti do rezimu C89 nebo C99 (k tomu jeste -Wall).

    Sice se take vyskytnou nejasnosti (K&R poznamky vs. C99), ale ty vetsinou nezpusobuji vetsi problemy - resp. kod, ve kterem "nove" poznamky koliduji, stejne malokdo bude psat. Vlastne me napadaji jeste trigramy, ty nektere prekladace take nezvladaji, i kdyz by je IMHO mely vzdycky akceptovat (po prepnuti do spravneho modu).
  • 28. 8. 2007 16:32

    jsem pes (neregistrovaný)
    Popisoval jsem situaci, kdy vytvoreny kod neodpovida puvodnimu programu. Priklad: kod je napsany podle normy (napr. Fortran 77), ale kdyz pri prekladu zapnete optimalizaci nebo kontrolu rozsahu poli, vysledny kod napocita jiny vysledek. Osobne jsem se s tim nekolikrat setkal, chyby jsem nahlasil vyrobci.

    Dalsi priklad: Pouzivam rozsahly simulacni software, ktery byl prepsan z Fortranu 77 do Fortranu 90/95. Autori byli nadseni, protoze driv museli obchazet nedostatky Fortranu 77 ruznymi triky, zatimco nyni to mohou napsat v souladu s normou. Pokud kompilator nestandardni konstrukci pochopil (nejak obchazeli nemoznost dynamicky alokovat pole ve Fortranu 77), vysledny kod daval spravne vysledky. Nyni je situace takova, ze v naproste vetsine pripadu kod vypise spravny vysledek, ale obcas vypise nesmyslna cisla a v nekterych pripadech se zacykli. Mozna je chyba ve zdrojovem kodu, ale ja spis tipuji, ze kompilator vygeneroval chybny kod. Proste k novym kompilatorum Fortranu nemam prilis velkou duveru.
  • 28. 8. 2007 17:24

    Pavel Tišnovský
    Aha, tak to je docela problem a taky dobrodruzstvi. Osobne by mi toto chaoticke chovani dost vadilo, protoze si uchovavam jenom zdrojaky (predevsim C, Java + nejake malickosti ve Forthu, LISPu ci Logu) s predpokladem, ze je i v budoucnu prelozim a dostanu spravny vysledek.

    Samozrejme spoustu veci odchyti unit testy, ale kdo je opravdu poctive vytvari :-) Nehlede na to, ze za dob F77 nebyly unit testy takova moda jako dneska.

    Jestli jsou ty programy napsane napriklad tak, ze pristupuji az za posledni prvek pole (nekdo si tuto fintu oblibil i v C++, asi inspirovan iteratory), tak opravdu zalezi na prekladaci, spravci pameti a nevim coho dalsiho.
  • 29. 8. 2007 11:34

    Pavel Tišnovský
    A jde o puvodni prekladac podle F77, nebo o novy prekladac, ktery se prepne do kompatibility s F77? Protoze jestli maji nove prekladace bugy, tak bych jim moc neveril ani pri praci v kompatibilnim rezimu.
  • 1. 9. 2007 11:45

    highegg
    To je jednoduché, tak prostě vyzkoušejte jiný překladač, nejlépe několik (zadarmo můžete zkusit přinejmenším gfortran a g95, pokud mě kontaktujete, mohu vám pomoci i Intelem a EkoPathem). Pokud se chyba jinde nebude projevovat, máte možná pravdu.
    Ale situace, kterou popisujete, je naprosto typická pro chybný kód, nejčastěji zapisování do neplatné paměti (dealokované). Pokud jde jenom o chybný výsledek, často je problém jen v numerické přesnosti. Můžete-li, zkuste použít vyšší nebo nižší přesnost (např. čtyřnásobnou u překladačů Intel). To je často rychlý způsob, jak odhalit numerické problémy.
    Pokuste se problém najít. Především je dobré si někam ukládat seedy generátoru pseudonáhodných čísel, a když se chyba objeví, můžete běh s chybou zopakovat a pak ji izolovat. Je-li ve vašem kódu, nejspíš ji při tom odstraníte. Pokud ne, a podaří se vám ji zredukovat na krátký kód, tvůrce překladače ji bezpochyby odstraní v nejbližším update.
    Já jsem ochoten se s vámi vsadit o pivo, že chyba je ve vašem kódu.
  • 1. 9. 2007 11:31

    highegg
    A máte pro tohle tvrzení nějaké podklady, nebo vám to tak prostě jen ze zkušenosti připadá?
    Sledujete-li například GCC bugzillu, četnost chyb v gfortranu není nijak podstatně větší než v g++. Naprostá většina způsobuje pád při překladu nebo při běhu programu (zejména v běhové knihovně). Zvýší se samozřejmě když implementujete nové věci, ale tak už to chodí. Rok 2006 pro GCC byl z hlediska Fortranu velmi produktivní.
    Pokud jde o kompilaci starších kódů novými překladači, ze zkušenosti (na diskuzní skupině comp.lang.fortran) vím, že většina problémů je na straně uživatelů. Mnoho kódů nejenže používalo různá "jasná" rozšíření, ale používalo i triky, které nikdy nebyly standardem Fortranu, jenom si to o nich spousta lidí myslela, protože rozšířené překladače to tak dělaly.
    Testovat, testovat a testovat, s tím se nedá než souhlasit.
  • 1. 9. 2007 17:49

    jsem pes (neregistrovaný)
    Statistiky jsem si nedelal, vychazim ze zkusenosti a z toho, co jsem obcas zaslechl od kolegu, co provozuji numericke vypocty na PC clusterech. Situace se uz mozna zlepsila - nevim. V soucasnosti programuji vyhradne pod C++ a Fortran pouzivam jen prilezitostne.

    Aby to nevypadalo, ze si vymyslim nesmysly, tak jsem zagoogloval. Namatkou jsem vybral seznam odstranenych chyb v PathScale 2.1 (http://www.nersc.gov/nusers/systems/jacquard/psrn21.txt). Ze seznamu jsem vypsal relevantni chyby kompilatoru Fortranu. Chyby kompilatoru C a C++ byly trochu jineho charakteru, viz URL. Samozrejme je mozne, ze cetnost tech chyb je stejna, jen u kompilatoru Fortranu se o nich vi, protoze jsou testovany na vypoctne intenzivnich kodech.

    Bugs fixed between 2.0 and 2.1:
    -------------------------------
    [Bug 4145] pathf90: execution returns incorrect results unless compiled with -LNO:opt=0
    [Bug 5185] pathf90 - inaccurate results when compiled at -O2 and -Ofast on molecular dynamics code
    [Bug 5296] pathf90: incorrect runtime results at -O3; passes -O3 -LNO:simd=0
    [Bug 5651] pathf90 customer code gives wrong answers at -O3, executes correctly at -O2
    [Bug 6176] pathf90 - min and minval returns incorrect values with -O3
  • 3. 9. 2007 8:55

    highegg
    no já netvrdím, že to není pravda, protože ten důvod (méně uživatelů -> méně testerů) zní logicky. S překladačem PathScale jsme sami měli nedávno problém.
    Jen bych podotkl, že ve vašem včtu výše jde vždy o chyby s těžkými optimalizacemi, které často obsahují inovativní triky a techniky a není divu, že v tom jsou chyby. Bez bližších detailů
    je těžké o těch chybách něco více říci. Tvrdé optimalizace prostě numerické výsledky ovlivňují,
    to je známý fakt (a známý vtip, že program přestává počítat a začíná hádat). Ten poslední bug zní jasně jako bug, ale u těch předchozích těžko říct.
  • 1. 9. 2007 3:08

    Mikuláš Patočka (neregistrovaný)
    Nebude Fortran s těmi novými featurami už poněkud přepatlaný?

    Ve F77 se sice nějaký uživatelský program (např. se strukturami) napsat nedal, ale měl velkou výhodu, že byl jednoduchý, vědci a inženýři se jej nemuseli zdlouhavě učit, nemuseli se zabývat syntaxí, strukturováním programu apod.

    Pokud do Fortranu připlácají featury jako z C/C++, tak je otázka, kdo se to bude chtít učit a kdo to pak místo C a C++ bude používat?
  • 1. 9. 2007 11:15

    highegg
    To je samozřejmě věc názoru.
    Podle mého názoru (a zkušenosti) je naučit se programovat ve Fortranu podstatně jednodušší než naučit se programovat v C nebo C++, tedy přinejmenším naučit se v něm dělat programy skládající se jen ze soubrového/konzolového I/O a výpočtů. Stát se na něj expertem a znát všechna zákoutí, zejména ta z minulosti, je samozřejmě podstatně těžší. Ale i expertů na Fortran 77 znám mezi staršími kolegy málo.
    Fortranská komunita a potažmo standardizační komise nemá žádný záměr konkurovat
    C/C++. Jejich záměrem je vytvářet co nejlepší general-purpose jazyk pro numerické výpočty (to není oxymoron :) Nic takového zcela zřejmě (a oficiálně) není záměrem komunity C a C++. Hmm, možná jsem měl tuhle kapitolu více rozvést.
  • 1. 9. 2007 14:25

    Mikuláš Patočka (neregistrovaný)
    Mě by zajímalo, co udělá inženýr (který nikdy žádný uživatelský klikací program nepsal ani nehodlá psát), až dostane zdroják ve Fortranu s objekty a dědičností a bude po něm chtěno, aby ho pochopil a upravil. Fortran byl jednoduchý na naučení právě proto, že tyhle věci neměl.

    Přijde mi, že se objekty (a pointery) na tohle použití nehodí. Je nějaký příklad numerického výpočtu, kde by objektovost přinášela výhodu?
  • 3. 9. 2007 8:41

    highegg
    Samozřejmě ano, ale není to příliš časté. Ze své praxe vám mohu říci, že ve výpočetních utilitách malé až střední velikosti (to je subjektivní) vůbec necítím potřebu používat OOP, začínám ji cítit, když už program začíná mít různé komponenty a stává se generickým.
    Pointery jsou trochu o něčem jiném, protože bez nich prostě (ve Fortranu 77) nebyla možnost jak
    někam "a posteriori" uložit odkaz na nějaké pole. Já si myslím, že omezené pointery jsou ve Fortranu udělané dobře, jen tam prostě měla být i omezená možnost udělat "generický" pointer,
    se kterým by šla udělat třeba jen jediná věc, a to předělat ho zpátky na ten správný typ.

    Abych to ještě rozvedl, já jsem za svou zatím celkem krátkou praxi došel k názoru, že optimální
    model pro výpočetní programy je systém malých až středních utilit, které se ovládají z příkazové řádky a komunikují pomocí souborů a stdin/stdout. Když udělám knihovnu s hezkým rozhraním ve Fortranu 95, je dobrá pro mě a pár vybraných kolegů. Když udělám sexy objektové rozhraní v C++, tak na ni teoreticky dosáhne víc lidí, když udělám klasické C rozhraní (to můžu i ve F2003), tak ještě víc. Naprosto nejvíc lidí ale bude moci můj software používat, když místo systému funkcí a objektů vytvořím systém spustitelných programů ve stylu GNU coreutils, ovládaných volbami z příkazové řádky a komunikujících přes soubory, protože naprostá většina i "počítačově tupých" lidí je relativně schopná a ochotná se naučit a pochopit jak fungují soubory a příkazová řádka, a většina z nich dokonce pochopí i roury a skripty (prostě zapíše příkazy do souboru). Zatímco doufat, že všichni kterým by se můj soft mohl hodit, se naučí programovat v C++ a používat objekty, je marné. Ty knihovny můžou klidně být v pozadí, ale je prostě zbytečné snažit se stvořit co nejintuitivnější a nejflexibilnější
    rozhraní i pro idioty, protože můžu s klidem předpokládat, že kdokoli bude knihovny používat,
    bude na podobné úrovni jako já.
    V tomto světle, kdykoliv to jde (a ono to určitě vždycky nejde, ale překvapivě často) se
    snažím rozbít svůj software na nezávislé utility, které si kolegové mohou osvojit postupně a
    používat je jednoduše a intuitivně
    (spustím to, vypíše to help, přečtu si syntax a volby co potřebuju, připravím soubory, a spustím to znova. Když je to dlouhé a je těch utilit víc, dám to do skriptu a pak spouštím ten.)
    no, už to přetahuju, ale chtěl jsem tím říct, že OOP potřebuju tak výjimečně, že se vůbec nedivím, že ve Fortranu 95 není.
  • 4. 9. 2007 5:08

    Mikuláš Patočka (neregistrovaný)
    S tím programováním v shellu --- problémem je rychlost. Pokud uděláte třeba utility na sčítání, násobení a další operace s maticemi a budete programovat pomocí pouštění těchto utilit přes pipy, tak to bude tak tisíckrát pomalejší než kompilovaný kód --- většinu času zabere fork, exec, dynamické linkování těch utilitek při jejich pouštění a parsování vstupů.

    Řešením by mohl být nějaký specializovaný matematický program, který by měl takovéto rozhraní a přitom si kód vnitřně kompiloval a pracoval vnitřně v binárním formátu čísel. Ale sám nevím, jak se ty matematické programy ovládají.

    --- no, i když ono je pořád jednodušší napsat "a=b+c*d" než
    "cat c | multiply d | plus b >a"

    Ad. to, jak má vypadat jazyk pro počítačové nevzdělance --- třeba můj otec je dobrý inženýr a fyzik, ale k počítačům má odpor --- a používá na výpočty excel. Proč? Protože se v něm nemusí učit syntax a co napíše, to vidí. Sice je excel na větší programování naprosto nepoužitelný (proměnné nejdou pojmenovávat názvy, ale odkazy typu A3, neumí víc jak 2-rozměrné pole, nejde v něm nijak řídit průběh výpočtu), ale jemu to na to, co dělá, stačí. IMHO kdyby někdo udělal jazyk, který by i takovíhle lidé pochopili (t.j. s naprosto jednoduchou syntaxí), tak by měl reálně šanci na úspěch. Při nabalování featur z C++ do Fortranu si nedokážu dost dobře představit, kdo to pak bude místo C++ používat.
  • 6. 9. 2007 10:03

    highegg
    Ne, to jste mě úplně špatně pochopil. Je sice možné (a občas i užitečné) mít utilitu na například sečtení dvou souborů čísel (tou je např. AWK), ale to samozřejmě neznamená že bych ji pak musel volat z programů ve Fortranu. Můžu, pokud nejde o časově kritickou operaci.

    Takových programů je mnoho, např. Octave. Problém je právě v tom, co jsem říkal - používat (kopírovat, mazat, přejmenovávat) soubory a spouštět programy většina lidí umí nebo se to naučí velmi záhy, zatímco učit se Octave chtít nebudou.
    Pro low-level operace jako sčítání a násobení jim samozřejmě nezbude nic jiného, než nějaký ten tabulkáč, nebo Octave, AWK apod., nebo si napsat vlastní program. To ale lidi příliš často nepotřebují.

    Příklad: J.R. Schewchuk vytvořil excelentní 2D meshátor (generátor sítí) jménem
    triangle. Je možné jej použít dvěma způsoby - jako knihovnu s C rozhraním nebo pomocí "driveru", tedy souborů a příkazové řádky. Přestože si s tím dal autor jistě práci, nemůže komfort C rozhraní soupeřit s komfortem driveru, takže software používá stokrát více lidí jako driver než jako knihovnu (např. studenti numeriky na MFF). A dokonce i ve svých programech jej používají tak, že zapíší data do souborů a pak zavolají driver (i já jsem to tak dělal). Ušetří svůj čas za čas procesoru, a jsou to ochotni udělat i v mnoha jiných případech. Kdyby se meshovala tisíckrát nějaká miniaturní síť, asi by nebyli.


    Váš otec je typickým příkladem inženýra - (když to přeženu) počítač je pro něj jen jeden z mnoha přístrojů a nechce mu nadržovat. Excel se prostě naučil a vyhovuje mu, tak jej používá kde jen to jde. Pro jiné inženýry je to třeba jiný nástroj - Matlab, Octave, nebo ten starý Fortran 77.
    Každý programovací jazyk je kompromisem mezi jednoduchostí a silou a pár dalšími věcmi. Vždycky tu proto bude více jazyků, vyhovujících různým skupinám lidí, a je potřeba to přijmout.
    Vaše poslední věta o "nabalování featur z C++" svědčí o tom, že jste příslušnou část článku naprosto nepochopil (to ale může být i moje chyba). Fortran nic "nenabaluje". Změny ve Fortranu jsou reakcí na požadavky jeho uživatelů, a jen velmi vzdáleně, pokud vůbec, mají vzor v C++. Komise Fortranu se snaží vycházet vstříc jednoduchosti právě tím, že je poměrně konzervativní ohledně nových featur - když už se tam něco protlačí, tak to tam (někteří) uživatelé chtějí. Bohužel má Fortran nejdelší historii a tudíž i největší práci se zpětnou kompatibilitou. K odstranění featury obvykle dojde tehdy, když komise usoudí že je nahraditelná nějakou novější a nemá už široké použití v nových kódech. "Nových" je důležité. Kdyby se vycházelo vstříc všem "legacy" kódům, nikdy by se nic nikam nepohnulo. Ostatně nikdo uživatelům nebrání řídit se starším standardem.