Názory k článku Fortran: základní konstrukce jazyka
-
agfa (neregistrovaný)Zdravim, delam program pro vedecke vypocty v Jave. Rad bych znal odpoved na par otazek:
1) Jde fortran prelozit do java bytecode? Existuji prekladace pro Python, Ruby...
2) Jde fortran pouzivat v clastru, tedy na vice pocitacich soucasne?
3) Jaky jazyk by autor doporucil pro vypocty dnes? (startuji novy projekt)
4) Co si myslite o jazyku Fortress od Sunu, ktery ma ambice nahradit Fortran? http://en.wikipedia.org/wiki/Fortress_(programming_language)
Diky za odpovedi -
agfa (neregistrovaný)Odkaz na fortress se vlozil spatne, zde je oprava: http://en.wikipedia.org/wiki/Fortress_(programming_language)
-
MeDon (neregistrovaný)2) Jde fortran pouzivat v clastru, tedy na vice pocitacich soucasne?
ano, Fortran se pouzival se a stale se pouziva na clusterech i jinych zbesilych masinach
3) Jaky jazyk by autor doporucil pro vypocty dnes? (startuji novy projekt)
Ja bych doporucil asi C, C++. Je v tom mozna citelnejsi kod (i kdyz to je vec nazoru a stylu), zna to vice lidi -> snazsi zapojeni dalsich lidi do projektu. -
Yenya (neregistrovaný)> C rozhodne ne, utopite se v globalnich promennych!!!
C je prece totez jako C++, ne? Kdyz se v C++ neutopite v globalnich promennych, proc byste se mel utopit v C? Struct a objekt je prece totez (az na viditelnost nekterych clenu).
To uz bych mohl klidne rict, ze v C++ se utopite v pretizenych operatorech (nebo tak neco).
Ale k veci: C++ je asi OK, zejmena s knihovnou blitz++ (jo, sablony jsou turingovsky silny makroprocesor; programovat bych v tom ale nechtel :-). C je taky OK, zejmena kdyz mate knihovnu linpack (nebo podobnou) vyoptimalizovanou pro konkretni architekturu sveho superpocitace.
-Yenya -
Jirka (neregistrovaný)Struktura a class jsou teoreticky to same. Na druhou stranu se podivejte na programy, ktere se bezne pisi. Vezmete si typicky vedecky software psany doktorandy v C a C++. Myslim, ze rozdil je hned patrny. V prvnim je zmatek kvuli globalnim promennym, v druhem je to lepsi, protoze jsou alspon schovane v tridach...
Co se tyce Blitz - je to asi dobra knihovna, ale rekl, bych, ze je pro vetsinu pouziti prilis slozita. Napsal jsem si neco podobneho jako http://www.nas.nasa.gov/News/Techreports/2000/PDF/nas-00-013.pdf a spokojenost nejvyssi...
Psat v linpacku je prima, ale nestaci na vse, to by muselo byt linpack+blas, blas ma silenou syntaxi... Navic pro male velikosti matice je linpack hrozne pomaly.
...Nejlepsi je kompilator na NEC SX-8, ktery rozpozna cast kodu, ktery lze nahradit volanim BLASu a nahradi ho optmalizovanou verzi pro vektorovy procesor... :-) -
"Struktura a class jsou teoreticky to same. Na druhou stranu se podivejte na programy, ktere se bezne pisi. Vezmete si typicky vedecky software psany doktorandy v C a C++. Myslim, ze rozdil je hned patrny. V prvnim je zmatek kvuli globalnim promennym, v druhem je to lepsi, protoze jsou alspon schovane v tridach..."
Pokud jde o globalni promenne, tak v C samozrejme neni jina moznost, to ale neznamena, ze se v tom hned utopite. Prostory jmen v C++ (podobne jako moduly ve Fortranu) proste jen brani konfliktum jmen pomoci name-manglingu, nic jineho v tom neni. To si v C muzete (musite) delat rucne.
Knihovny jako Blitz++ a uBLAS jsou dost dobre (syntaxe skoro tak komfortni jako Fortran,
rychlost +- stena), problem je ale
"Psat v linpacku je prima, ale nestaci na vse, to by muselo byt linpack+blas, blas ma silenou syntaxi... Navic pro male velikosti matice je linpack hrozne pomaly."
LINPACK je pomaly zejmena pro velke matice, kde ho LAPACK zaslape do zeme, diky blokove organizaci nekterych faktorizaci.
"...Nejlepsi je kompilator na NEC SX-8, ktery rozpozna cast kodu, ktery lze nahradit volanim BLASu a nahradi ho optmalizovanou verzi pro vektorovy procesor... :-)"
Tohle umi treba i gfortran (fexternal-blas). Obecne se to ale u level 1 operaci spis nevyplati (zvlast pokud je BLAS dynamicky prilinkovany), u level 2 nekdy.
Vtip je v tom, ze tech level 1 operaci by bylo potreba mnohem vic nez je v BLAS - to je
taky duvod existence Fortrani polni syntaxe, potazmo C++ knihoven Blitz++ a uBLAS. -
Pavel TišnovskýZlatý podporovatelTak s "globalnimi" promennymi v cecku zas takovy problem byt nemusi, jen clovek nesmi byt liny a napsat pred "globalni" promenne static a z globalni promenne je ihned pouze promenna modulu.
Kdyz jsou z tohoto modulu viditelne (= uvedene v headeru) pouze manipulacni funkce, da se v cecku bez problemu napsat i zdojak s nekolikaset tisici radky, vcetne spoluprace vic lidi. Samozrejme to neresi vse, napriklad multithreading zacina byt problematicky. Ale skutecne globalni promenne (viditelne pres vice modulu) nejsou v 99% pripadu zapotrebi, sam si pamatuji pouze pouziti sdileneho pole, ale i to slo nakonec resit rozumejsim zpusobem.
IMHO je idealni pouzivat neglobalni struktury, ktere se predavaji pomoci odkazu. Volani je pak rychle, vraceni hodnot vlastne zadarmo a syntaxe s "sipkou" je docela citelna. Malokdy se tak stane, ze je potreba predavat velke mnozstvi parametru, typicky dva az tri (prvni je struktura, ktera se zpracovava, druhy treba nejaky modifikator). No a pokud jsou struktury vytvoreny jako lokalni promenne, mame zadarmo i GC :-) -
Petr (neregistrovaný)Ohledne prvniho odstavce, myslim, ze jdete trochu mimo podstatu - mate samozrejme pravdu, ale podstata je jinde. Je rozdil mezi tim, co v jazyce lze napsat, a co v jazyce vypada "prirozene". To druhe nesouvisi jen se schopnostmi jazyka, ale i s tim, co se pise snadno, co hezky vypada a (pozor!) co existuje/je bezne v telese existujiciho kodu.
V C jsou globalni promenne prirozene. Singletony a thread-local singletony jdou napsat, ale pusobi to neprirozene - "jako byste psal C++ v C".
V C++ jsou prirozene singletony a globalni promenne tam vypadaji cize. V Jave je prirozene ze singletonu udelat registry pattern. -
Pavel TišnovskýZlatý podporovatelTo asi zalezi na vykladu slova "prirozene" a dopredu priznavam, ze ac Ceckar, tak delam i v dalsich jazycich, ktere me urcite ovlivnuji.
Pokud se napriklad podivam na hlavickovy soubor gl.h (OpenGL), je tam spousta #definu (=netypovane konstanty pouzite asi z duvodu zpetne kompatibility s prekladaci, ktere neznaji const), nekolik typedefu a potom uz jenom 100+ hlavicek funkci, ktere muzu volat a ktere mi popr. neco vraci. Zadna "extern" promenna, nic takoveho - veskera komunikace jde pres funkce, jsou tam samozrejme i klasicke settery a gettery.
To mi pripadne jako "prirozene" a logicky vytvoreny modul (zadna C++ovina ani Javovina, klasicky proceduralni kod :-)). I kdyz ho budu linkovat staticky, tak bych nemel mit problemy napriklad s kolizi jmen globalnich promennych ani neceho podobneho.
Narozdil on napriklad standardni ceckove knihovny, ktera nekolik externich promennych ma (errno), ale to se ukazalo jako problematicka vec. -
1. O tom nic nevím. Překladač Lahey umí překládat pro .NET, jinak jde všude o strojový kód.
Myslím, že nějaký fork GCC backendu, který bude překládat do Mono - takže pak to bude umět i Fortran.
2. Jasně, MPI pro Fortran je standard (binding je pro C/C++ a Fortran). Jinak existuje i cluster OpenMP od Intelu, což má být "power of MPI, ease of OpenMP". Ale zatím jsem neměl příležitost vyzkoušet. Už delší dobu existuje taky Co-Array Fortran, což je vestavěná paralelní notace pro Fortran. Je to fakt pěkné, bohužel to ale kromě superpočítačů Cray nikde není.
3. To rozhoduje víc věcí. Já doporučuju Fortran spíš na menší(?) projekty, na kterých budou dělat 1-3 programátoři. Trochu také záleží, čeho se má projekt týkat. Navíc Javu už umíte, to jí dává nezanedbatelné plus.
Obecně, pokud nejste připraven se potýkat s úskalími nového jazyka, nepřecházejte. Z toho pak vznikají na diskuzích přiblblé příspěvky typu (ten <dosaďte si jazyk> je strašnej šit, v <jiný jazyk> šlo tohle udělat normálně takhle...)
4. Fortress jsem komentoval už v diskuzi k minulému článku. Já jsem si pročetl specifikaci, zkusil jsem přeložit jednu dvě věci, a došel jsem k závěru, že až to bude trochu použitelnější, určitě to zkusím používat. -
mys elf (neregistrovaný)1. Knihovny psané ve fortranu se v Pythonu dají použít relativně snadno: http://cens.ioc.ee/projects/f2py2e/
-
. (neregistrovaný)1) Nastesti ne. Jde o to, ze jeden ze zakladnich rysu Fortranu (nebo i C, C++, Cobj, ...) je rychlost, male zatizeni pameti,... U C je to sice na ukor "bezpecnosti programovani" u Fotranu to tak ani zdalena neni. Ten ma v sobe radu techto "bezpecnostich mechanismu" zabudovanych. Je to sice na ukor omezeni pristupu treba k HW, ale to samozrejme pri pocitani nevadi.
("bezpecnosti" myslim ruzne udelatka znacne usnadnujici praci, znemoznujici buffer overflow, atd. Navic ma vetsina Fortranskych prekladacu kontrolu rozsahu pole, adres,....)
2) Samozrejme. Podpora jde tak daleko, ze jakykoli program prelozeny na dobrem prekladaci jde automaticky spoustet parallene. Vyuzije se to ale jen u programu, ktere pracuji s poli (to nas asi ceka priste).
3) Mam zkusenost, ze u velkych projektu je to nakonec smeska nekolika jazyku (urcite vyuzijete (ba)sh,... ), takze moje rada je matematicke vypocty ve Fortranu, ridici a graficke veci v C++. Obal shell.
4) Podle odkazu se jedna o jazyk, ktery neni urcen na masivni pocitani
a pravdepodobne nebude s Fotranem kompatibilni. Cili otazka je typu
"co si myslime o jazyku XXX". Odpoved: YYY. -
Mikuláš Patočka (neregistrovaný)> pro vyhodnocování výrazů a funkcí v nich platí ve Fortranu
> poněkud jiná pravidla než v C (a jeho potomcích). V C mohou
> funkce ve výrazech dělat cokoliv, protože lze přesně určit
> pořadí, v jakém se budou vyhodnocovat.
--- to není pravda, fixní pořadí vyhodnocování platí jen pro pár operátorů v C (&& || ?: ,), pro ostatní operátory je pořadí vyhodnocení nedefinované.
BTW. Platí v C to, že funkce se ve výrazu musí zavolat, i když na ní nezáleží? --- t.j. např. ve výrazu 0*f(), musí kompilátor zavolat tu funkci f()? Já myslím, že musí, ale nejsem si tím teď jist. (v případě && || ?: je specifikováno, že se to část, na které nezáleží, vyhodnotit nesmí, jak je to u ostatních operátorů --- musí se vyhodnocovat nebo mohou?)
Fixní pořadí vyhodnocování měl myslím Pascal (a kompilátory to z důvodu optimalizace umožňovaly vypnout). -
MeDon (neregistrovaný)>> BTW. Platí v C to, že funkce se ve výrazu musí zavolat, i když na ní nezáleží? --- t.j. např. ve výrazu 0*f(), musí kompilátor zavolat tu funkci f()? Já myslím, že musí, ale nejsem si tím teď jist.
Ja bych rekl, ze u aritmetickych operaci se zavoalt funkce musi. Jeji vysledek muze byt treba NaN (Not a number, trepa po deleni nulou), a pak je cely vysledek spatne. -
Jasně, mea culpa, tady jsem to trochu přehnal.
Podle C99 jsou sequence points jenom v logických operátorech, čárce a ternárním operátoru.
Zdá se mi to, nebo jich v C89 bylo víc? Ten teď nemám po ruce, takže to nemůžu ověřit.
Pokud jde o váš druhý dotaz, tak nemusí, pokud funkce nemá boční efekt. V C99 je to výslovně
zmíněno (někde na začátku). U knihovních funkcí to tedy zřejmě bude vědět, u uživatelských asi podle složitosti a stupně optimalizace. I kdyby to tam zmíněno nebylo, tak je to logické, protože když funkce nemá boční efekt, tak se vlastně nic nepozná. Tedy to pokud f() je int, float může mít něco jako NaN a Inf, které násobením nulou nedají nulu.
Překladač Fortranu má tedy tu výhodu, že to nemusí řešit (čili nemusí ji vyhodnotit, ani když má boční efekt). Fortran tak požaduje od programátora větší disciplínu. IMHO ale boční efekty
ve výrazech jsou celkem zavrženíhodné. -
mys elf (neregistrovaný)To není pravda, pořadí vyhodnocování je v C dost striktně určené: http://www.difranco.net/cop2220/op-prec.htm
-
mys elf (neregistrovaný)Odkaz, který jsem sem poslal, říká: "Their associativity indicates in what order operators of equal precedence in an expression are applied." Je fakt, že není možné aplikovat operátor na operandy, které nejsou dosud vyhodnocené, ale na druhou stranu samozřejmě není nutné, aby tyto operandy byly vyhodnocené v nějakém pevném pořadí. Spoléhat se na to nedá, to je pravda, takže jsem asi trochu mystifikoval (ikdyž bych si tipnul, že normální člověk by to pořadí asi dělal stejně podle té asociativity). Ale zase, pokud někdo spoléhá na toto pořadí a jeho funkce, jejichž návratová hodnota se používá v aritmetických operacích, mají tak brutální boční efekty, je to prase a dobře mu tak, když se spálí.
-
Pavel TišnovskýZlatý podporovatelIMHO tu funkci volat nemusi, protoze muze v ramci optimalizaci provest jeji "inlining" a potom treba zjisti, ze se jedna o konstantni vyraz. Nebo se ta funkce vola uvnitr smycky se stejnymi parametry (a nema vedlejsi efekt) - pri optimalizaci se ta funkce predpocita. Taky mam dojem, ze prekladac muze i podle normy vyhodit i cele bloky kodu, u kterych je zrejme, ze se stejne neprovedou (dead code elimination?).
U funkci, ktere maji vedlejsi efekty je to samozrejme jinak a u logickych vyrazu s && a || je zkracene vyhodnoceni primo predepsano (nekdy by se hodilo toto "vypnout" nebo mit dve sady operatoru ala Java, protoze treba v makrech to dela problemy). -
PaJaSoft (neregistrovaný)Domnivam se, ze i vyse uvedeny priklad po optimalizaci nemusi provest volani f(). Vzhledem k tomu, ze k zasadam cisteho programovani ma patrit i to, ze volani takove funkce nema mit vedlejsi ucinky na celkovy kod (a nedej boze na obsah stavovych promennych apod.) by to u vsech rozumne myslitelych bytosti (ktere si chteji zachovat dusevni silu) nemelo vadit...:-)
Obecne bych problem spise videl v tom, jak automatizovane poznat, ktera vypustka vadi a ktera ne... - bud proste optimalizujeme konstrukce tohoto razu (kdekoli) nebo ne.
PS: A uz bych se vubec do techto uvah nepoustel z titulu chybovosti prekladacu. To, ze to 100x na exemplarnim prikladu zkusim a prelozim a ono to konstrukci prelozi dle ocekavani vubec neznamena, ze pri 101. prekladu to cele nedopadne jinak. Ostatne, kernelovi programatori by mohli vypravet... (a zdaleka nejen oni) -
Jirka P (neregistrovaný)f(): Musí se vyhodnotit, pokud kompilator nezjisti, ze se to nepozna. gcc ma k tomu __attribute__((pure)) a __attribute__((const)) [a samozrejme se to da videt z (inlinovanyho) kodu]
Celkem nedavno jsem videl nejaky standard Pascalu, kde bylo poradi vyhodnocovani parametru funkci nespecifikovane. Jak je to s vyrazy nevim.
MMCH jak je to presne v C se sequence pointy? Standard C neznam, mam jen C++ a dejme tomu
a++; b++;
je v C++ mozno vyhodnotit v jakemkoli poradi, pokud obe vedou ke stejnemu vysledku (a a, b nejsou volatile a nejde o volani funkce). -
. (neregistrovaný)CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
C
C No F90 pouzivam leta, ale takovahle nalivarna prekvapila i me.
C Behem druheho dilu na nas vybalit pure procedury a optional
C parametry me vazne vyrazilo dech. Predstavoval jsem si neco takoveho
C jako uvodni kapitolu z Hrebicka (takova ta klasicka ceska kniha
C o F77) nebo druha kapitolka z K&R. Vetsina lidi, kdyz jim to vykladam,
C tak ma problemy spise s vypsanim neceho na obrazovku s tim,
C jak se to preklada.
C
C Jinak dobry, drzim palce, neco takoveho uz to chtelo.
C
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC -
Tak nejsem si jistý, ale budu to brát jako pochvalu :)
Tohle neměl být ani tutoriál k Fortranu, tím méně příručka nebo učebnice. Já chtěl hlavně
Fortran představit jako moderní jazyk (viz perex prvního dílu), místy porovnat s ostatními jazyky, vyzdvihnout zajímavé (podle mě) schopnosti, zmínit historické souvislosti a zajímavosti,
prostě takový přehled "co to umí". -
PaJaSoft (neregistrovaný)Ta perlicka se zamenou tecky a carky se bohuzel stala i v realu v NASA (a nejsou to prusery typu metricke vs. jine jednotky) a dusledkem toho raketa, ktera se mela dostat na orbit se spokojene vratila k Zemi, kde shorela a timto aktem pohrbila cely jeden vyzkumny program...
-
Ano, to je známá legenda (urban legend). Já už to kdysi vyhledával na webu a vím, že to není pravda. Přestože tato chyba v softwaru NASA (Mercury) skutečně byla, sonda Mariner 1 kvůli ní nespadla, jak se často tvrdí i v některých knížkách. Mariner havaroval kvůli logické chybě (chybně přečtený rukopis algoritmu). Mercury byl v téže době používán v jiném projektu, a přikrášlením skutečnosti zřejmě došlo k záměně.
