Zasto to mislis?
Program mozda i nije, ali kod bi morao biti - naravno ako je pisan pod standardom.

Nativni program za windowse u pravilu ne radi na linuxu. Ne radi, ali postoje emulatori...


Kako mislis povezati Javu s C-om? Pitam jer vrlo slabo poznam Javu.

Neces moci da imas jedan binarni fajl (izvrsni) - tako da ces morati da razdvojis distribucije softvera za Windows i Linux u 2 paketa - Windows distribucija bi se sastojala od tvog Java softvera + jednog Windows DLL fajla, dok bi Linux ekvivalent bila Linux biblioteka.

Osim ako ne planiras da distribuiras program kao open-source, za sta je onda potrebno da imas makefile ili 2 makefile-a kako bi korisnici mogli da kreiraju binary za oba sistema.



Moze, preko JNI-a (Java Native Interface)

@NrmMyth
Ivan Dimkovic ti je već odgovorio. JNI nisam koristio, ali znam čemu služi i eto, kad dođe vreme, koristiću ga. Btw, C je "extension language" za većinu programskih jezika, pa i za Javu.

@Ivan Dimkovic
Moram da razdvojim binarne fajlove, čak i ako su u njima samo tako jednostavne stvari kao što su obični matematički proračuni?

moj predlog ti je da koristis scons kao build sistem za c deo koda (http://www.scons.org/) i da se drzis standardne c biblioteke koliko je moguce, time povecavas sansu da izbegnes glavobolje oko portabilnosti. interfejs ka javi ne bi trebalo da bude problem ukoliko budes oprezan oko tipova i koristi -Xcheck:jni, ume da smanji glavobolje.

_{[Ovu poruku je menjao caboom dana 18.10.2006. u 16:50 GMT+1]}

Scons. Stvari kao da počinju da se preterano komplikuju. btw, @caboom, hvala na odgovoru, ali mislim da nisam trenutno spreman da se nešto mnogo petljam sa stvarima koje su daleko od Jave (i C-a).

Ako ti treba brzo i jednostavno resenje, onda ako ces da koristis samo standarden C biblioteke, prevedi C program za Vindouz i Linuks platformu i distribuiraj oba u jednom paketu ako nisu znacajno velika ili ih zajedno sa programom podeli u dva zasebna paketa za te dve platforme.

Ipak, iako nije uputno postavljati pitanje na pitanje :) interesuje me da li si siguran da ces dobiti znacajno ubrzanje?
Da se odmah ogradim, ne znam sta bi program konkretno trebao da radi, ali ako ta izracunavanja radis u C-u, onda ces da koristis ugradjene (primtivne) tipove podataka int, float, double... i/ili mozda neke strukture, zasto onda ne bi pokusao da koristis ugradjene (primitivne) tipove podataka i u Javi umesto klasa Integer, Float, Double... koje bi verovatno u nekoj meri usporile izvrsavanje "kriticnih" delova programa, jer iako nemam dugo iskustvo u radu sa Javom, mislim da u ovom konkretnom slucaju, pisanje zasebnih funkcija u C-u verovatno ne bi bilo mnogo isplativije, kada se uzmu u obzir i drugi cinioci (npr. konzistentnost i odrzavanje programa) nego kada bi to isto uradio u Javi.
Najbolje bi bilo da ako imas vremena (i volje) pokusas i jedno i drugo resenje (mozda sa manjim "modelima") i da onda vidis ciji ti odnos dobitaka i gubitaka najvise odgovara.

@Milan Aksic
Obe varijante koje si naveo u prvom pasusu dolaze u obzir. Već sam razmišljao o tome.

E sad, da li je OK da sve bude pisano u Javi? Mogu da ti kažem da sam i sam iznenađen brzinom kojom radi Java. Svojevremeno sam napisao obimnu web-aplikaciju u kojoj je bilo dosta proračuna, na osnovu kojih su se generisale neke slike. Podatke sam držao u kolekcijama, pa sam morao često da radim konverziju u primitivne tipove. Vodio sam računa o tome da što više koristim redove a što manje kolekcije, ali sam ipak morao i jedno i drugo. Za divno čudo, sve je radilo prilično brzo. Doduše, uvek sam se pitao kako li će to da radi kod ISP-a, ali mi je jedan ortak malo olakšao brigu rekavši mi da to nije moj problem, već je to problem ISP-a. I nije bilo problema, sajt nije bio preterano posećen (koga je briga za tehniku) pa je sve bilo OK.

