[T2k]

idézet:

---

Ezt írta Rive:
Ehe-ehe. Csak tudnám, mi adja az egész alá az infrastruktúrát... [/quote]

Hat NEM AZ ITANIUM, az biztos. Es nem veletlenul.

[SFIJ]

idézet:

---

Ezt írta Rive:

Aha. Jól kijelentetted, nézzük mi van mögötte.
Nézzünk egy totálisan eseményvezérelt feladatok megoldására alkalmazott nyelvet: GCC. Válasszunk hozzá egy procit: K7. Feladat: SPEC.
[/quote]

A GCC az az en szemelyes tapasztalataim szerint a compiler csomag, a neve is erre utal (gnu compiler collection) es nem tekinteheto ezert (formalis) nyelvkent. A Grammar translator nem azanos magaval a grammar-ral, szereny velemenyem szerint.
Az hogy a prgramforditas esemnyvezerelt task lenne, azt vitanam. Tovabba a benchmarkokat sem tartom esemenyvezerelt ugyeknek specin2k, specfp2k. talan a specweb szol valami ilyesmirol.
Tovabba nem vilagos szamomra a postodbol, hogy a teszt targyat a SPEC csomag leforsitasa vagy futtatasa jelenti. Ez szerintem azert fontos dolog
Csendben megjegyeznem, hogy stukturaslisan mar a k7 is streaming iranyba mutato proci.

Abban ellenben igazad vagyon, hogyha a target streaming proci, akkor az I/O-t a TCP/IP-t es a packet filteringet celszeru streaming kodra irni. Linuxban jelenleg ezek a dolgok pure c-ben vannak irva. Ennek tan az az oka, hogy portabilisnek akarjak megtartani a kernelt.

Irtad korabban, hogy az IA32 nem temogatja a taskkezelest. Nos lehet hogy tevedek, de mintha az i386-ban lett volna taszk kapu hivas. Azota ezt kivettek volna az ISA-bol

[Elric]

SFIJ, sajnos nem hiszek az osszeeskuves elmeletekben. A memoria technologia szepen lassan fejlodik, de sajnos igazad van abban, hogy a legfontosabb feladat az volt nagyon hosszu ideig, hogy a kapacitast maximalizald es csak most kezdodik a savszelesseg dolog. Elhiszem, hogy lesz holografikus memoria elobb utobb, de ez szerintem messze nem annyira trivialis, mint amennyire most latszik. Itt millio olyan apro kerdes van, hogy ok, hogy nagy mennyiseget tarolsz, de hogyan viszed el a procihoz? Optika, igen, de aszimmetrikusan fut, nagyon gazos a pozicionalasa, kabelezese etc... Speciel van valoban olyan megoldas, amivel 2007-re egyetlen 30x30cm-es lapon tobb tucat processzort es fel TB memoriat tudsz letenni kb. 40TB/sec savszelesseggel. Az egy masik kerdes, hogy hutened is kell....
Elric

[Rive]

idézet:

---

Ezt írta T2k:
B)barmilyen sw remekul hasit rajta??[/quote]

Itt a gond. Az erõteljes SSE optimalizációt használó programok hasonló sebességgel fognak futni rajta, mint a K7-en. Hány K7 áll nálatok rendszerben? Hány szoftver használ SSE-t? Mi a tapasztalatod?
A P4-el viszonylatba állítva az SSE-optimalizáció minõségétõl -azaz: a programverziótól - függõen a teljesítmények aránya ilyen esetben konvergál a fizikai órajelek arányához.

Még az hozzá, hogy az ilyen jellegû programok alatt mutatott teljesítménye nem a modellszámozás, hanem az órajel arányában skálázódik majd.

idézet:

---

Ezt írta T2k:
A kerdes az, LESZ-E ELEG belole ahhoz, hogy ELARASSZA a piacot vele az AMD?[/quote]

Meg: a WS piac mekkora szegmensében válik egyeduralkodóvá az SSE-optimalizáció?

idézet:

---

Ezt írta T2k:
DEHOGYNEM!!!! Ebbol is kozetkezik, hogy HULYESEG a ti 'sikerre van itelve' dumatok. Ezt probalom elmagyarazni en is, Elric is, SFIJ is.[/quote]

Ha a pillanatnyi helyzeten szeretnél vitázni, csak nyugodtan.
A magam részérõl az x86 jelenlegi formájában rejlõ zsákutcát és a továbblépés reménytelenségét látom.

A K9, ha minden igaz, egy hosszú futószalaggal megáldott/megvert architektúra lesz. Lehet, hogy az órajel-versenybe be tud majd szálni, lehet, hogy SSE alatt jól teljesít majd, de az x86 alatt mutatott hatékonysága megy a P4 mellé, a béka hátsója alá.

