Vlákno názorů k článku Fortran: základní konstrukce jazyka od agfa - Zdravim, delam program pro vedecke vypocty v Jave....
-
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.