A sad, o temi. Proračuni kojima nameravam da se bavim su neka light varijanta metode konačnih elemenata, tj. veoma uprošćen model sa ne baš preterano velikom diskretizacijom. Koliko brzo bi to Java obavila ne znam, ali znam da se za te proračune koriste C ili Fortran, pa sam i ja hteo da to uradim kako valja. Mada, s obzirom na to da je reč o desktop aplikaciji, probaću da što više izvučem od Jave, pa ako budem zadovoljan brzinom, neću ni da probam da to radim u C-u. Interesovala me je pre svega portabilnost C-a za takve stvari, ali pošto od toga nema ništa, nisam siguran da bih ću da se trudim oko njega. Ako mi baš bude frka, naći ću nekog da mi to napiše u C-u i kompajlira, jer taj deo koda ne bi trebao da se menja kad se jednom napiše.

Sve zavisi od veličine matrice. Ako je dovoljno mala, Java može da bude sasvim OK. Ako ne, ozbiljno razmisli o Fortranu. Za numeriku je Fortran i dan danas ubica. C ne može ni da mu priđe.

Slažem se. Fortran je No1. Nego ja treba da napravim i neki korisnički interfejs, a to znam samo u Javi. C++ ne znam.

Malo sam google-ovao i video da su još 1998/99 ljudi pokušali da Javu prilagode za numeričke proračune. Tako su u samoj Javi napisane neke klase koje su značajno ubrzavale proračune u odnosu na tadašnju Core Javu 1.2. U samom startu su iza toga stajali IBM i Sun, tako da verujem, mada još nisam naišao na takav zaključak, da današnja Java u potpunosti implementira predložena, a možda i bolja rešenja. To bi praktično značilo, da je Java po performansama za numeriku, u najgorem sličaju za oko 35% sporija od optimizovanog koda za Fortran. To je za mene sasvim zadovoljavajuće. Pogledajte to ovde: http://researchweb.watson.ibm.com/journal/sj/391/moreira.html Članak je iz 2000. godine. problem sa javom i dalje je veća potrošnja memorije nego kod npr. Fortrana ili C-a, ali nebitno, ima ona mnogo svojih prednosti.

Uf, kako ovo zvuci malo cudno :). Da si rekao da u fortranu ima puno libova a numericke proracune, pa da si rekao da je gomila libova za razne proracune napisano u fortranu, ali ne mozes me nikako ubediti da ce program koji prevede neki fortran biti toliko brzi od programa koji prevede c :).

A na stranu sto vecina tih libova ustvari samo zaobilazi cinjenicu da je fortran IV imao samo jednodimenzionalne nizove, pa su emulirali matrice na razne nacine :).

Ali u svakom slucaju bas bi voleo da vidim neki citat gde se spominje to da je fortran bolji :))).

A inace sto se tice portabinosti, kositi samo stabdradna zaglavlja i ...

@chupcko
Mada nisi mene citirao, komentarisaću samo ukratko da sam ja na puno mesta nailazio na neke uporedne dijagrame koji su prikazivali brzinu Jave u odnosu na Fortran i C i uvek je Fortran bio nešto malo bolji od C-a. Takođe, pošto je cilj bio da se pokaže razlika u brzini u odnosu na Javu, uvek je postojala i napomena da je reč o optimizovanim kodovima za C i Fortran. Na taj način, mogao je da se stekne utisak o maksimalnoj razlici između primene Jave sa jedne strane i C-a i Fortrana sa druge strane za numeričke proračune.

Pa i očekivao sam da ako se koriste standardna zaglavlja, da bi to možda i moglo da bude portabilno, ali sam ipak morao da pitam.

Kad sam radio u jednoj laboratoriji gde smo razvijali FEM aplikacije, merili smo C i Fortran i "starac" je razbio C (čisto da razjasnim: svi mi smo "navijali" za C). A ako hoćeš "naučno" objašnjenje zašto je tako, pogledaj sekciju b) ovde: http://www.ibiblio.org/pub/languages/fortran/ch1-2.html Posebno značajna stavka je tzv "aliasing" koji je dozvoljen u C-u i onemogućava neke vrlo bitne optimizacije.

