Vlákno názorů k článku Fortran: Quo vadis? od jsem pes - Clanek je prima, ale nezminuje v praxi dulezity...
-
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. -
Pavel TišnovskýZlatý podporovatelMate 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). -
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. -
Pavel TišnovskýZlatý podporovatelAha, 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. -
Pavel TišnovskýZlatý podporovatelA 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.
-
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. -
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. -
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 -
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.
