[es] - Portabilnost C-a

cynique
Ivan Štambuk
Zagreb@Croatia

Član broj: 93690
Poruke: 155
193.198.17.*

ICQ: 106979934
Sajt: istambuk.blogspot.com

Profil

Re: Portabilnost C-a

^{24.10.2006. u 15:11 - pre 213 meseci}

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.

Put the funk in funktion.

Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
65.213.80.*

+6 Profil

Re: Portabilnost C-a

^{24.10.2006. u 17:09 - pre 213 meseci}

Citat:

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

Ajde da je brzi 35%, moze, ali 35 puta :)))).

"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 :)

IOCC

Odgovor na temu

chupcko
Negde
Beograd

Član broj: 5560
Poruke: 1141

Sajt: www.google.com

+63 Profil

Re: Portabilnost C-a

^{24.10.2006. u 19:55 - pre 213 meseci}

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 :))).

CHUPCKO

Odgovor na temu

Časlav Ilić
Braunšvajg, Nemačka

Član broj: 4945
Poruke: 565
*.lstm.uni-erlangen.de.

+27 Profil

Re: Portabilnost C-a

^{24.10.2006. u 21:20 - pre 213 meseci}

Citat:

"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 [...]"

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“ :)

Odgovor na temu

tosa
上海，中国

Član broj: 1811
Poruke: 1342
222.64.102.*

ICQ: 14293955
Sajt: https://github.com/milost..

+48 Profil

Re: Portabilnost C-a

^{29.10.2006. u 03:46 - pre 213 meseci}

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 :)

Odgovor na temu

Časlav Ilić
Braunšvajg, Nemačka

Član broj: 4945
Poruke: 565
*.lstm.uni-erlangen.de.

+27 Profil

Re: Portabilnost C-a

^{29.10.2006. u 11:40 - pre 213 meseci}

Citat:

tosa: 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.

„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.

Odgovor na temu

tosa
上海，中国

Član broj: 1811
Poruke: 1342
*.ubisoft.com.cn.

ICQ: 14293955
Sajt: https://github.com/milost..

+48 Profil

Re: Portabilnost C-a

^{30.10.2006. u 04:49 - pre 213 meseci}

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..

Odgovor na temu

chupcko
Negde
Beograd

Član broj: 5560
Poruke: 1141

Sajt: www.google.com

+63 Profil

Re: Portabilnost C-a

^{30.10.2006. u 10:04 - pre 213 meseci}

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 :).

CHUPCKO

Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
65.213.80.*

+6 Profil

Re: Portabilnost C-a

^{30.10.2006. u 15:49 - pre 213 meseci}

Citat:

tosa: Ukoliko se razlika u brzini svodi na aliasing, C će lako biti uvek brži uz
dobrog programera.

Č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.

IOCC

Odgovor na temu

Časlav Ilić
Braunšvajg, Nemačka

Član broj: 4945
Poruke: 565
*.lstm.uni-erlangen.de.

+27 Profil

Re: Portabilnost C-a

^{30.10.2006. u 19:35 - pre 213 meseci}

Citat:

tosa:
"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 [...]

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).

Citat:

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 ako se porede rezultati.

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.

Citat:

Da li imaš neki primer gde je specijalizovana instrukcija kontra produktivna?

U vezi sa grafikom, ni slučajno :)

Odgovor na temu

X Files
Vladimir Stefanovic
Pozarevac

SuperModerator
Član broj: 15100
Poruke: 4902
89.216.236.*

Jabber: xfiles@elitesecurity.org

+638 Profil

Re: Portabilnost C-a

^{30.10.2006. u 20:06 - pre 213 meseci}

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.

Odgovor na temu

tosa
上海，中国

Član broj: 1811
Poruke: 1342
218.82.252.*

ICQ: 14293955
Sajt: https://github.com/milost..

+48 Profil

Re: Portabilnost C-a

^{30.10.2006. u 23:43 - pre 213 meseci}

Citat:

Dragi Tata: Č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.

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.

Citat:

Časlav Ilić: U vezi sa grafikom, ni slučajno :)

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.

Citat:

X Files: 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.

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).

Odgovor na temu

Časlav Ilić
Braunšvajg, Nemačka

Član broj: 4945
Poruke: 565
*.lstm.uni-erlangen.de.

+27 Profil

Re: Portabilnost C-a

^{31.10.2006. u 01:15 - pre 213 meseci}

Citat:

tosa: 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.

(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).

Odgovor na temu

tosa
上海，中国

Član broj: 1811
Poruke: 1342
*.ubisoft.com.cn.

ICQ: 14293955
Sajt: https://github.com/milost..

+48 Profil

Re: Portabilnost C-a

^{31.10.2006. u 02:11 - pre 213 meseci}

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.

Citat:

Časlav Ilić: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.

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).

Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
65.213.80.*

+6 Profil

Re: Portabilnost C-a

^{31.10.2006. u 12:48 - pre 213 meseci}

Citat:

tosa: 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.

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

IOCC

Odgovor na temu

tosa
上海，中国

Član broj: 1811
Poruke: 1342
218.82.250.*

ICQ: 14293955
Sajt: https://github.com/milost..

+48 Profil

Re: Portabilnost C-a

^{31.10.2006. u 13:43 - pre 213 meseci}

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

Odgovor na temu

cynique
Ivan Štambuk
Zagreb@Croatia

Član broj: 93690
Poruke: 155
193.198.17.*

ICQ: 106979934
Sajt: istambuk.blogspot.com

Profil

Re: Portabilnost C-a

^{31.10.2006. u 15:03 - pre 213 meseci}

Citat:

tosa: 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).

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.

Citat:

Časlav Ilić: (

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).

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.

Put the funk in funktion.

Odgovor na temu