Da, ti libovi su takodje jedan od razloga ali i pored toga ako imas liboce napisane u C-u, cesto oni napisani u Fortranu rade brze.



Evo citata:



Salu na stranu, radio sam jedno biolosko istrazivanje gde se koristilo dosta numerickog procesiranja slika sa elektronskog mikroskopa i uvek su brzi bili programi koji su bili napisani u Fortranu. Makar je takvo moje iskustvo.

Pa da, ali opet ponavljam nije ga razbijao, razbiti znaci da je nesto brze barem 2 puta.

Naravno postavlja se pitanje kada je radjeno to istrazivanje i da li je radjena optimizacija :).

E sada, nemojte samo da se javi neko ko ce reci : daaaaaa fortran je brzi i od assemblera :)).

Mada pouzdano i danas znam ljude koji rade neke proracune na fortranu :))), eh ti libovi.

Inace u onom poucnom linku pise da je lakse razvijatu u fortranu nego u c-u, ali ajde, neka bude da je fortraaaaaaaaan nadmocniji puno.

Ali ajde ovako, ako neko bas zeli da me ubedi, neka napise neki lib na fortranu, neki lib u c-u, pa da iskompaliramo sa f77 i gcc, pa kom opanci tom i jeri.

P.S. Da ne bude zabune moj prvi jezik na kojem sam radio je fortran IV.

Nije nikakva posebna mudrost potpuno zaobići problem aliasinga za matrice i vektore u C/C++.
Kada se to jednom reši, fortran može da se pozdravi sa vođstvom!
Problem je u programerima, ne samo u jezicima koje koriste...

U principu mi mozemo za sve da koristimo inline assembly code pa da nam bude skoro isto brzo ali nije u tome poenta. C++ i C nisu pravljeni da budu kao Fortran specijalizovani za numericke operacije. Recimo do c99 standarda nisi imao kompleksne brojeve a u C++-u ih imas ali koriscenjem template-a zbog cega ti sve bude dosta sporije nego da su kompleksni brojevi ukljuceni odmah u sam jezik. Slicna razlika postoji i u D-u i C++-u sto mozes da vidis ovde:
http://www.digitalmars.com/d/cppcomplex.html.

Žao mi je što nema nigde (koliko znam) on-line verzija knjige "Design and evolution of C++" u kome je Dr Stroustrup napisao jedan lep paragraf na ovu temu.

U svakom slučaju, on tvrdi (parafraziram) da je prednost Fortrana u odnosu na C i C++ u numeričkim proračunima od 50% do 35 puta (jeste, 35x) zavisno od hardverske arhitekture na kojoj program "trči".



Bojim se da će neko drugi morati da te ubeđuje. Nisam pipnuo Fortran od 1998 i nemam nameru da ga sad obnavljam.

:))))))))) Dobro, a da li je neko ukljucio zdrav razum malo :))).

Ajde da je brzi 35%, moze, ali 35 puta :)))).
Pa ajde da je poredjen fortran i java, mozda bi to i moglo da prodje, ali ipak , pricamo o c-u.
Ne uzimam sada u pozmatranje c++, kod koga mozda i moze da bude 35 puta sporije, ali pricam o c-u.

Jednostavno, sistem prevodjenja koji se koristi u fortranu i koji se koristi u c-u nije bitno razlicit. Naravno evo ja cu postaviti jaku tezu:
za svaki proracun koji neko napise u fortranu ja pisem barem jednako brzu u c-u :).

Apropro teze da je fortran pravljen za numericke proracune ?, izvini ali ne mozete me ubediti da je u fortran ugradjen neki super cudno brzi object kod, a da u c nisu mogli nikako to da ugrade ;))). Ako pak neko zna neku instrukciju neka je podeli sa nama :))).

Ali dobro, ovde definitno postoje ljudi koji veruju u bajke i to da je neki programski jezik toliko carobaaaaan :), tako da cu dok ne dobijem neke konkretne rezultate samo da posmatram nemo :).