Elric éppenséggel ezt (is) magyarázza:

idézet:

---

Ezt írta Elric:
Rive, erosen vitatkozom avval, hogy a jovo a hosszu pipeline-u gepeke. A uniprocesszoros piacon igen, mashol? Hat bizonytalan vagyok. Ha megnezed a piacot, a jovo minden esetben a sok core, sok thread per processzor rendszereke. HP, IBM, Sun, AMD, Intel. Mindenki ebbe az iranyba megy, ez meg az atbocsajtas (throughput). A szerver vilagban ha van 16 egyszeru 6-8 lepcsos, nem szuperskalar core-od es egy jo interconnected, igaz, hogy nagy chip-sd lesz, de iszonyatosan gyors. Sokkal gyorsabb, mint egy 16-utas, 40 lepcsos csoves cucc... Egyszeruen nem eri mar meg tobb ILP-t tenni a procikba... Ezt hala az egnek meg a kutatas is megerositi.

...

T2k-val ertek egyett abban, hogy valoban az Intel 10 eve tomi a penzt a HP-val karoltve az Itaniumba. Egyelore keves eredmennyel. Meg par ev es lesz eredmenye. Minden esetre az x86-64 valoban sokkal eselyesebb a sikerre, HA az AMD jo teljesitmenyt, marketinget es ISV tamogatast tud moge tenni. Szerintem mindent meg fog tenni, de lattunk mar elszurt dolgokat, szoval erre sem vennek merget.
Elric[/QB][/quote]

idézet:

---

Ezt írta T2k:
Hat NEM AZ ITANIUM, az biztos. Es nem veletlenul.[/quote]

Lehet, hogy félreérthetõen fogylmaztam meg a kérdést.

Akkor még egyszer: min fut pl. egy JAVA program?
Kell hozzá architektúra-függõen optimalizáló fordító és SDK?

