[Vajonész]

idézet:

---

Ezt írta Rive:

Am, ezzel együtt is szívesen hallanám pl. az 'EPIC compilere' kifejezés értelmezését az általad vázolt kontextuson belül.
Mer' szerintem elég értelmetlen :confused:[/quote]

Ami számodra értelmetlen az nem biztos, hogy értelmetlen, de sebaj.
Nincs ennyi felesleges idõm, a részemrõl lezártam a témát.

[special]

idézet:

---

Ezt írta Vajonész:


Miért nem mindjárt egy mûvelet?
Adott egy feladat az a leggyorsabb, amelyik a legkevesebb idõ alatt végez. A kutyát nem érdekli, hogy hány mag, VE, vagy bármi más van benne.
Vonatkoztass el a hagyományos Neumann elvû professzoroktól. A te értelemezésedben pl. egy teljesen máselvû professzornak esélye sincs.[/quote]

Ezek a processzorok MP környezetbe készülnek, így nyilvánvaló, hogy a felhasznlásukkor erõsen párhuzamos végrehajtás történik, különben az egész nem ér semmit.

Viszont ha egy processzor sebességérõl beszélünk technikai szemmel, akkor nem tartható a CMP figyelembe vétele, mivel az több, ugyanolyan magot takar, és melyek egy szekvenciális számítás esetében nem játszanak. Szerintem meggondolatlanság lenne ezen számítások nagyságát és gyakoriságát félresöpörni.

[SFIJ]

idézet:

---

Ezt írta Rive:
Csakhogy azoknál, ahol erre az ISA kidolgozásakor jóelõre felkészültek, ez megfelelõen kezelhetõ[/quote]

Valszeg en vagyok a total huje de akkor nem ertem. Ha a compiler kerdeskort az IA64 ISA kidolgozasakor jelentosen koruljartak, akkor mert jottok allandoan azzal, hogy az IA64 eseteben compiler technologiailag meg sokmindent tartogat a jovo.

[Fiery]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:


Valszeg en vagyok a total huje de akkor nem ertem. Ha a compiler kerdeskort az IA64 ISA kidolgozasakor jelentosen koruljartak, akkor mert jottok allandoan azzal, hogy az IA64 eseteben compiler technologiailag meg sokmindent tartogat a jovo.[/quote]

Az Intel anno kitalalta, hogy hogyan kellene mukodnie egy IA-64 compilernek, csakhogy azota sem tudtak osszehozni azt az "idealis" (vagyis erosen optimalizalt kodot generalo) compilert, es nem is fogjak tudni. De ez csak nehanyunk velemenye, nem szentiras.


Fiery

[Fiery]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:


Valszeg en vagyok a total huje de akkor nem ertem. Ha a compiler kerdeskort az IA64 ISA kidolgozasakor jelentosen koruljartak, akkor mert jottok allandoan azzal, hogy az IA64 eseteben compiler technologiailag meg sokmindent tartogat a jovo.[/quote]

A legnagyobb gond egyebkent az, hogy az alapvetoen szekvencialis kodot (nezz bele barmelyik Visual C++ forraskodba, hogy tippet kapj, mire gondolok) az EPIC "igenyei" szerint kellene atalakitani gyakorlatilag tobb parhuzamos kodfolyamma, raadasul kozben ugyelni arra, hogy a parhuzamos VE-k kozott ne legyen fuggesbeli problema, azt ugyanis az IA-64 az x86-tal ellentetben nem tudja lekezelni.

Ha gondolod, megprobalom szemleltetni ezt egy emberkozeli peldaval, mar ha az IA-64 doksik alapjan nem vilagos, hogy az EPIC miert drasztikusan mas, mint pl. az x86.


Fiery

[SFIJ]

idézet:

---

Ezt írta Fiery:

Ha gondolod, megprobalom szemleltetni ezt egy emberkozeli peldaval, mar ha az IA-64 doksik alapjan nem vilagos, hogy az EPIC miert drasztikusan mas, mint pl. az x86.
[/quote]

Errol van elkepzelesem, ugyanis tobbezernyi kodsort irtam TMS320C60-ra