50% od C-a, 35 puta od C++-a. Moze li tako? I vuk sit i ovce na broju...

Konkretno u vezi pointer aliasinga, C99 propisuje strict aliasing pravilo po kojem dva pointera različitog tipa ne mogu pokazivati na istu lokaciju u memoriji, te ključnu riječ restrict, koja zahtijeva da pointeri istog tipa ne pokazuju na "preklapajuće" memorijske segmente.

PS: Navodno jedino SISAL ima komparabilne/bolje number crunching performanse od FORTRAN-a na multiprocesorima.

"Design and Evolution of C++" 6.5.2:

"A Fortran compiler is allowed to assume that if a function is given two arrays as arguments, then those arrays don't overlap. A C++ function is not allowed to assume that. The result is an advantage in speed for the Fortran routine of between 15% and 30 times dependent on the quality of the compiler and the machine architecture. The spectacular savings come from vectorizing operations for machines with special vector hardware such as Crays."

Dakle nije 35 nego "samo" 30 puta. Ako ne veruješ Dr Stroustrupu koji je poznati obožavalac Fortrana i mrzitelj C++a, nađi Cray pa isprobaj sam :)

Eh, da, dakle ti si iz vremena Cray-a :), na koliko bese radio ono Cray, bese nesto reda velicine 450MHz :)))). Naravno vektroski.

Dakle ne mesati C i C++, pod jedan :).

Cisto da ne bude zabune, moze neko da napise i u C-u los program koji ce se izvrsavati 1000 puta sporije, ali to ne znaci da je jezik los :).

Ajde malo da priupitam pcelice, recimo nesto tipa a=sin(x), da li iko veruje da ce to da se u fortranu izvrsava mnogo puta brze nego u C-u ?
Zar zdrav razum ne nalaze da ce to da se prevede u odgovarajuci veoma slican niz instrukcija :)

Mada, ko zna, mozda vi uporno uporedjujete fortran na recimo nekom klasteru i c na mobilnom telefonu :))).

Kod vektorske mašine jedino bitno je da su petlje vektorizovane. Ako se kompilatoru učini da tu može postojati neka zavisnost, pa ne vektorizuje petlju, odoše performanse bestraga. To je ova gornja granica, 30-ak puta sporije, itd. Mada ne toliko drastično, ovo je bitno i kod običnih RISC procesora, te se pri prevođenju proračunskog C/C++ koda obavezno kaže kompilatoru da nema preklapanja. Npr. -fargument-noalias-global za GCC i -fno-alias za ICC.

Što se tiče ove donje granice, od 15%, to može da bude svašta, ali je najpre do više uloženog truda u razvoj fortranskog kompilatora. Posebno za superračunaljke, proizvođač može sebi da dozvoli (ili je, hm, bar mogao ranije) da nema baš najbolji kompilator C-a, dok na Fortranu ne sme da se oklizne — probni kodovi, na osnovu kojih se odlučuju kupovine, su mahom fortranski :)

Ono što stoji, međutim, da zbog te svoje veće ograničenosti, u Fortranu je teže napisati spor kod nego u C-u, o C++u i da ne pričamo :) Uvek mi ovde padne na pamet slično poređenje između Lispa i C-a negde sa početka 90-ih (http://www.naggum.no/worse-is-better.html). Tu se navodi primer dva lispovska koda za sabiranje matrica, gde je jedan brz koliko i C ili fortranski (verovatno u smislu tadašnjeg stanja optimizacionih kompilatora), a drugi načisto katastrofalan. Autor teksta zaključuje: „In Lisp it is very easy to write programs that perform very poorly; in C it is almost impossible to do that.“

E sad, ovo otvara jedno zanimljivo pitanje. Kao što se ne mogu posmatrati kompilatori zasebno, već samo u kombinaciji sa platformom (npr. na Itanijumu je sve osim Intelovih kompilatora neprihvatljivo), tako ne vidim zašto se u to ne bi faktorisao i čovek, odnosno programer. Mislim da su u današnje vreme veće šanse da C-programer napiše efikasan kod nego fortranski programer, potirući izvesne male prednosti koje bi fortranski kompilator mogao da ima nad C-ovskim. Tako da bih se ja ovde kladio na Čupka, kad već ne preza od „jakih teza“ :)