[ 2003. október 11.: Rive szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
A GCC az az en szemelyes tapasztalataim szerint a compiler csomag, a neve is erre utal (gnu compiler collection) es nem tekinteheto ezert (formalis) nyelvkent. A Grammar translator nem azanos magaval a grammar-ral, szereny velemenyem szerint.
Az hogy a prgramforditas esemnyvezerelt task lenne, azt vitanam. Tovabba a benchmarkokat sem tartom esemenyvezerelt ugyeknek specin2k, specfp2k. talan a specweb szol valami ilyesmirol.[/quote]

Remélem, csak kötözködsz, és nem tapasztalatlanságból érted félre, amit írok... Minden ott van, leírva, ha nem fél percben ütnél össze rá egy választ, hanem értelmeznéd, sokat megspórolhatnál magadnak :o

idézet:

---

Tovabba nem vilagos szamomra a postodbol, hogy a teszt targyat a SPEC csomag leforsitasa vagy futtatasa jelenti. Ez szerintem azert fontos dolog [/quote]

:o

idézet:

---

Csendben megjegyeznem, hogy stukturaslisan mar a k7 is streaming iranyba mutato proci.[/quote]

Oh... SSE-ben. Más jellegû feladatokban roszabb hatékonysággal dolgozik, mint egy PPro :o

idézet:

---

Abban ellenben igazad vagyon, hogyha a target streaming proci, akkor az I/O-t a TCP/IP-t es a packet filteringet celszeru streaming kodra irni. Linuxban jelenleg ezek a dolgok pure c-ben vannak irva. Ennek tan az az oka, hogy portabilisnek akarjak megtartani a kernelt.[/quote]

Mint közismert, pillanatnyilag erre x86 alatt nincs lehetõség...

idézet:

---

Irtad korabban, hogy az IA32 nem temogatja a taskkezelest. Nos lehet hogy tevedek, de mintha az i386-ban lett volna taszk kapu hivas. Azota ezt kivettek volna az ISA-bol [/quote]

Majd ha dedikált TaskState Cache vagy stack lesz benne, és HW-ból támogatják a taszkok közötti paraméterátadást :o

Komolyan, ha nincs idõd ezzel foglalkozni, akkor inkább hagyd a fenébe, vagy szólj...
Ezeknél a próbálkozásoknál azért jóval szinvonalasabbnak ismerlek...

[ 2003. október 11.: Rive szerkesztette a hozzászólást ]

[ 2003. október 11.: Rive szerkesztette a hozzászólást ]

[Fiery]

idézet:

---

Ezt írta Rive:
Oh... SSE-ben. Más jellegû feladatokban roszabb hatékonysággal dolgozik, mint egy PPro[/quote]

Lehet, hogy rossz a hatekonysaga, de hogy azonos orajele sz*rra verne a PPro-t, az is biztos. Senki sem erdekel a hatekonysag, amig a teljesitmeny elegendo.

Lehet, hogy szamodra a P4 SSE(2) optimalizacio eseten egy idealis cuccnak tunik, mondhatni kovetendo peldanak, de mint ahogy az x86 nem eleg hatekony, ennyi erovel mondhatnank azt is, hogy altalanos felhasznalasra a P4 meg losz*r, hiszen "akkora orajelbol" sokkal tobb mindent ki lehetne hozni.

Egyebkent ha ennyire sz*rnak tartod az x86-ot, akkor javaslom, hogy allj neki tervezni valamit, ami nem x86, ami hatekonyabb vegrehajtast tenne lehetove (azonos tranzisztorszam mellett!), es amire tudsz 1 even belul _hatekony_ compilert is irni. Ja, es ami kompromisszumok nelkul futtatja az x86, SSE, SSE2, es esetleg az AMD64 kodot is. Nehogy azt hidd, hogy ez olyan konnyu feladat

Amugy meg tovabbra sem ertem, mi bajod az x86-64-gyel konkretan, ott pont az x86 legidegesitobb hianyossagait kuszobolte ki az AMD. Lasd FPU, 32 bit es a regiszterek alacsony szama.


Fiery

[ 2003. október 12.: Fiery szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta Fiery:
Lehet, hogy rossz a hatekonysaga, de hogy azonos orajele sz*rra verne a PPro-t, az is biztos. Senki sem erdekel a hatekonysag, amig a teljesitmeny elegendo.[/quote]

A legkevésbé sem közömbös tényezõ a hatékonyság: minél alacsonyabb, annál nagyobb erõfeszítésbe kerül a skálázódás megfelelõ szinten tartása az órajel emelésével. Ez pillanatnyilag nagyon jól demonstrálható a P4 és a K7 általános célú programok futása alatt mutatott teljesítményének összevetésével.

Külön probléma, hogy a hatékonyság romlását itt olyan tényezõ okozza, amit nem lehet megkerülni, és a nagyobb órajelek felé tendenciózusan egyre nagyobb gondot okoz.

idézet:

---

Lehet, hogy szamodra a P4 SSE(2) optimalizacio eseten egy idealis cuccnak tunik, mondhatni kovetendo peldanak, de mint ahogy az x86 nem eleg hatekony, ennyi erovel mondhatnank azt is, hogy altalanos felhasznalasra a P4 meg losz*r, hiszen "akkora orajelbol" sokkal tobb mindent ki lehetne hozni.[/quote]

A P4/SSE páros a speciális célú, straming-ra optimalizálható számítások területén verhetetlen, mégpedig pont amiatt, mert a nagy memória-késleltetés hatásait megkerülõ lehetõségeket az adott számításokat támogató ISA-kiegészítésbe belevették.
Ezen túl, bármilyen általános célú számítás esetén a P4 teljesítménye úgy sz@r, ahogy van - azért, mert az alap x86 ISA az azonnali adatelérés feltételezésére épül.

idézet:

---

Egyebkent ha ennyire sz*rnak tartod az x86-ot, akkor javaslom, hogy allj neki tervezni valamit, ami nem x86, ami hatekonyabb vegrehajtast tenne lehetove (azonos tranzisztorszam mellett!), es amire tudsz 1 even belul _hatekony_ compilert is irni. Ja, es ami kompromisszumok nelkul futtatja az x86, SSE, SSE2, es esetleg az AMD64 kodot is. Nehogy azt hidd, hogy ez olyan konnyu feladat [/quote]

Kutya se hiszi, hogy ez könnyû feladat. Az Intel ezzel küszködik az IA64 kapcsán...

idézet:

---

Amugy meg tovabbra sem ertem, mi bajod az x86-64-gyel konkretan, ott pont az x86 legidegesitobb hianyossagait kuszobolte ki az AMD. Lasd FPU, 32 bit es a regiszterek alacsony szama.[/quote]

Az x86-64-el kapcsolatban itt még nem esett szó, így nem is fejtettem ki, mi a bajom vele.

Az x86 legidegesítõbb, leginkább korlátozó jellegû tulajdonságai nem azok, amiket említesz, és amikre valóban megoldást ad az x86-64, hanem az azonnali adatelérés feltételezése. Ezzel viszont semmit se tesz az x86-64.

Ui.: összeszedem egy helyre a memória-késleltetéssel és az ISA problémáival kapcsolatos dolgokat, a véleményemet az egészrõl, és körüllöttyintem némi szakirodalommal.
Lassan ott tartunk, hogy mindenki másról beszél

[ 2003. október 13.: Rive szerkesztette a hozzászólást ]

[SFIJ]

Draga 1 Rive,
Elvarasaid affele tendalnak szamomra, hogy a magaszintu nyelven is kenytelen leszel notalni a nem azonnali adatelerest[delayed assignment operator, sic (!) ], kulonben fabol vagy vaskarika es dogozhatsz assembly szinten. Tudom hogy meg hiszel a csudacompilereben, de en aszondom, hogy ollyan nem lesz. Compiler szamara aztat eldonteni hogy valos adatfugges van, vagycsak hulyen programoztak le valamit az esetek nagy reszeben nagyon nem trivi egy ugy.
Meg kollene magadban ket kerdest valaszolni.
Mi az az ISA es miert?
Az IA-32/AMD64 ISA miert olyan, amilyen? (sugok. nem azert mert oreg es nemis azert mert hujek terveztek anno)

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
Az IA-32/AMD64 ISA miert olyan, amilyen? (sugok. nem azert mert oreg es nemis azert mert hujek terveztek anno)[/quote]

idézet:

---

Minden nagyon szép, minden nagyon jó, mindennel meg vagyok elégedve...[/quote]

Nem volt semmi fejlõdés '80 óta, a memória problémái miatt nem pumpálták az egekbe a cache mennyiségét, nem próbálkoznak mindenhol legalább a speciális számítások körében az sw prefetch-el, nem próbálják minden nagyteljesítményû processzorban minél inkább a pipe legelejére hozni az L/S detektálást, nem vezették be az MTRR-eket, és a Hammer sem a kis késleltetésû memóriái miatt döngöl földbe minden asztali processzort bármi konzervatív alkalmazás alatt, és a különféle processzorok teljesítménye is lineárisan skálázódik az órajellel...

Vazze!

Ui.: Csak tudnám, hogy bármilyen fordító esetében mi a fene köze van a forrásnyelvi szintnek az optimalizálást végzõ ütemezõhöz

[ 2003. október 13.: Rive szerkesztette a hozzászólást ]

[SFIJ]

idézet:

---

Ezt írta Rive:


Nem volt semmi fejlõdés '80 óta, a memória problémái miatt nem pumpálták az egekbe a cache mennyiségét, nem próbálkoznak mindenhol legalább a speciális számítások körében az sw prefetch-el, nem próbálják minden nagyteljesítményû processzorban minél inkább a pipe legelejére hozni az L/S detektálást, nem vezették be az MTRR-eket, és a Hammer sem a kis késleltetésû memóriái miatt döngöl földbe minden asztali processzort bármi konzervatív alkalmazás alatt, és a különféle processzorok teljesítménye is lineárisan skálázódik az órajellel...

Vazze!

Ui.: Csak tudnám, hogy bármilyen fordító esetében mi a fene köze van a forrásnyelvi szintnek az optimalizálást végzõ ütemezõhöz

[/quote]


Section 1.
[url="http://"http://www.arstechnica.com/cpu/2q00/x86future/isa-future-1.html"]>>>KATT<<<[/url]
probald meg azt hogy nem fogod szelektive felreerteni, pliiiiz!
Adalekanyagnak melletoszogatnam egy bizonyos Nikolas Wirth bacsi p-kod neven elhiresult alkotasast. capisi?

section 2.
A forrasnyelvi utemezo barmennyire is megdobbento, akarcsak a panamai szabo, hozott anyagbol dolgozik 'oszt esetleg kiderul hogy vaszonzsakbol nem lehet kisestelyit kiszabni furcsa kellemetlen jateka ez a valosagnak, de bezony van ra incidens, hogy megesik.

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
Section 1.
[url="http://"http://www.arstechnica.com/cpu/2q00/x86future/isa-future-1.html"]>>>KATT<<<[/url]
probald meg azt hogy nem fogod szelektive felreerteni, pliiiiz! [/quote]

Bár kifejezetten úgy gondolom, hogy egy olyan idõszakban, amikor a normális futásteljesítmény elérése érdekében már az x86-vonalon belül se mellõzheti senki az architektúra-specifikus optimalizációval dolgozó compilereket, nagyobb kritikával kellene olvasni az olyan helyeket, amik csak az ellenvéleménnyel kapcsolatban hivatkoznak más forrásból származó publikációkra: ígérem, átnézem.

idézet:

---

Adalekanyagnak melletoszogatnam egy bizonyos Nikolas Wirth bacsi p-kod neven elhiresult alkotasast. capisi?[/quote]

Aham. Adalékanyag. És? Hadd legyen ez kérdés, ne válasz: mennyire determináns a P-code manapság?

idézet:

---

section 2.
A forrasnyelvi utemezo barmennyire is megdobbento, akarcsak a panamai szabo, hozott anyagbol dolgozik 'oszt esetleg kiderul hogy vaszonzsakbol nem lehet kisestelyit kiszabni furcsa kellemetlen jateka ez a valosagnak, de bezony van ra incidens, hogy megesik. [/quote]

forrásnyelvi ütemezõ
Tegyük fel, hogy a compiler gépi kódú utasításokkal dolgozó ütemezõjére gondoltál. Más úgyse nagyon van...

A 'hozott anyag' ez esetben megdöbbentõen egységes tulajdonságokkal bír minden olyan magasszintû nyelvnél, amely közvetlenül futtatható állományokat produkál.
Az ütemezõ számára fontos tulajdonságok leginkább probléma-, nem pedig forrásnyelv-specifikusak.

[SFIJ]

Rive elirtam az utemezot, mea maxima culpa. Az utemezo ofcourse a traget assembly nyelvre vontakozik.

Ellenben mivel a forrasnyelven megeshet, hogy a dependenciak nehezen vehetoek eszre, illetve mivel a forrasnyelv nem tamogatja a compiler ilyeten tenykedeset, barminemu utemezo kizarolag best effort elven mukodhet. Tovabba vegyuk meg azt, hogy a forditas egysege kizarolagosan a file, elokerul az a problema, hogy a lokalisan vegzett optimalizacio a call-graf-ot tekintve esteleg akar tobb bajt okozhat mintha nem csinaltunk volna eteren semmit. Globalis informacio, call-graph csupan profilingbol, tesztfutasbol nyerheto. Namost ugyi a tesztfutasok meg attol fuggnek hogy mikent, hogyan jaratod meg a sw-> Ehhez meg koll egy optimalasi celu tesztadatbazis.
Ez az a par ok ami miatt nem igazan hiszek abban hogy az altalad hajpolt es 5 ev mulva mexuleto csodacompiler elso blikkre atvagja a gordiuszi csomot.
On the long run I'm afraid, hogy az Itanicos compiler nem tud jobbat produkalni mint egy crusoe morphing engine vagy barmelyik jelenlegi x86-os prociban levo IA32 interpreter. Ezeknek ugyanis nagysagrendekkel tobb informacioja van a futas alatt allo kodrol mint annak a szerencsetlen compilernek amely cache/tlb hit/miss ugyekkel nem talakozhat, max a profilerezes alatt...

[ 2003. október 13.: Supposed Former Infatuation Junkie szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
Ellenben mivel a forrasnyelven megeshet, hogy a dependenciak nehezen vehetoek eszre, illetve mivel a forrasnyelv nem tamogatja a compiler ilyeten tenykedeset, barminemu utemezo kizarolag best effort elven mukodhet. [/quote]

Khm.

A fordítás - és most hagyjuk végre a JAVA és a .NET virtuális gépeit, aminek a hatékonyságát a VM, és a VM-et lefordító compiler determinálja - ma a legegyszerûbb compiler esetében is legalább két lépésbõl áll.

Elsõ lépésben a szintaktikai elemzést és behelyettesítést követõen megalkotják a program assembly vázát, majd egy szimpla soros optimalizáció - felesleges szerkezetek elhagyása, kisebb átalakítások: mindaz, ami a 8086 óta nem változott - következik.
Ennek eredménye a .obj, azaz egy regiszter-hozzárendelések és pontos sorrendiség nélküli alacsonyszintû programváz.
Innentõl kezdve a magasabb szintû nyelvi rétegeknek semmi szerepe.

A második lépésben a cél-hardver számára készített egyedi ütemezõ elkezdi a képességeinek megfelelõ ütemezést. Ez, szép és jó tankönyvi megnevezés alapján - a valóságban tehát elég sok köztes eset fordul elõ, sõt - lehet alapblokk, ciklus- illetve globális ütemezés. Ezen a szinten jelennek meg elõször a vezérlési és adatfüggõségek, magasabb szinten nem.

Csak ezután jön a regiszterek kiosztása.


Az alapblokk-ütemezés annyit tesz, hogy egy-egy alapblokkon belül elõresorolja a függõségek nélkül végrehajtható utasításokat. Teljesítménye kicsi, csak a rövid futószalagú skalár proceszorok esetén ad igazán kielégítõ eredményt, viszont fõleg az alapblokkok rövidsége miatt kielégítõ matematikai alapokra helyezhetõ.

A ciklus-ütemezõk képesek különbözõ mértékben kibontani az egyes ciklusokat, vagy akár szoftver-futószalag megvalósítására is felkészíthették. Ezekben az esetekben nagyon komolyan az alkalmazott heurisztikákon van a hangsúly: az egész ütemezés-problémakör keményen NP-jellegû.

A GCC-ben pl. egy alacsonyfokú ciklusütemezéssel kibõvített alapblokk-ütemezõ mûködik.

A globális ütemezés az alapblokkokon túlnyúlóan is képes az egyes utasításokat átmozgatni: esetenként akár olyan feltétellel is, hogy egy másik végrehajtási ágon az adott utasítás hatását késõbb semlegesíteni kell. Messze ez a legnagyobb teljesítményû ütemezési technika: magyarán, totális megvalósítása kézzel, 100 soros assembly betéten belül, esetleg. Minden mai, globális ütemezést (is) megvalósító compiler kizárólag heurisztikákon alapul, tudtommal.
Ja, igen: ez utóbbi elõször a széles VLIW masinákkal kapcsolatban kapott komoly szerepet, meglehetõsen látványos eredményekkel...


A feltételes utasításvégrehajtás lehetõsége mindhárom ütemezési szinten képes növelni a hatékonyságot - alapblokkok megnövekednek, loop-unrolling esetén nem kell törõdni az esetlegesen nem megfelelõ számú ciklusismétléssel...

Az SW prefetch képes úgy adatbetöltést indítani, hogy nem foglal le regisztert és várakoztatóállomás-bejegyzést, emellett korán detektálható és probléma nélkül külön végrehajtási útra terelhetõ...

idézet:

---

Tovabba vegyuk meg azt, hogy a forditas egysege kizarolagosan a file, elokerul az a problema, hogy a lokalisan vegzett optimalizacio a call-graf-ot tekintve esteleg akar tobb bajt okozhat mintha nem csinaltunk volna eteren semmit. Globalis informacio, call-graph csupan profilingbol, tesztfutasbol nyerheto. Namost ugyi a tesztfutasok meg attol fuggnek hogy mikent, hogyan jaratod meg a sw-> Ehhez meg koll egy optimalasi celu tesztadatbazis.[/quote]

Ilyen jelegû hiba a heurisztikában már csak a globális ütemezõk szintjétõl kezdve lehetséges, alatta nem: így aztán ebben a környezetben a 'lokális' szó jelentése... Hm...

A profiling minden mai ütemezéssel és power-appal foglalkozó fejlesztés integráns része, a futásidõ alatti profiling és kódoptimalizálás pedig a compiler-technológia leginkább fejlõdõben levõ területe.

idézet:

---

Ez az a par ok ami miatt nem igazan hiszek abban hogy az altalad hajpolt es 5 ev mulva mexuleto csodacompiler elso blikkre atvagja a gordiuszi csomot.[/quote]

Ki állította, hogy ez egy csodaszer? Itt egy folyamatosan fejlõdõ heurisztikákra épülõ ágazatról van szó, és pl. a széles VLIW architektúrák számára is születtek igen-igen demonstratív globális ütemezõk (> 8-10 év alatt). Itt pedig 'csak' egy keskeny VLIW-rõl van szó... Ami történetesen hajlandó kiszolgálni mindazon alapvetõ igényeket, amiket egy nagy késleltetésû memóriákra és ILP processzorokra szánt compiler támaszt...

idézet:

---

On the long run I'm afraid, hogy az Itanicos compiler nem tud jobbat produkalni mint egy crusoe morphing engine vagy barmelyik jelenlegi x86-os prociban levo IA32 interpreter. Ezeknek ugyanis nagysagrendekkel tobb informacioja van a futas alatt allo kodrol mint annak a szerencsetlen compilernek amely cache/tlb hit/miss ugyekkel nem talakozhat, max a profilerezes alatt...[/quote]

Run-time optimization...

Találós kérdés: tudod-e, melyik desktop-procikat (is) gyártó cég fektetett eddig legtöbb energiát az event-counterek és a vonatkozó szoftverkörnyezet illetve dokumentáció fejlesztésébe?

Hadd súgjak: az AMD vonatkozó forrásai... Hogy is mondjam... Sz@rok. Mind.

Az IA32-interpreterrõl meg majd a következõben, a forrásod kapcsán.

[Rive]

Elõfordult itt is, több helyen, és a fentebbi hozzászólásban felhozott link is ezzal kapcsolatos dolgokat taglal: az ISA mennyiben determinálja egy adott végrehajtási szisztémán elérhetõ teljesítmény- és hatékonysági korlátokat, mikor válik meghaladottá.

Nos, a processzorokhoz kiadott Optim. Guide-k szerint nagyon, és én valahogy ezeket a forrásokat tekintem hitelesnek.

Lássuk egy kézenfekvõ példát: string-utasítások x86 alatt.
A korai idõkben, a skalárprocesszorok és a gyorsítótárak megjelenése elõtt az utasítás-behívás idõtartama komolyan befolyásolta az elérhetõ teljesítményt, valamint a memória is szûkösebb volt a kívántnál, így érthetõ volt az a törekvés, hogy komplex ( akár >>100 óraciklus) rutinokat valósítsanak meg a mikrokódon belül. Ez hatékonyan gyorsította a programokat: egy utasításlehívással komplex feladatokat tudtak elvégezni, gyakorlatilag a mikrokód sebességével.
Nézzük, mi történt azóta.

A legnagyobb változás ezt illetõen a cache, az utasítás-dekódolás, a várakoztató-állomások és a párhuzamos VE-k bevezetése volt: emellett ezekre tekintettel sokat változtak a compilerek is.

Egy-egy string-utasítás alapesetben telefossa a gyorsítótárat szeméttel, telerakja a várakoztatóállomást ismétlõdõ mikroutasításokkal, megakasztva ezzel a többi utasítás dekódolását: A VE-k közül gyakorlatilag egy integer és egy L/S párost használ, emellett nem ütemezhetõ. Moderálás veszélye nélkül nem tudom megfelelõen jellemezni azt, amit a hatékonysággal mûvel.
Ez a vector-path, ami csak és kizárólag a visszafelé kompatibilitás jegyében maradt benne az x86 alapú processzorokban - minden más x86 dekódolás már huzalozott alapú, akárcsak a RISC alapú gépekben...

Nem véletlen, hogy a komplex utasítások használatát az összes Optim. Guide határozottan kerülendõnek, károsnak tartja.
Ui.: tényleg, utánanézek, hogy a TraceCache hogy reagálja le az ilyen szemetet


Lássunk egy elvibb példát is!

A gyakorlat szerint x86 alapon ca. minden negyedik, ötödik utasítás ugrás. Egy-egy alapblokk tehát ekkora méretû: egy egyszerû ütemezõ csak ezen belül képes elõrehozni a gyorsan végrehajtható utasításokat, ezen túllépni már csak globális ütemezõ megvalósításával lehet.
Egy-egy alapblokk késleltetése jó esetben - ha nem merül fel távoli adatbehívás, pl. a memóriából - ca. 20-25 órajel: ezen belül az átmozgatott utasítások nagyjából öt órajelciklusnyi elõnyt élveznek. Egy memóriabehívás legjobb esetben is >80 órajel - ehhez aránylik az öt órajelnyi elõny.

Mi történik akkor, ha kockázat nélkül elõrehozható egy-egy adatbetöltés, pl. az alapblokkokon kívülre is könyen elmozgatható prefetch utasítással?
Nos, ez esetben az adat a másodlagos vagy a harmadlagos gyorsítótárból érkezik, nagyjából 20 órajel alatt, azaz pont akkorra, amikorra szükség van rá.

Van erre lehetõség x86 alatt?
Szükséges (lenne) ez a modern processzorok számára?

Függ-e tehát egy adott architektúrán az elérhetõ teljesítmény az ISA felépítésétõl?

Ha figyelmbe vesszük, hogy egy P4 esetében nem elképzelhetetlen >>200 órajelnyi load-latency, vajon hol lehet az a pont, amikor már minden más beelõz a hatékonyságra törekvés lehetõségei terén?

Ui.: még annyit, hogy az adott problémákkal kapcsolatban ma mindinkább kezd közös kategóriába kerülni a processzor és a programok hatékony portolásához szükséges compiler és ütemezõ a vonatkozó dokumentációkkal.
Azaz: nem csak a processzor a döntõ tényezõ, hanem a programozók számára biztosított támogatás is.
Ez paralel folyamat azzal, ami a beágyazott processzorok piacán végbement: egy processzor hatékony fordító nélkül semmi.

Mikor adta ki az AMD a proccesszoraihoz az elsõ fordítóját?
A dokumentációi még mindig nagyon keveset érnek, sajnos.

[ 2003. október 14.: Rive szerkesztette a hozzászólást ]

[Atti]

idézet:

---

MOUNTAIN VIEW, Calif. (2003. október 14.) Az SGI bejelentette, hogy az amerikai légierõ egyik legfontosabb kutatóbázisán az Aeronautical Systems Center Major Shared Resource Center (ASC MSRC) Wright-Patterson Air Force Base-n befejezték és október 6-án ünnepélyes keretek között átadták az eddigi legnagyobb SGI® Origin® 3000 szuperszámítógépet.

A nem mindennapi installáció egy 2048 processzoros szuperszámítógép, amelyhez adattárolásra egy SGI® InfiniteStorage diszkrendszert illesztettek. A diszk alrendszer önmagában 2 TeraByte (TB) gyorsító memóriát és 40 TB tárhelyet tartalmaz speciális data management lehetõséggel. Az új számítógéppel megduplázták a kutatóközpont számítási kapacitását.

Nézzük meg közelebbrõl mibõl is áll a gép. A 2048 processzor 700MHz R16000™ MIPS®, amelyhez processzoronként 1GB memória tartozik. A 4 nodeból álló konfiguráció nodeonként 512 processzoros shared memóriás környezetet biztosít a kutatóknak. Ezzel lehetõvé vált, hogy az eddigieknél lényegesen nagyobb modelleket is kezelhetnek. Az SGI® NUMAflex™ architektúra rendkívüli elõnyöket biztosít bármely más számítógépes környezettel szemben. A napjainkban egyre elterjedtebb cluster technológiákhoz képest, sokkal egyszerûbb adminisztrálni, üzemeltetni és sokkal hatékonyabb programok fejleszthetõk. Míg a clusteres program elkészítése nagyon komoly programozói munkát igényel a shared memóriás környezetben az igazi problémákra lehet fókuszálni, amivel hatékonyabb és eredményesebb a kutatás. A gép percek alatt átkonfigurálható a kutatási igényeknek megfelelõen, míg a clusteres megoldás esetén ez a munka komoly szervezést és akár több napig tartó üzemszünetet is jelenthet.

További fontos szempont lehet, hogy az Origin 3000 processzoronként tizedannyi energiát használ fel, mint egy PC, ezzel sokkal kevesebb hõt termelve nagyban egyszerûsíti a megfelelõ hûtést. Így adott területen lényegesen több processzort helyezhetnek el, egy rack akár 128 processzort is tartalmazhat.

Forrás: [url="http://"http://www.sgi.hu"]www.sgi.hu[/url] [/quote]

A marketingdumát leszámítva eléggé érdekesnek tûnik számomra a hír. Az SGI anno az Itanium miatt fogta vissza a MIPS felesztését, és kínálnak is Itaniumos gépeket.
Viszont ebbe a meglehetõsen jelentõsnek tûnõ gépbe mégis az öregecske, lassúcska MIPS került, csak nem itt is a szoftver volt a döntõ?
Csinálhat valaki egy fantasztikus procit, ha nincs hozzá szoftver, akkor nem sokat ér...
Valahogy ezt hagyták figyelmen kívül az Itanium fejlesztésénél, vagy baromira bíztak a szoftveres srácokban, akik most kissé pácban hagyták õket.

[special]

Ytse, szerinted a Fanwood árban hova fog pozícionálni? Hogyan oldják meg hw szinte, hogy csak DP rendszerbe lehessen rakni? Van valami info, hogy milyen egyéb okosságot fog tartalmazni? Több kérdésem nincs.

[Ytse]

Szerintem Deerfield-árban mozog majd a cucc. Egyelõre nem tudok semmit, de majd utánajárok.

[special]

Jó, de ha Deerfield árban lesz, akkor mivel akadályozzák meg, hogy a jelenlegi MP vonal helyett valaki azt pakoljon nagyobb gépekbe? Hogyan oldják ezt meg a Xeonok esetében? A cpu tartalmaz valami okosságot?

[Vajonész]

Az IDC csökkentette az Itanium-alapú szerverekre vonatkozó forgalmi elõrejelzését


Ilyen sorozat után ki veszi komolyan, hogy mit mondanak mi lesz 3-4 év múlva?

[ 2004. január 14.: Vajonész szerkesztette a hozzászólást ]

[SFIJ]

idézet:

---

Ezt írta Vajonész:
Az IDC csökkentette az Itanium-alapú szerverekre vonatkozó forgalmi elõrejelzését


Ilyen sorozat után ki veszi komolyan, hogy mit mondanak mi lesz 3-4 év múlva?

[ 2004. január 14.: Vajonész szerkesztette a hozzászólást ][/quote]

5000 USD nagyon sok penz egy processzoret akkor amikor a legkaposabb pro ws termekek 3000 USD-t kostalnak es komplett szervereket lehet mar 5000USD-ert kapni.

szo ami szo, az [url="http://"https://www.hwsw.hu/hir.php3?id=24145"]IA32 execution layer[/url] egeszen jol teljesit.

[ 2004. január 14.: Supposed Former Infatuation Junkie szerkesztette a hozzászólást ]