[T2k]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:


Fiery,
ad 1. tessékúgy kezdeni, hogy RTFM. Az Oracle-hez ugyanis az install guide-ban van dimensioning guide. Nos már a 8x esetén is igaz, hogy a rendszer idle loadja esetén is kell 1 GByte RAM, nos ez az optimal érték nem a mûködési határérték. Az utóbbi 512 MByte RAM. Az Oracle meg a Sybase eredendõen data warehouse-ok kiépítésére való. Ha valaki naplófõkönyvet akar, vagy raktárkészlet nyilvántartást kis cégnél pl videotéka arra nagyon jó a postgres a mysql vagy a borland-dal jövõ informix; esetleg kellõen hithû emberek dolgozhatnak az M$ jet engine-nel is ha épp olyan a target platform...[/quote]

Leforditom T2k-s nyelvre: egy olyan fossz@rtalicska gepre, amiben mindossze fel giga ram van, nem Oraclet kell inhallalni, hanem vmi csumpibb sqlt! Az Oracle nagyfiuknak lett kitalalva - a sarki tekas a penegy+winxpre meg csak inhalljon vmi fostos M$sqlt, ne nagykepuskodjon.

[szeder]

idézet:

---

Ezt írta Fiery:
Ha gondolod, megprobalom szemleltetni ezt egy emberkozeli peldaval, mar ha az IA-64 doksik alapjan nem vilagos, hogy az EPIC miert drasztikusan mas, mint pl. az x86.[/quote]