Ja mislim da nisu veće šanse da C programer napiše brži kod od fortran programera, pre svega zbog
kvaliteta većine C programera. Ukoliko se razlika u brzini svodi na aliasing, C će lako biti uvek brži uz
dobrog programera. Ukoliko razlika potiče od toga da fortran na Cray-u podržava malo više feature-a
hardvera, kao na primer ključni - vektorski, onda je poređenje skroz pogrešno.
Ako bi dodali asm rutine za podršku vektorskom proračunu, dobija se mnogo poštenije takmičenje.

Poređenje transformacije homogenog vektora na papiru:
Ne vektorski kod: 16 množenja i 12 sabiranja
Vektorski kod: 4 specijalizovane instrukcije.

Iz ovoga je kristalno jasno da ako postoji podrška za vektore da će razlika u brzini biti ogromna...
Još ako HW podržava ekstrakciju kolona i vrsta matrice, onda će recimo množenje matrica biti
daleeeeko brže sa vektorskim kodom.

Pitam se šta bi bilo kada bi C kompajler dobio vektorsku podršku :)

„Vektorski“ u smislu Kreja, Hitačija i sličnih vektorskih računaljki, znači samo to da procesor može da uradi mnogo više paralelnih („vektorskih“) FP operacija po taktu (npr. 16 na SX6 prema 2 na P4), uz abnormalno brzu glavnu memoriju da usluži takvu potrebu (keševa nema uopšte).

Cenim da Toša ovde ima na umu vektorizaciju u smislu baratanja 3D grafikom. Čak i u tom slučaju, „ispod haube“ uvek mora da se odradi isti broj osnovnih operacija (sabiranje, množenje...). Tako da su fantomski rezultati što ih čujem za današnje GPUove posledica njihove unutrašnje arhitekture, verovatno nalik na opšte vektorske mašine (uključujući i brzu memoriju na kartici). Štaviše, specijalizovane instrukcije mogu biti i kontra-produktivne (ako bi postojao odgovarajući optimizujući kompilator), zbog čega opšte vektorske mašine i nemaju nikakve specijalizovane instrukcije.

U vezi poređenja Fortrana i C-a, svakako je svejedno, jer se misli na onaj prvi smisao, opštu vektorizaciju odnosno kompilatore koji to mogu da odrade. Skoro je jedan kolega optimizovao C-kod za SX6, i po rezultatima se jasno videlo da je Hitačijev C-kompilator pravilno vektorizovao kod, kao što bi i fortranski uradio.

Da, pričao sam o 3D grafici. "Ispod haube" se ne dešava ista stvar, pre svega zato što
HW korišćenjem specijalizovanih instrukcija može da napravi neke pretpostavke.
Ukoliko bi funkcionalnost bila ista, verujem da se HW vendori ne bi ni zamarali pravljenjem dodatnih
instrukcija već bi pravili assemblerske makroe, kao što već postoje za neke operacije na GPU-ovima.

Primera radi, mašina na kojoj sam radio do skora ima dot product instrukciju koja traje tri ciklusa dok
je množenje jedan ciklus. Pored očigledne razlike od 25% u korist specijalizovane instrukcije, rezultat
nije identičan. Razlika je u tome da je HW reorganizovao operacije u slučaju dot product-a i vide se
razlike u decimalama zbog preciznosti float brojeva.

Da li imaš neki primer gde je specijalizovana instrukcija kontra produktivna?
Veoma sam radoznao da čujem..

ahaaaaa, sada sam shvatio najzad kako je fortran brzi od c-a, ako se koriste vektorski procesori i specijalizovan fortran kompajler onda je brzi nego obican c kompajler.

To me malo podseca na one trke konja i voza na divljem zapadu. A i znate sta, primetio sam da je moj fortran program za mnozenje matrica koji se vrti na masini od 3GHz 10 puta brzi od istoradeceg c progarma koji se vrti na masini od 233MHz. Zakljucak, fortran je 10 puta brziiiiiiii :).

