[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
off. Hagyd szegenyt, mar reges-reg nem koherens es konzisztens onmagaval se... [/quote]

Gratulálok

Ügyesen ködösítesz. Nagyon. Mondd, kifejtenéd végre, hogy mi is van azzal a szerencsétlen Prescott gyorsítótárral? Mer' amit a másik topikban írtál, az heveny röhögõgörcsök keltésén túl nem sok mindenre elég

Szóval, miért is kell fcpu/2-vel meghajtani egy on-chip SRAM-blokkot? Miért is kell - szerinted - egy nagyobb gyorsítótárnak lassabbnak lennie egy olyan prociban, ahol minden valószínûség szerint pillanatnyilag is több milliónyi tranzisztort hagynak kihasználatlanul?

[ 2004. február 10.: Rive szerkesztette a hozzászólást ]

[hvuk]

idézet:

---

Ezt írta Rive:

Egyedül a VE-blokkok származási helye. Ez pont elég, hogy bizonytalanságot keltsen.
Régebben is mondtam már, most is mondom: az AMD-nek nagyon fontos lenne nagyobb órajelen mûködõ K8 bemutatása. [/quote]

Nem voltam úgy látszik egyértelmû az elõbb. Az AMD nyilván nem fog tudni 2.4 GHz-nél gyorsabb procit 130 nanon bemutatni, de ez nem utal rosszabb skálázódásra, mint a P4-ek esetén, hiszen az órajelet az elõzõ processzhez képest ugyananniyra tudta emelni, mint az Intel. Magyarán, nem is várható el tõle, hogy 2.4-nél gyorsabb procit jelenleg kihozzon, hiszen még így is pont ugyanúgy skálázódott, mint az Intel P4.

Annak, hogy még nem hozta ki a 2.4 GHz-et nyilván az is az oka - az esetleges gyártási nehézségeken túl -, hogy utánna 8-9 hónapig semmi mást nem tudna bejelenteni. Ez pedig nem lenne a legjobb taktika.

idézet:

---

Ezt írta Rive:
Mármint arról, hogy az IA64 ISA öszességében nagyobb fejlõdési lehetõségeket rejt, mint az x86?
[/quote]

Nem, hanem arról, hogy esetleg az Itaniumra nem is írható a lehetõségeit normálisan kihasználható fordító. Persze az kérdés, hogy mit értünk ez alatt.

idézet:

---

Ezt írta Rive:
Röviden összefoglalva: a PC-processzorok utasításkészlet-bõvítései - ezzel együtt a végrehajtásukra tervezett architektúrák - a programokban gyakorta használt utasítássorok, matematikai mûveletek által támasztott követelményekhez igazodnak. Ez nem érinti az általános célú, szinte kizárólag magasszintû nyelveken készített programok körét, pl. SPECCPU2k, szerver-alkalmazások, satöbbi.[/quote]

Nem tudom mit értsz általános célú programok alatt, de az bizots, hogy jó néhány professzionális területen gyorsulás érhetõ el az új utasítások kihasználásával (lásd pl. professzionális 3D grafika). Jó néhány esetben meg nyilván nem, lásd az egetverõ teljesítménykülönbséget a (web)szerver alkalmazások alatt a Xeon és az Itanium között. Azok a programok tehát nyilván nem profitálnak a streamesítésbõl, illetve nem alakíthatóak át ilyen módon.

De ettõl még igaz az, hogy egy halom alkalmazásban - 3D grafika, számításigényes alkalmazások, ... - a processzorok hatékonysága nõtt. Néhány esetben meg esetleg nem nõtt. Például a SPEC programok alatt a P4-ek hatékonysága például nem hiszem, hogy nõtt volna a P3-hoz képest (noha az Opteron szériáé igen).

[hvuk]

idézet:

---

Ezt írta Rive:

Szóval, miért is kell fcpu/2-vel meghajtani egy on-chip SRAM-blokkot? Miért is kell - szerinted - egy nagyobb gyorsítótárnak lassabbnak lennie egy olyan prociban, ahol minden valószínûség szerint pillanatnyilag is több milliónyi tranzisztort hagynak kihasználatlanul?

[/quote]

Tény, hogy több olyan cikket is olvastam, ahol azt elemzegették, hogy a kihozatal (yield) szûk keresztmetszete egyre inkább az L2 cache lesz. Ezek alapján feltételezhetõ, hogy valamikor a késöbbiekben nem a magsebességen fog futni az L2.

Nm biztos, hogy kell hogy lassabb legyen az L2 cache, de az biztos, hogy az Intelnek ezt nem sikerült megoldani, azaz szignifikánsan nõtt a latency. Tehát lehet, hogy elméletileg nem kell, hogy nõjön a késleltetés, de gyakorlatilag mégis nõtt. És a puding próbája az, hogy megeszik.

[SFIJ]

idézet:

---

Ezt írta Rive:

Gratulálok
Ügyesen ködösítesz. Nagyon. Mondd, kifejtenéd végre, hogy mi is van azzal a szerencsétlen Prescott gyorsítótárral? Mer' amit a másik topikban írtál, az heveny röhögõgörcsök keltésén túl nem sok mindenre elég
Szóval, miért is kell fcpu/2-vel meghajtani egy on-chip SRAM-blokkot? Miért is kell - szerinted - egy nagyobb gyorsítótárnak lassabbnak lennie egy olyan prociban, ahol minden valószínûség szerint pillanatnyilag is több milliónyi tranzisztort hagynak kihasználatlanul?

[ 2004. február 10.: Rive szerkesztette a hozzászólást ][/quote]


Kedves Rive, ez itt offtopik. Erveimet a kerdeses topikban leirtam. vitatni lehet ertelmesen es kulturaltan. Alapveto dolgokat azert elvarok egy argumentacioval kapcsolatban - vagy ird oda, hogy baromira nem komalod a buram, es akkor tiszta sor...

[Haderach]

idézet:

---

Ezt írta Rive:

Szóval, miért is kell fcpu/2-vel meghajtani egy on-chip SRAM-blokkot? Miért is kell - szerinted - egy nagyobb gyorsítótárnak lassabbnak lennie egy olyan prociban, ahol minden valószínûség szerint pillanatnyilag is több milliónyi tranzisztort hagynak kihasználatlanul?
[/quote]

Bár nem nekem, szól, én is reagálnék rá.
Ha azt feltételezzük, hogy a SRAM technológia adott, azaz nem fognak kitalálni olyan SRAMot, ami adott csíkszélességen adott technológia mellett nagyobb órajelet és/vagy kisebb késleltetést tud, akkor az SRAMok teljesítményének növelésére egyetlen mód a gyártástechnológia javítása, azaz többek között a csíkszélesség csökkentése. de a processzorok órajel is kapcsolatban áll a csíkszélességgel, de ott be tudnak vetni más fegyvereket is: futószalag-hosszabbítás, újabb stepping, meg hasonlók. ezeket figyelembe véve nem elképzelhetõ, hogy a processzorok órajele meghaladja majd azt a maximumot, amit az adott elõállítási technológia mellett az adott mennyiségû és felépítésû SRAM el tud érni?

[SFIJ]

idézet:

---

Ezt írta Miracle:


Bár nem nekem, szól, én is reagálnék rá.
Ha azt feltételezzük, hogy a SRAM technológia adott, azaz nem fognak kitalálni olyan SRAMot, ami adott csíkszélességen adott technológia mellett nagyobb órajelet és/vagy kisebb késleltetést tud, akkor az SRAMok teljesítményének növelésére egyetlen mód a gyártástechnológia javítása, azaz többek között a csíkszélesség csökkentése. de a processzorok órajel is kapcsolatban áll a csíkszélességgel, de ott be tudnak vetni más fegyvereket is: futószalag-hosszabbítás, újabb stepping, meg hasonlók. ezeket figyelembe véve nem elképzelhetõ, hogy a processzorok órajele meghaladja majd azt a maximumot, amit az adott elõállítási technológia mellett az adott mennyiségû és felépítésû SRAM el tud érni?[/quote]


Nos itt a csont akarom mondani a pont. 2 dolgot tehetsz, ha a die 1/3-at elfoglalo RAMoszaurusz sebessege korlatozni kezdi az fcore frekit:
-Hierarchikus cache-t csinalsz-> no a latency
-A Cache 2/3, 3/4, 1/2, 1/3 fcpu-val jar

[Rive]

idézet:

---

Ezt írta hvuk:
. Az AMD nyilván nem fog tudni 2.4 GHz-nél gyorsabb procit 130 nanon bemutatni...[/quote]

Állítólag bemutatott 90 nanos K8 mintapéldányokat, nem magasabb frekvencián.

Amúgy, kérlek használd következetesen a bemutatni és a kihozni szavakat. Egy gyors K8 mostani kihozatalával kapcsolatban teljesen egyetértünk...

idézet:

---

Ezt írta hvuk:
Nem, hanem arról, hogy esetleg az Itaniumra nem is írható a lehetõségeit normálisan kihasználható fordító.[/quote]

Én megelégszem azzal, ha még 50% benne van a compilerben az x86-hoz képest Az pedig bennevan

idézet:

---

Ezt írta hvuk:
Nem tudom mit értsz általános célú programok alatt...[/quote]

Amit magasabbszintû nyelvekbõl fordítanak, compilerrel. Ami miatt nem nyúl, vagy nem nyúlhat senki assemblyhez
(Nem, ne köss bele, hogy vannak határterületek. Vannak. de pl. egy hetente átírt kvantummechanikai számítást ne hasonlíts pl. a SciMark rutinjaihoz.)

idézet:

---

Ezt írta hvuk:
Tény, hogy több olyan cikket is olvastam, ahol azt elemzegették, hogy a kihozatal (yield) szûk keresztmetszete egyre inkább az L2 cache lesz. Ezek alapján feltételezhetõ, hogy valamikor a késöbbiekben nem a magsebességen fog futni az L2.

Nm biztos, hogy kell hogy lassabb legyen az L2 cache, de az biztos, hogy az Intelnek ezt nem sikerült megoldani, azaz szignifikánsan nõtt a latency. Tehát lehet, hogy elméletileg nem kell, hogy nõjön a késleltetés, de gyakorlatilag mégis nõtt. És a puding próbája az, hogy megeszik. [/quote]

Nem a sebesség a kihozatal gátja, hanem a fizikai - magon elfoglalt - méret. Egyre nagyobb esélye van annak, hogy a cache területére esik valami hiba.

A kell szimplén hülyeség a P3 óta. Nem kell, hanem a tervezõk szerint felesleges.
A processzorok fõbb paramétereit szimulátorok segítségével lövik be: adott core mellé olyan képességû gyorsítótár-rendszert választanak, ami a kívánt hatékonyságot biztosítja a megcélzott órajel-tartományban. Az, hogy nagyobb késleltetésû gyorsítótárat választottak a Prescotthoz, annyit jelent: a szimulátor kisebb késleltetésû gyorsítótár esetén nem jósolt olyan sebességnövekedést, ami miatt érdemes lett volna azt megvalósítani. Ennyi. Semmi kell.

[ 2004. február 10.: Rive szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta Miracle:
Bár nem nekem, szól, én is reagálnék rá.
Ha azt feltételezzük, hogy a SRAM technológia adott, azaz nem fognak kitalálni olyan SRAMot, ami adott csíkszélességen adott technológia mellett nagyobb órajelet és/vagy kisebb késleltetést tud, akkor az SRAMok teljesítményének növelésére egyetlen mód a gyártástechnológia javítása, azaz többek között a csíkszélesség csökkentése. de a processzorok órajel is kapcsolatban áll a csíkszélességgel, de ott be tudnak vetni más fegyvereket is: futószalag-hosszabbítás, újabb stepping, meg hasonlók. ezeket figyelembe véve nem elképzelhetõ, hogy a processzorok órajele meghaladja majd azt a maximumot, amit az adott elõállítási technológia mellett az adott mennyiségû és felépítésû SRAM el tud érni?[/quote]

A gyorsítótárban alkalmazott SRAM gyakorlatilag azonos felépítésû a regisztereket alkotóval: a körítés más, egyszerûbb.
Szerinted?

[SFIJ]

idézet:

---

Ezt írta Rive:
Az, hogy nagyobb késleltetésû gyorsítótárat
választottak a Prescotthoz, annyit jelent: a szimulátor kisebb késleltetésû gyorsítótár esetén nem jósolt olyan sebességnövekedést, ami miatt érdemes lett volna azt megvalósítani. Ennyi. Semmi kell.
[/quote]
Vagy annyit, hogy dragabb eloallitani a kerdeses
dugimemoriat, lerontana a yiledet, stabilitasi
gondokat vetne fel, az adott techologiaval dolgozo
low latency cache lehetetlenne tenne a termek kivant
bearazodasat, staobbi, satobbi, satobbi.

idézet:

---

Ezt írta Rive:
A gyorsítótárban alkalmazott SRAM gyakorlatilag azonos felépítésû a regisztereket alkotóval: a körítés más, egyszerûbb.
[/quote] Erre azrt nem vennek merget.
-van meretbeli kuonbseg
-van fogyasztasbeli kulonbseg
-van cimzesbeli kulonbseg
En amugy nem vennek arra merget hogy SRAM-okbol all a cache.

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

[Haderach]

idézet:

---

Ezt írta Rive:


A gyorsítótárban alkalmazott SRAM gyakorlatilag azonos felépítésû a regisztereket alkotóval: a körítés más, egyszerûbb.
Szerinted?[/quote]

de a regisztereknek nincsen 64/128/nemtudommennyi bites memóriabusza, meg nincsen egymásmellett pár-milió, hogy jó nagy interferenciát gerjesszenek, arról meg nem is beszélve, hogy a jelnek a RAMblokk másik felébe is el kell érnie bizonyos idõ alatt, meg vissza az adatnak. ezekkel a problémákkal szerintem a regisztereknek nem kell megküzdeniük. nomeg ugye ezek ha jól emlékszem kétszeresen(vagy többszörösen) asszociatív memóriák... a regiszterekkel ellentétben. vagy ezek nem számítanak?(komolyan kérdezem, mert nem tudom)

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
Kedves Rive, ez itt offtopik. Erveimet a kerdeses topikban leirtam. vitatni lehet ertelmesen es kulturaltan. Alapveto dolgokat azert elvarok egy argumentacioval kapcsolatban - vagy ird oda, hogy baromira nem komalod a buram, es akkor tiszta sor...[/quote]

'Érveidben' nem találtam semmi olyat, ami az én elektronikai tervezéssel (is) foglalkozó elmeszerûségem számára bármilyen mértékben is érvnek tûnt volna.
Erre ott felhívtam a figyelmedet, és további magyarázatot kértem. Cserébe semmi.

Tovább magyarázod és folytatod a szarkeverést, vagy végre megpróbálod leírni, mire is gondoltál?

[SFIJ]

idézet:

---

Ezt írta Rive:


'Érveidben' nem találtam semmi olyat, ami az én elektronikai tervezéssel (is) foglalkozó elmeszerûségem számára bármilyen mértékben is érvnek tûnt volna.
Erre ott felhívtam a figyelmedet, és további magyarázatot kértem. Cserébe semmi.

Tovább magyarázod és folytatod a szarkeverést, vagy végre megpróbálod leírni, mire is gondoltál?[/quote]


ugyanitt meg1x osszefogalaltam. Ha szerinted erveim nem 'ervek' szamodra akkor igy jartam...

[Rive]

idézet:

---

Ezt írta Miracle:
de a regisztereknek nincsen 64/128/nemtudommennyi bites memóriabusza, meg nincsen egymásmellett pár-milió, hogy jó nagy interferenciát gerjesszenek, arról meg nem is beszélve, hogy a jelnek a RAMblokk másik felébe is el kell érnie bizonyos idõ alatt, meg vissza az adatnak. ezekkel a problémákkal szerintem a regisztereknek nem kell megküzdeniük. nomeg ugye ezek ha jól emlékszem kétszeresen(vagy többszörösen) asszociatív memóriák... a regiszterekkel ellentétben. vagy ezek nem számítanak?(komolyan kérdezem, mert nem tudom)[/quote]

Az asszociatív memóriák részben meghatározzák a sebességet, bár elrendezésük, szerepük némileg más, mint amit a hozzászólásodból saját ismereteidnek lehet sejteni. Azok ugyanis a megfelelõ cacheline kiválasztását, azaz a fizikai cím komparálását végzik, nem az adatok tárolását.
Mostanra az asszociatív rész már nem korlát. 1mm2 alatt van 1^6 tranzisztor. Szabadon, csak a kitûzött teljesítmény érdekében lehet garázdálkodni.
A többi nem számít. Gondolj utána, mekkor a zsúfoltság, mekkorák a távolságok a core egészében, és hogy mekkora regiszterblokkok vannak ott.

[ 2004. február 10.: Rive szerkesztette a hozzászólást ]

[Haderach]

idézet:

---

Az asszociatív memóriák számítanak, bár azok elrendezése némileg más, mint amit a hozzászólásodból saját ismereteidnek lehet sejteni. Azok ugyanis a megfelelõ cacheline kiválasztását, azaz a fizikai cím komparálását végzik, nem az adatok tárolását. [/quote]

azzal tisztában vagyok, hogy mire jó az nutasan asszociatív memória, de szerintem azok nem kicsit kellene, hogy lassítsanak. mert a létezés eldöntéséhez meg kell vizsgálni az egy cache-címre asszociált összes címet(hú ez de magyartalan de nem tudom jobban megfogalmazni most) tehát egy memóóriamûvelet elõtt biztosan egyszer meg kell vizsgálni.

idézet:

---

A többi nem számít. Gondolj utána, mekkor a zsúfoltság, mekkorák a távolságok a core egészében, és hogy mekkora regiszterblokkok vannak ott.[/quote]
jó, nagy a core, de az 31 lépcsõ, +memóriavezérlõ, FSB vezérlõ L1 meg CU, meg egy csomó minden, amik egymástól viszonylag függetlenül mûködnek. nem teljesen függetlenül értelem szerûen, mert akkor a proci semmit sem csinálna(mondjuk esetleg szép randomgenerátor lenne) de azok a részegységek minden órajelciklus elején megkapják a bemenõ adatokat, és az órajel ciklus alatt egymástól függetlenül állítják be a megfelelõ kapuikat úgy, ahogy tervezve lettek. de ott egy órajel alatt csak a DIE egy kis része van kapcsolatban közvetlenül egymással, a cache meg a DIE 1/3 -a... remélem érted amit mondok, és ha érted, nem mondtam nagy hülyeséget....

[ 2004. február 10.: Miracle szerkesztette a hozzászólást ]

[SFIJ]

idézet:

---

Ezt írta Rive:

Mostanra az asszociatív rész már nem korlát. [/quote]
Namost valszeg en vagyok a huje, de egy asszociativ tar hozzaferesi ideje - szerintem - eredendoen az adat kikeresesi idejetol fugg. Minel nagyobb a blokk, ennek az asszociativ lekepzest vegzo funkcionalis egysegnek a merete annal nagyobb, igy az adott megvalositas eseten a jelterjedesi korlatozasok miatt adodik egy maximalis hozzaferesi sebesseg.

idézet:

---

Ezt írta Rive:

de ott egy órajel alatt csak a DIE egy kis része van kapcsolatban közvetlenül egymással, a cache meg a DIE 1/3 -a... remélem érted amit mondok, és ha érted, nem mondtam nagy hülyeséget....
[/quote]
Amikor a kerdeses 'topicban' ementem is erveltem, nos akkor 'hulzezett' le Rive bacsi

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

[special]

idézet:

---

Ezt írta T2k:
Csak ugy megjegyzem, erdekessegkeppen: egy honapja nyuzom lassan a dual Opteron 248-asainkat...

A "tesztekhez" ill. ertelmukhoz, megbizhatosagukhoz annyit tennek hozza, hogy a dual 3.06-os Xeonjaimnal 50 szazalekkal gyorsabb 3dsmax (renderer: brazil) alatt a dual Opteron...
Mas: volt itt az AMD, ugy nez ki, kapunk toluk 100 dual Opteront iden... beszelgettunk a varhato ev vegi allapotokrol... haaat... nekem kikerekedtek a szemeim annak hallatan, mire szamithatok UGYANEZEN PIN LAYOUTTAL...

PS: Fiery, csend legyen... [/quote]

Nyilván dual CMP, 2 MB L2 cache, esetleg SMT is. Mondjuk 2.6-8 GHz-en. Mennyire talált? Mondjuk Fierybõl úgyis kiszedem.

[SFIJ]

idézet:

---

Ezt írta special:


Nyilván dual CMP, 2 MB L2 cache, esetleg SMT is. Mondjuk 2.6-8 GHz-en. Mennyire talált? Mondjuk Fierybõl úgyis kiszedem. [/quote]


CMP+SMT? 4 logikai CPU 1 tokban? ajjaj

[Rive]

idézet:

---

Ezt írta Miracle:
azzal tisztában vagyok, hogy mire jó az nutasan asszociatív memória, de szerintem azok nem kicsit kellene, hogy lassítsanak. mert a létezés eldöntéséhez meg kell vizsgálni az egy cache-címre asszociált összes címet(hú ez de magyartalan de nem tudom jobban megfogalmazni most) tehát egy memóóriamûvelet elõtt biztosan egyszer meg kell vizsgálni.[/quote]

Párhuzamos folyamat, egy órajel alatt két összehasonlítással. Ha valaki nagyon siet, akkor minden cacheline-ra párhuzamosan, azaz egy órajel alatt két cacheline kereshetõ ki. Ez a szélsõséges eset.
Ha nem ennyire sietõs, akkor több lépcsõs logikát alkalmaznak - ez azonban ma már inkább választási lehetõség, nem korlát.

idézet:

---

Ezt írta Miracle:
...de ott egy órajel alatt csak a DIE egy kis része van kapcsolatban közvetlenül egymással, a cache meg a DIE 1/3 -a... remélem érted amit mondok, és ha érted, nem mondtam nagy hülyeséget....[/quote]

Pl. a regiszterblokk a VE elejével és végével is kapcsolatban van. Emellé a memória-vezérlõvel is, valamint ehhez jön egy valag bypass.

[ 2004. február 10.: Rive szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta Supposed Former Infatuation Junkie:
Namost valszeg en vagyok a huje, de egy asszociativ tar hozzaferesi ideje - szerintem - eredendoen az adat kikeresesi idejetol fugg. Minel nagyobb a blokk, ennek az asszociativ lekepzest vegzo funkcionalis egysegnek a merete annal nagyobb, igy az adott megvalositas eseten a jelterjedesi korlatozasok miatt adodik egy maximalis hozzaferesi sebesseg.[/quote]

Az adat különbözik a nyilvántartásától. Az asszociatív egység mérete sokkal kisebb, mint a SRAM-blokké.

[SFIJ]

idézet:

---

Ezt írta Rive:


Az adat különbözik a nyilvántartásától. Az asszociatív egység mérete sokkal kisebb, mint a SRAM-blokké.[/quote]
Az allitas elso fele tautologia, a masodik fele igaz ugyan, de irrevelans:
- Az asszociativ resz 'lappangasi ideje' fugg attol, hogy mekkora meretu SRAM reszhez kell legyartani az asszociaciokat, illetve hogy mekkora az asszociacio parameterenek az ertekkeszlete.
- Az asszociativ resz altal meghajtott belso cimbuszra kirakott cimvezeteket az SRAM resz egyfelol tereheli, mareszt a ciminformaciot valahogy el kell vezetni az elemi cacheline cellakhoz.

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