Ha SFIJ esetleg nem is igenyli, de masok kedveert nem lehetne szemleltetni? (;

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
Valszeg en vagyok a total huje de akkor nem ertem. Ha a compiler kerdeskort az IA64 ISA kidolgozasakor jelentosen koruljartak, akkor mert jottok allandoan azzal, hogy az IA64 eseteben compiler technologiailag meg sokmindent tartogat a jovo.[/quote]

Nem a compiler-kérdéskört járták körül, hanem a CPU mûködését, a végrehajtás menetét: majd az ezekkel kapcsolatos problémák által felvetett igényeknek megfelelõen alakították ki az ISA-t.
Abban csak bízni tudtak, hogy egyes korábbi - fõleg tudományos számításoknál használt - compiler-technológiák már elsõre is megfelelõen képesek teljesíteni az új környezetben, és hogy az új dolgokat képesek viszonylag gyorsan kihasználni.
Ez nem igazán jött be: a tudományos számítások jóval nagyobb alapblokk-méretekkel dolgoznak, mint az oprendszerek, és a loop-unrolling is nagyobb hatásfokkal ûzhetõ azon a területen: az utasítás-ütemezés hatásfoka pedig fõleg a megfelelõ alapblokk-méreten áll vagy bukik.
Azonban, a proci (az ISA) a kézzel hangolt alkalmazások tanulsága alapján megvalósítja a tervezéskor kitûzött célokat, és a compilerekben használt módszerek valóban továbbfejleszthetõk - gondolok itt pl. a (viszonylag) gyorsan terjedõ végrehajtás-elemzésen alapuló kódoptimalizációra, vagy a transmeta-féle code-morphing megoldásra.

[h1ghland3r]

idézet:

---

Ezt írta sz:


Ha SFIJ esetleg nem is igenyli, de masok kedveert nem lehetne szemleltetni? (;[/quote]

Amennyit en lattam belole (szigoruan programozoi szemszogbol), azon van a hangsuly, hogy bizonyos fuggosegi informaciokat mar fordiatasi idoben hozzarendelnek a gepi utasitasok kotegeihez (egy kotegben talan 3 gepi utasitas van). Ez foleg a kodban rejlo parhuzamositasi lehetosegek kihasznalasat segiti. Az EPIC mozaikszoban az EP az Explicitly Parallel vagy hasonlo roviditest takar.

Ez ket szempontbol jo.

1. Nem kell ilyen funkcioju aramkoroket epiteni a processzorba, ergo a proci egyszerubb lehet, es kevesebb munkat kell vegeznie.

2. Az elemzest forditasi idoben megteheti a compiler, ahol raadasul a szukseges dependency grafok egyebkent is rendelkezesre allnak.

Persze ez egyszerunek tunhet de lehetnek problemak.

Kerdeses, hogy az utasitasokat harmasaval csomagolva megfeleloen kihasznalhato-e a parhuzamossag egy RISC ISA eseten. Ugy gondolom, hogy a predikatum utasitasok reszben ezert kerultek alkalmazasra (persze bizonyara jol jonnek a pipeline effektiv mukodesehez is), mert igy egy flagtesztet es egy sima muveletet egy gepi utasitassal is el lehet vegeztetni, es nem kell elagazasbecslest csinalni.

En kicsit kevesnek erzem ezt a bizonyos harom utasitast, de bizonyara valami komoly akadaly miatt nem tudtak novelni.

A masik kenyes ugy a compilerek irasa. Ezt a fajta optimalizaciot nagyon jol meg kell csinalni. Gondolom az Intel ezert vasarolta fel a KAI Labsot, es ezert vette at a Compaq Fortran fejlesztoit.

h1ghland3r

[Elric]

Tobb dologot is ki kellene javitanom. Elsokent a compiler technologiat es a VLIW otletet a HP adta az Intel-nek, mert a HP Labs ezer eve foglalkozott a VLIW-vel, erdemes meg nezni a weblapjukon a Tech. Reportokat. Raadasul nagyon is jo otleteik voltak. Az Itanium ISA tervezeseben meg az volt az otlet, hogy tegyunk bele mindent ami kurrens, aztan itt vannak a HPs fiuk, majd megcsinaljak a jo compilert. Az iparban mindenki tudja, hogy miutan megvan a chip, kb. 5 ev egy SIMA RISC chipnel, mire jo optimalizalo compilert csinalsz. Az egy VLIW-nel kb. 8-10 ev...

Namost a compiler egy csomo olyan dolgot kell, hogy kezeljen, ami nincs az x86-os ISA-ban. Pl. predikatum logika, memory disambiguation (ALAT), prefetch, a teljesen uj nyitott sliding window regiszter fajl stb...

A compilernek az utasitas resze csak a kozepso reteg, utan jon az optimalizacio, ami a HARDVER fuggvenye es NEM az ISA-e. Vagyis minden chip-re ujra kell csinalni!
Elric

[Fiery]

idézet:

---

Ezt írta Elric:
Tobb dologot is ki kellene javitanom. Elsokent a compiler technologiat es a VLIW otletet a HP adta az Intel-nek, mert a HP Labs ezer eve foglalkozott a VLIW-vel, erdemes meg nezni a weblapjukon a Tech. Reportokat. Raadasul nagyon is jo otleteik voltak. Az Itanium ISA tervezeseben meg az volt az otlet, hogy tegyunk bele mindent ami kurrens, aztan itt vannak a HPs fiuk, majd megcsinaljak a jo compilert. Az iparban mindenki tudja, hogy miutan megvan a chip, kb. 5 ev egy SIMA RISC chipnel, mire jo optimalizalo compilert csinalsz. Az egy VLIW-nel kb. 8-10 ev...

Namost a compiler egy csomo olyan dolgot kell, hogy kezeljen, ami nincs az x86-os ISA-ban. Pl. predikatum logika, memory disambiguation (ALAT), prefetch, a teljesen uj nyitott sliding window regiszter fajl stb...

A compilernek az utasitas resze csak a kozepso reteg, utan jon az optimalizacio, ami a HARDVER fuggvenye es NEM az ISA-e. Vagyis minden chip-re ujra kell csinalni!
Elric[/quote]

Es minden chipre 8-10 ev az optimalizacio? Na jo, ez felesleges kotozkodes volt, de az mindenesetre riaszto lenne, ha az Itanium 3 "tul hamar" kovetne a Madisont, akkor lehetne kukazni a mostani compilerek eddig elert optimalizaciojat...


Fiery

[Fiery]

idézet:

---

Ezt írta T2k:
Leforditom T2k-s nyelvre: egy olyan fossz@rtalicska gepre, amiben mindossze fel giga ram van, nem Oraclet kell inhallalni, hanem vmi csumpibb sqlt! Az Oracle nagyfiuknak lett kitalalva - a sarki tekas a penegy+winxpre meg csak inhalljon vmi fostos M$sqlt, ne nagykepuskodjon. [/quote]

Ize, nekem az AIDA32 teszteles miatt kell Oracle, Sybase meg MS SQL is, amugy dobnam messzire oket izombol Plane ilyen gepen, ha me'g tudnad, hogy milyen proci meg alaplap van benne


Fiery

[Elric]

Minden uj core eseteben. Ez annyit jelent, hogy minden olyan esetben amikor a pipeline-t ujra terveztek. Ez alol kivetel, ha ISA kiegeszites is volt, pl. SSE[n+1] akkor a regi core eseteben is ennyi. Minden mas esetben kb. 1-2 ev, attol fuggoen, hogy mennyi valtoztatas volt az architekturaban.
Elric

[Atti]

Tényleg, az Itanium el(nem)terjedésében mennyire játszik szerepet az, hogy minden generációhoz újra kell fordítani a programokat? Vagy ez nem igazán lényeges szempont? :confused:

[SFIJ]

idézet:

---

Ezt írta Elric:
A compilernek az utasitas resze csak a kozepso reteg, utan jon az optimalizacio, ami a HARDVER fuggvenye es NEM az ISA-e. Vagyis minden chip-re ujra kell csinalni!
Elric[/quote]

Lehet hogy botorság amit íok de mintha ugy emlékeznék, azért büszke az Intel+HP az Itanicra, hogy nála nem kell újrafordítani a programot a köv. verziójú chipre

A sliding window regiszter fajl meg ha jolemlex US procikban is van és arra jó ugyi, hogy ne kelljen a stackre pakolni a függvényeknek átadott és visszatérõ paramétereket

[Elric]

Atti, nem kell ujraforditani. Az Itaniumnal is minden olyan mint barmelyik masik CPU-nal. Altalaban azert forditasz ujra, hogy a legjobb teljesitmenyt elerd. Itt is igy van. Az egy masik dolog, hogy ennel az architekturanal sokkal jobban jarsz, ha ujraforditasz. Egyfelol azert mert a VLIW egy ilyen allatfajta, masodszor meg azert, mert az optimalizalas fugg a hardvertol, szoval nem biztos, hogy mindegy, hogy 3, 4, 5, 6 vagy 9MB L3 cache-ed van...
Elric

[Elric]

Bocs, ugy latszik felreertheto lett amit irtam.

Az optimalizalot kell a compilerben minden verziohoz tuningolni, mindegy, hogy uj pipeline vagy csak uj feature. Az elobbihez tobb, az utobbihez meg kevesebb ido kell a fejlesztok oldalarol. A binarisokat valoban nem kell ujraforditani. Lasd az elozo postot.

Egyebkent valoban van regiszter ablak a SPARC CPU-kban, (mindben), csak ott nem dinamikus az ablak merete, hanem fix. A dinamikara optimalizalni az az ami nem trivialis, mert ha jol akarod csinalni akkor fa szinten kell optimalizalni, a call graf alapjan. Esetleg cross source code file vizsgalatot is csinalni kell...
Elric

[Rive]

idézet:

---

Ezt írta Elric:
A compilernek az utasitas resze csak a kozepso reteg, utan jon az optimalizacio, ami a HARDVER fuggvenye es NEM az ISA-e. Vagyis minden chip-re ujra kell csinalni!
Elric[/quote]

Khm.

Az adott ISA fejlesztésénél erõteljesen figyelembe vették a hardver korlátokat, így a hardver felépítése tükrözõdik az ISA-ban is.

A legtriviálisabb példa: egy azonnali adat/kódelérésre tervezett ISA esetében nincs prefetch.

[h1ghland3r]

Hi!

Egy kisse offtopic leszek. A HP az IA64 kedveert bealdozza a PA-RISC-et (elvegre mind a ket proci sajat gyerek)? Vagy van valami lenyeges kulonbseg a ket vonal kozott, ami miatt maskeppen pozicionalhatoak?

h1ghland3r