Čekaj, ovo mi nije jasno. Problem sa aliasingom je u tome što C kompajler ne sme da pretpostavi da ga nema i ne može da izvrši određene optimizacije, dok Fortran kompajler može. To nema veze sa programerom, već isključivo sa programskim jezikom.

Doduše, ovaj deo priče je već udaljavanje na kvadrat od teme, ali kad sam lupao, sad moram da se vadim :)

Odmah da napomenem da nemam tri blage sa bilo kakvom grafikom. Ono što mene zanima, mada trenutno samo izokola i informativno, jeste (zlo)upotreba GPUova u opšte računske svrhe (npr. www.gpgpu.org).


Da bi se izračunao skalarni proizvod n-vektora, svakako moraju da se izvrše n množenja i sabiranja. Odnosno, činjenica da specijalizovana instrukcija radi brže i daje bolji rezultat ne znači da je ona dobra, već da nešto „nije u redu“ sa običnim instrukcijama.

Problem sa komplikovanim atomskim instrukcijama je baš u tome što moraju da se izvrše tako kako su zamišljene, dok sa malim brojem jednostavnih instrukcija kompilator ima mnogo više mogućnosti da ih optimalno iskombinuje (u stvari, klasična CISC pr. RISC priča).

Međutim, razvijanje takvih kompilatora je dugotrajan proces (rekoše mi da je trebalo preko dve godine da Intelovci razviju razuman kompilator za Itanijum). Pošto tako nešto nije prihvatljivo za današnje GPUove (svakih 6-12 meseci novo?), onda je verovatno bilo isplativije osloniti se na specijalizovane instrukcije kao međurešenje. Naravno, vrlo je povoljna i činjenica da mogu da budu fokusirani na usku oblast primene.


U vezi sa grafikom, ni slučajno :)

Off topic:
(Fortran vs C)

U jednom razvojno/istraživačkom centru (uglavnom koriste M$ C/C++):
http://www.csk.kg.ac.yu/
...sa kojom imam saradnju, iskustva su da je Fortran značajno brži od C-a. Rade dosta FEM.

Imaju i klaster mašinu:
http://www.csk.kg.ac.yu/csk_sr/index_sr.htm
... i mnogi njihovi proračuni "rade" danima, pa im nije bilo teško da izvuku merodavne rezultate.

Meni je sve to u početku bilo neobično, ali definitivno je tačno.

Ima veze sa programerom zato što programer može da pretpostavi da li će biti aliasinga i da promeni kod da to spreči.
Čak ne mora ni da pretpostavlja, može da pogleda asm listing i da vidi šta se dešava.
Ima više knjiga koje se bave ovom tematikom kada pričaju o optimizacijama.


Ne koriste se pomenute operacije samo za 3D grafiku već i za razne vrste simulacija.
Možeš mi dati bilo koji primer specijalizovane instrukcije koja je kontra produktivna,
naravno uz odgovarajuću argumentaciju, smajli nije dovoljan.


Iznenađujuće je nizak kvalitet programerskog kadra na našim univerzitetima.
Meni je to dovoljan razlog da njihove rezultate čak i ne pogledam.
Da se ponovim, na osnovu čega je bazirana ta analiza? Jednostavnim nabacivanjem koda u jednom i drugom jeziku
se ne može praviti poređenje. Potrebno je da se to uradi propisno. Svima je jasno čemu fortran služi i da će
out-of-the-box dati bolje rezultate za neke proračune, ali uz malo specifičnih znanja taj isti fortran bi bio kao kornjača u odnosu na C (zec).

(gleda kako da se izvuče) A dva smajlija ako stavim?

Kao što pokušah da kažem, pitanje je više hipotetičko: ako bi postojao odgovarajući optimizujući kompilator, onda bi svakako specijalizovane instrukcije više odmagale nego pomagale. Stoga je rezonovanje čisto posredno i na osnovu dosadašnjih trendova u razvoju, očigledno se ne može proveriti kao takvo.

Npr. onaj test kojim određuju Top 500 listu superračunara, LU dekompozicija matrice. Npr. http://www.ics.psu.edu/fallnotes/Kunz_Lecture_1.pdf, slajd 17, pokazuje oko 90% dostignutog teoretskog plafona performansi za dati vektorski procesor (što je donja granica, jer se radi o celom postrojenju, te su uključeni i troškovi komunikacije).

S druge strane, http://gamma.cs.unc.edu/LU-GPU/lugpusc05slides.pdf daje fino upoređenje istog problema na P4 i Envidijinim 6800 i 7800 karticama. Osim u jednom slučaju, gde uspevaju da povuku performanse na konto inače neiskorišćenog memorijskog protoka (slajd 38), performanse 6800 su tek u rangu P4-vorke (slajd 36, 37). P4 pritom dostiže oko 50% sopstvenog teoretskog plafona (slajd 7), što izađe na nekih 12 GFLOPS (prema slajdu 10). 6800 onda pri oko 12 GFLOPS (ili nešto bolje) ne dostiže ni dvocifreni procenat svog teoretskog plafona (slajd 10, doduše daje podatke za 7800).

(Inače, ovo ne znači da je tu nešto razočaravajuće, za cene kartica takve kakve su. Onaj vektorski procesor odozgo košta đavo i po — mada je sada već mator, ali i njegov savremeniji, duplo brži naslednik isto košta đavo i po — da bi mogao da bude i opšta računaljka i zaista isporuči teoretski plafon. Zato se i polomiše oko primene GPUova u opšte računske svrhe, i zato i mene interesuje na šta će to da izađe...)

Drugi primer je Itanijum, baš poznat po tome što su ga napravili da bude glup ko panj, da izvršava program bez filozofiranja. Nikakve specijalne instrukcije, nikakvo hardversko preuređivanje redosleda ili predohvatanje podataka iz memorije, niti ostale pikanterije koje imaju P4 ili Opteron. Zato je Intelovcima trebalo (kako čuh) preko dve godine da dorade kompilator koji je Itanijum konačno ostvario kao onakvu računaljku kakvom je zamišljen (npr. slajd 16 u prvom dokumentu).

Na žalost ne mogu da sada pronađem tekst/članak/šta god u kome se porede GPU i p4, gde GPU bije p4 preko dvadeset puta.
To je samo zanimljiva statistika i dalje, budući da preciznost GPU-ova tek dolazi na nivo CPU-a.


Na ovakve izjave sam mislio kada sam tražio argumente. Postoje optimizujući kompajleri i jedna od stvari koju rade je
da koriste specijalizovane instrukcije. Ne pričamo ovde o java-i i sličnim bljuvotinama od jezika, koje nisu native pa
kao takve imaju daleko manje šanse da koriste te instrukcije (čitaj nikakve).

Naravno, ali ako idemo do tog nivoa, poređenje kompajlera pomalo gubi smisao. Poenta je da sa Fortranom nema šta da misliš o aliasingu.

A moja poenta je da korisnici fortrana ne misle dovoljno, al' njihov izbor :)

CLR (.NET runtime) JIT kompajler već odavno emitira SIMD kod i za najtrivijalnije vektorizabilne operacije (zainteresiranima preporučam igranje sa cordbg.exe), i općenito sve moderne virtualne mašine utiliziraju jedan cool thingie zvan dinamička rekompilacija koji im omogućuje optimiziranje bottleneckova programa po potrebi.



Poanta VLIW arhitekture i jest da procesor bude no-brainer, da offloada gomilu redundancije koja postoji na relaciji kompajler - CPU pipeline, tako da umjesto da 80% tranzistora bude zaposleno time da održe pipeline cijelo vrijeme pun (kao što rade svi moderni RISC/CISC-ovi sjeckanjem instrukcija u microops, analizom njihovih ovisnosti, reschedulingom, OOO izvršavanjem slobodnih operacija u poolu lalala....što u konačnici kao posljedicu ima fiksnu teoretsku gornju granicu od 4-way instruction-level paralelizma :), jednostavno izvršava kod koji je unaprijed optimiziran za vrijeme kompajliranja.

Problem je što je pisanje optimizirajućih kompajlera za takvu arhitekturu užasno teško. Imaš (za akademske građane besplatan!) Simics emulator koji podržava IA-64 (možeš skinuti predinstaliran linux image), probaj u njemu napisati ijedan netrivijalan algoritam u IA-64 asembleru pa da vidiš kako je to bolesno :)

I BTW, Itanium ima instruction prefetching.