HWSW Informatikai Kerekasztal: AMD Hammer - negyedik rész - HWSW Informatikai Kerekasztal

Ugrás a tartalomhoz

Mellékleteink: HUP | Gamekapocs

  • (153 Oldal)
  • +
  • « Első
  • 114
  • 115
  • 116
  • 117
  • 118
  • Utolsó »
  • Nem indíthatsz témát.
  • A téma zárva.

AMD Hammer - negyedik rész Értékeld a témát: -----

#2301 Felhasználó inaktív   dezz 

  • Törzsvendég
  • PipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 740
  • Csatlakozott: --

Elküldve: 2007. 03. 28. 12:18

Idézet: hvuk - Dátum: 2007. márc. 21., szerda - 12:56

Sok vita folyik róla, hogy vajon mire gondoltak, mert ráadásul volt olyan nyilatkozat, ami sok alkalmazásról beszélt. A legvalószínűbb az, hogy mind a 4 magot kihasználó szerveralkalmazásokról beszélt (specintrate pl.). A Core 2 architketúra nagy előnye, hogy az L2 cache osztott, ami miatt ha csak az egyik proci használt, akkor az kisajátíthatja magának az egész cache-t jelentősen megdobva így a teljesítményt. Nyilván ha minden mag ki van használva, akkor ez az előny eltűnik.

A "wide range of applications" inkább a floating point teljesítménnyel kapcsolatban hangzott el (nem csoda, az SSE teljesítmény nőtt ennyire jelentősen). Az integer teljesítménynövekedés valószínűleg elég általános, jópár kisebb-nagyobb tuningolás alapozza meg.

#2302 Felhasználó inaktív   Balala 

  • Tag
  • PipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 169
  • Csatlakozott: --

Elküldve: 2007. 03. 28. 14:46

Hello,

Quad Core Processor Overview, 2007 Feb. A 10. oldal utan jonnek az uj infok, foleg a L1D cache-rol es a prefetchrol.
2006 novemberi cucc, de szep osszefoglalas. (Csak a cimlap nem latin betus...) (bocs, ha volt mar...)

Udv,
Balala

#2303 Felhasználó inaktív   Balala 

  • Tag
  • PipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 169
  • Csatlakozott: --

Elküldve: 2007. 03. 29. 09:25

Hello,

Ez innen van:
Kép
Ez ha jol latom kb. 150-160 SPECfp_rate2000-et mutat, 2.3GHz-en.
(A szoveg szerint szimulacio, de nem hinnem, hogy par honappal a release elott hazon belul nem tudnak SPEC-et futtatni...)

Udv,
B.

#2304 Felhasználó inaktív   special 

  • project 2501
  • PipaPipaPipaPipaPipa
  • Csoport: Stábtag
  • Hozzászólások: 11.962
  • Csatlakozott: 2001. jan. 16.

Elküldve: 2007. 03. 29. 09:40

a 9-es slide az überlol.

#2305 Felhasználó inaktív   d n . r 

  • Senior tag
  • PipaPipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 2.211
  • Csatlakozott: --

Elküldve: 2007. 03. 29. 09:40

Arra van valakinek ötlete, hogy miért még mindig spec2000-rel mérnek és miért nem spec2006-tal?

(mondjuk _én_ amúgy is inkább a real-life proramokkal végzett teszteket várom)

#2306 Felhasználó inaktív   d n . r 

  • Senior tag
  • PipaPipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 2.211
  • Csatlakozott: --

Elküldve: 2007. 03. 29. 09:44

Idézet: special - Dátum: 2007. márc. 29., csütörtök - 9:40

a 9-es slide az überlol.

Hát tényleg az.

#2307 Felhasználó inaktív   special 

  • project 2501
  • PipaPipaPipaPipaPipa
  • Csoport: Stábtag
  • Hozzászólások: 11.962
  • Csatlakozott: 2001. jan. 16.

Elküldve: 2007. 03. 29. 09:48

találtam egy másik gyót:

http://www.samss.org...-meeting/07.pdf

Kép

#2308 Felhasználó inaktív   d n . r 

  • Senior tag
  • PipaPipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 2.211
  • Csatlakozott: --

Elküldve: 2007. 03. 29. 10:39

Idézet: special - Dátum: 2007. márc. 29., csütörtök - 9:48

találtam egy másik gyót:
(...)

Igen, ezt én is kiszúrtam magamnak tegnap a pdf-ben... :)
Épp ezt nem értem: ha teljesítményben ennyire szuperior lesz, akkor a marketingeseknek mi a ráknak kell lemenni teljesen ultragagyiba?  :confused:  Na mind1.

#2309 Felhasználó inaktív   special 

  • project 2501
  • PipaPipaPipaPipaPipa
  • Csoport: Stábtag
  • Hozzászólások: 11.962
  • Csatlakozott: 2001. jan. 16.

Elküldve: 2007. 03. 29. 10:51

de a vicc az benne, hogy azok előtt, akik kicsit is értenek hozzá, magukat járatják le, sőt készségesen bebizonyítják, hogy rosszabb TDP mutatókkal rendelkeznek, és Otellininek igaza van. és hát ilyen slide-okat nem a mónika showban szoktak elemezni.

#2310 Felhasználó inaktív   dezz 

  • Törzsvendég
  • PipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 740
  • Csatlakozott: --

Elküldve: 2007. 03. 29. 12:32

Idézet: special - Dátum: 2007. márc. 29., csütörtök - 10:51

de a vicc az benne, hogy azok előtt, akik kicsit is értenek hozzá, magukat járatják le, sőt készségesen bebizonyítják, hogy rosszabb TDP mutatókkal rendelkeznek, és Otellininek igaza van. és hát ilyen slide-okat nem a mónika showban szoktak elemezni.

Jó, ez így kicsit vicces, de az volt itt a lényeg (beszéltek is róla), hogy az új AMD chipek BIOS-frissítéssel mehetnek a meglévő rendszerekbe, szerverekbe, és semmi sem változik, csak a teljesítmény, az Intel procikhoz meg új kell (és elvileg még úgy sem tudnak annyit).

Otellini meg nem igazán a TDP-re gondolt.

Ami a 9-es (pontosabban 8-as) slide-ot illeti a másikban: máshol részletesen ki volt fejtve, mi miért előnyös a másikhoz képest.

Szerkesztette: dezz 2007. 03. 29. 12:34 -kor


#2311 Felhasználó inaktív   special 

  • project 2501
  • PipaPipaPipaPipaPipa
  • Csoport: Stábtag
  • Hozzászólások: 11.962
  • Csatlakozott: 2001. jan. 16.

Elküldve: 2007. 03. 29. 12:54

Idézet: dezz - Dátum: 2007. márc. 29., csütörtök - 13:32

Jó, ez így kicsit vicces, de az volt itt a lényeg (beszéltek is róla), hogy az új AMD chipek BIOS-frissítéssel mehetnek a meglévő rendszerekbe, szerverekbe, és semmi sem változik, csak a teljesítmény, az Intel procikhoz meg új kell (és elvileg még úgy sem tudnak annyit).




Nem igaz, hogy új alaplap kellene, ha a gyártója teljesítette a specifikációkat. A DC-->QC átállás szimpla procicsere/BIOS-frissítés az Intel oldalán is (1-2-way szerver, asztali), a szoftverek persze más kérdés.

Idézet

Otellini meg nem igazán a TDP-re gondolt.


Olyan idézetet raktak be tőle, amelyen legfeljebb bölcsészek kezdenének el vitatkozni, hogy "mi is az igazság, mi az élet értelme". Az, hogy multi-chip package vagy monolitikus design, irreleváns paraméter a vevő számára. Teljesítmény van, fogyasztás van, RAS van, költség van.

Idézet

Ami a 9-es (pontosabban 8-as) slide-ot illeti a másikban: máshol részletesen ki volt fejtve, mi miért előnyös a másikhoz képest.


Lássuk sorban:

1. irreleváns.
2. önmagában irreleváns. ugyanakkora, de mekkora? a top bin SKU-k kivételével mindegyik DC és QC chip TDP-je magasabb, mint az inteles társáé, és az Intelnél sem volt a növekedésből probléma. összességében ez a pont egy fasság.
3. ez mint előny, LOL. a shared cache megfelelő mérettel, asszociativitással és konfliktuskezelési algoritmussal a legtöbb asztali alkalmazás alatt szuperior a dedikálthoz képest. utóbbi előnye az egyszerűbb architektúrális felépítés, és szerverloadoknál a magok folyamatos magas cache-használata miatt nem éri meg a befektetést, sőt rosszabb is lehet. de egyébként is irreleváns.
4. ez már ROTFL. ez biztos azért előny, mert az egyszerű, kisméretű dedikált L2-k miatt a szükség van már rá. irreleváns.
5. első valóságos állítás. kérdés, hogy a DDR2 és az FB-DIMM DDR2 hogyan viszonyul egymáshoz teljesítményben különféle workloadok alatt.
6. rizsa. persze ha az új chipek virtualizációs teljesítménye jóval magasabb lesz az intelénél, akkor pont lehet.
7-8. :D no komment.

tehát van egy-egy fél lábon álló 5-6-os pontunk, vagyis hétből egyet megszavazok. ügyes munka volt.

#2312 Felhasználó inaktív   dezz 

  • Törzsvendég
  • PipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 740
  • Csatlakozott: --

Elküldve: 2007. 03. 29. 13:39

Idézet: special - Dátum: 2007. márc. 29., csütörtök - 12:54

Nem igaz, hogy új alaplap kellene, ha a gyártója teljesítette a specifikációkat. A DC-->QC átállás szimpla procicsere/BIOS-frissítés az Intel oldalán is (1-2-way szerver, asztali), a szoftverek persze más kérdés.

Pl. az emlegetett 5355-ösnek, és néhány másiknak 1333 MHz-es FSB-je van, a korábbi lapok hivatalosan 1066-ot támogatnak.
Plusz az Intel oldalon megnövekedő villany-költségekkel kell számolni, amihez relatíve kisebb teljesítmény-növekedés társul.

Idézet

Olyan idézetet raktak be tőle, amelyen legfeljebb bölcsészek kezdenének el vitatkozni, hogy "mi is az igazság, mi az élet értelme". Az, hogy multi-chip package vagy monolitikus design, irreleváns paraméter a vevő számára. Teljesítmény van, fogyasztás van, RAS van, költség van.

Mint AMD-éknél is mondták, nem ez a releváns önmagában, hanem ami vele jár: nincs szűk keresztmetszet a memória és a rendszer felé az FSB miatt; gyorsabb inter-core adatcsere.

Idézet

1. irreleváns.

Mint írtam, önmagában igen, de a (máshol részletesebben kifejtett) részletek miatt mégsem.

Idézet

2. önmagában irreleváns. ugyanakkora, de mekkora? a top bin SKU-k kivételével mindegyik DC és QC chip TDP-je magasabb, mint az inteles társáé, és az Intelnél sem volt a növekedésből probléma. összességében ez a pont egy fasság.

Oké, nyilván nem az számít igazán, hogy ugyanakkora, hanem a telj./fogy., viszont legalább egyszerűen tudomásul lehet venni, hogy a fogy. nem változik, elég a teljesítmény-növekedéssel számolni. :)

Idézet

3. ez mint előny, LOL. a shared cache megfelelő mérettel, asszociativitással és konfliktuskezelési algoritmussal a legtöbb asztali alkalmazás alatt szuperior a dedikálthoz képest. utóbbi előnye az egyszerűbb architektúrális felépítés, és szerverloadoknál a magok folyamatos magas cache-használata miatt nem éri meg a befektetést, sőt rosszabb is lehet. de egyébként is irreleváns.

Ezt is kifejtették máshol részletesebben, hogy szerintük miért jó.

Idézet

4. ez már ROTFL. ez biztos azért előny, mert az egyszerű, kisméretű dedikált L2-k miatt a szükség van már rá. irreleváns.

Ezt is.

Idézet

6. rizsa. persze ha az új chipek virtualizációs teljesítménye jóval magasabb lesz az intelénél, akkor pont lehet.

Nem rizsa, ennek újításai is ki vannak fejtve máshol.

Idézet

7-8. :D no komment.

A 7-eshez nem értek, mennyire számít, de 8-ason mi a no comment? Az nem előny, hanem megjelenési időpont. :)

(Az Enhanced PowerNow!-t kihagytad.)

Idézet

tehát van egy-egy fél lábon álló 5-6-os pontunk, vagyis hétből egyet megszavazok. ügyes munka volt.

Ez a táblázat nem valami önmagában álló érv-lista volt, hanem csak máshol kifejtett dolgok összefoglalója. A részleteket kell nézni.

Szerkesztette: dezz 2007. 03. 29. 13:42 -kor


#2313 Felhasználó inaktív   special 

  • project 2501
  • PipaPipaPipaPipaPipa
  • Csoport: Stábtag
  • Hozzászólások: 11.962
  • Csatlakozott: 2001. jan. 16.

Elküldve: 2007. 03. 29. 15:10

éppen a mögötte lévő részletek miatt fájdalmas az a slide. a powernow!-t valóban kifelejtettem, pedig az a legjobb: nincs amd technológia az intel prociban. :D ha legalább DBS-t írtak volna, de az meg van.

1.  a Bensley platform kezdettől támogatta a QC-t, 2006 tavaszától, és a Core 2 megjelenésével az asztali oldalon is megjelent a támogatás QC-re.
2. tehát irreleváns. ha jó a nő segge, az számít, hogy hogyan érte el, az nem.
3. ha megengeded, nem ők a hiteles forrás. ez a kérdés máshol részletesebben tárgyalt, és a konklúzió az, hogy a shared cache architektúra fejlettebb. de tedd fel a kérdést: az intel miért költött erre erőforrásokat, ha nem előnyös?
4. lásd előző. a shared L3-ra az L2 miatt van szükség, az L2-t pedig azért hagyták dedikáltnak, mert ez volt az olcsóbb tervezési, és gyárthatósági oldalról is (kis die a volumenchipekez, L3 nélkül)
5. :D
6. majd ha látom a virtualizációs teljesítményt, elhiszem.
7. az a megjelenés. azért jelenik meg egyszerre, mert a 2P fél évvel később kerül piacra az Intelhez képest.
8. :D

#2314 Felhasználó inaktív   SFIJ 

  • Őstag
  • PipaPipaPipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 20.145
  • Csatlakozott: --

Elküldve: 2007. 03. 29. 15:30

Idézet: special - Dátum: 2007. márc. 29., csütörtök - 9:40

a 9-es slide az überlol.

mos nemtom mit izelsz. minden igaz, ami a slideon van :)
νιψονανωμηματαμημωνανοψιν

What do stars do? They shine.(Yvaine)

#2315 Felhasználó inaktív   SFIJ 

  • Őstag
  • PipaPipaPipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 20.145
  • Csatlakozott: --

Elküldve: 2007. 03. 29. 15:32

Idézet: d n . r - Dátum: 2007. márc. 29., csütörtök - 10:39

Igen, ezt én is kiszúrtam magamnak tegnap a pdf-ben... :)
Épp ezt nem értem: ha teljesítményben ennyire szuperior lesz, akkor a marketingeseknek mi a ráknak kell lemenni teljesen ultragagyiba?  :confused:  Na mind1.

ne varj sokat bolcseszektol :Đ
νιψονανωμηματαμημωνανοψιν

What do stars do? They shine.(Yvaine)

#2316 Felhasználó inaktív   dezz 

  • Törzsvendég
  • PipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 740
  • Csatlakozott: --

Elküldve: 2007. 03. 29. 16:49

Idézet: special - Dátum: 2007. márc. 29., csütörtök - 15:10

a powernow!-t valóban kifelejtettem, pedig az a legjobb: nincs amd technológia az intel prociban. :D ha legalább DBS-t írtak volna, de az meg van.

Nyilván nem az elnevezés volt a lényeg. Vajon az Inteles DBS kiterjed a legkisebb számú mag működtetésére (és a többi kikapcsolására), vagy pl. erre?
Kép

Idézet

1.  a Bensley platform kezdettől támogatta a QC-t, 2006 tavaszától, és a Core 2 megjelenésével az asztali oldalon is megjelent a támogatás QC-re.
2. tehát irreleváns. ha jó a nő segge, az számít, hogy hogyan érte el, az nem.

Igen, irreleváns, amit az 1.-esben írsz :), mert így is gyakran válik szűk keresztmetszetté az FSB. A 1333MHz meg csak nemrég óta elérhető.

Idézet

3. ha megengeded, nem ők a hiteles forrás. ez a kérdés máshol részletesebben tárgyalt, és a konklúzió az, hogy a shared cache architektúra fejlettebb.

Oké, ez az elmélet, de a gyakorlat adott esetben lehet más. A két mag zavarhatja egymás L2 elérését.

Idézet

de tedd fel a kérdést: az intel miért költött erre erőforrásokat, ha nem előnyös?

Ez nem feltétlenül jó kérdés, az Intel számára néha fontosabb a marketing. :)

Idézet

4. lásd előző. a shared L3-ra az L2 miatt van szükség, az L2-t pedig azért hagyták dedikáltnak, mert ez volt az olcsóbb tervezési, és gyárthatósági oldalról is (kis die a volumenchipekez, L3 nélkül)

Bizonyára ez volt a legfontosabb, de ők más indokokat is írnak. Meg van itt valami olyasmi, hogy később a L2 v. a L3 valami más elektronikai megoldású lesz, és ahhoz is jobb ez a kialakítás, de ez most csak halványan rémlik.

Idézet

6. majd ha látom a virtualizációs teljesítményt, elhiszem.

Addig is egy slide, ami most akadt az utamba, a többi itt van.
Kép
(De a fenti doksikban is volt róla szó.)

#2317 Felhasználó inaktív   dezz 

  • Törzsvendég
  • PipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 740
  • Csatlakozott: --

Elküldve: 2007. 03. 30. 14:56

Intel Details Upcoming New Processor Generations. Csak az előzőekkel kapcsolatban emelnék ki 1-2 dolgot:

Idézet

(Nehalem)
- Superior multi-level shared cache leverages Intel® Smart Cache technology

Nocsak, hát mégis van jobb megoldás, mint a minnél nagyobb, shaded L2? :)

Idézet

(Penryn)
- Enhanced Intel® Virtualization Technology -- Penryn speeds up virtual machine transition (entry/exit) times by an average of 25 to 75 percent. This is all done through microarchitecture improvements and requires no virtual machine software changes.

A mai Conroe még a korábbi Shadow Page Tables megoldást használja. Abból, hogy nem változik a szoftveres rész, arra lehet következtetni, hogy a Penryn is azt fogja. Így valószínű csak a Nehalembe tervezi beletenni az Intel az Extended Page Tables megoldást, ami hasonló az AMD Nested Page Tables megoldásához, ami nem kis gyorsulást hoz. Tehát erősen jár a pont ezért a K10-nek a mai Conroe-alapú procikkal szemben, és úgy tűnik, még a Penrynnel szemben is...

Idézet

(Penryn)
- Intel Dynamic Acceleration Technology Enhanced Performance for Single Threaded Apps -- For the mobile Penryn processor, Intel has enhanced the Intel® Dynamic Acceleration Technology available in current Intel Core 2 processors. This feature uses the power headroom freed up when a core is made inactive to boost the performance of another still active core. Imagine a shower with two powerful water shower heads, when one shower head is turned off, the other has increased water pressure (performance).

Namost ezt elvileg a K10-es Enhanced PowerNow! is tudhatja (tehát lekapcsol 1-2-3 magot, és a maradék órajelét emeli). (Ráadásul az Intelnél csak a mobil változat fogja tudni. Plusz úgy tűnik, az utolsó képen látható megoldások - amik azt hiszem, az IBM-től származnak, és pl. a Cellnél is alkalmazottak - Intelnél csak a Nehalemtől lesznek.)
(Ide is jár a pont. :D )

Szerkesztette: dezz 2007. 03. 30. 15:15 -kor


#2318 Felhasználó inaktív   special 

  • project 2501
  • PipaPipaPipaPipaPipa
  • Csoport: Stábtag
  • Hozzászólások: 11.962
  • Csatlakozott: 2001. jan. 16.

Elküldve: 2007. 03. 31. 20:59

Idézet: dezz - Dátum: 2007. márc. 29., csütörtök - 17:49

Nyilván nem az elnevezés volt a lényeg. Vajon az Inteles DBS kiterjed a legkisebb számú mag működtetésére (és a többi kikapcsolására), vagy pl. erre?

Azt javaslom, hogy mielőtt vitába állsz egy ilyen komplexitású témában, kicsit olvass utána.

A 2006 elején megjelent Core Duóval már biztosan el lehet érni, hogy az egyik mag deep sleep state-be lépjen, ehhez azonban szoftveres támogatás kell, értelemszerűen. De elképzelhető, hogy korábbi Intel vagy AMD DC chipek is képesek rá.

A fine grained clock gating technika az Intelnél 2003 elején debütált a Baniasszal (Pentium M), 130 nanométeren, az AMD ebben legfeljebb felzárkózik.

Idézet

Igen, irreleváns, amit az 1.-esben írsz :), mert így is gyakran válik szűk keresztmetszetté az FSB. A 1333MHz meg csak nemrég óta elérhető.


Nem irreleváns, csak tévedésből írtam oda az 1-est. Az 1333 MHz FSB a Woodcresttel debütált tavaly nyár elején, a Bensley már korábban támogatta, tehát új infrastruktúrát sem igényelt, és hogy a busz a szűk keresztmetszet, az látod sok workload alatt igaz lehet, ugyanakkor gyakorlatilag mindenben veri az Opteronokat.


Idézet

Oké, ez az elmélet, de a gyakorlat adott esetben lehet más. A két mag zavarhatja egymás L2 elérését.


Igen, elképzelhető olyan szituáció, ahol a konfliktus és a méretből és asszociativitástból fakadó relatíve magasabb késleltetés jelentette overhead teljestíménycsökkenéshez vezethet, ez viszont statisztikailag az x86-os chipek által lefedett kódok esetében bizonyára kisebbséget képeznek, különben az Intel nem döntött volna a bevezetése mellett, ami egyébként gyökeres cache-hierarchia áttervezést és extra ráfordítást igényel -- nem beszélve a gyárthtósági hátrányról, ami az Intel szempontjából #1 prioritás.

Az osztott cache előnye többek között a magasabb kihasználtság, a koherencia biztosítása és ezátal az ilyen jellegű forgalom csökkentése és a cache és magok rendelkezésre álló sávszélességének hatékonyabb kihasználása, továbbá az I/O logika is egyszerűbb lehet az 1 L2 port miatt, és nagyobb sebességek érhetőek el. Osztott cache-t alkalmaz egyébként a Power4 és a Power5 is, az UltraSPARC IV+ és a Niagara is. Az Itanium egyelőre nem, és úgy tűnik, a Tukwila is dedikáltakat alkalmaz majd -- hogy miért, az jó kérdés, talán mert a folyamatosan magas többszálú terhelés miatt egyenletes a terhelés a magok között. Erre gondoltam, mikor azt írtam, hogy a nem biztos, minden esetben megéri a befektetést az osztott felépítés. Persze jó kérdés, hogy akkor a többi nagy szerver MPU-tervező is miért döntött mellette, és az Intel miért nem -- talán hogy minél alacsonyabban tartsa a késleltetéseket. Mindenesetre úgy tűnik, erre halad mindenki.

Tekintve, hogy a modern processzorok architekturális tervezése számítógépeken zajlik, és az egyes megoldásokat szimulátorokkal tesztelik le, mielőtt legyártanák, az elmélet és a gyakorlat elég közel van egymáshoz.

Idézet

Ez nem feltétlenül jó kérdés, az Intel számára néha fontosabb a marketing. :)


Mindenkinek a marketing a legfontosabb, akinek nem, az megdöglik. Már a sugallt felvetésed is blőd.


Idézet

Bizonyára ez volt a legfontosabb, de ők más indokokat is írnak. Meg van itt valami olyasmi, hogy később a L2 v. a L3 valami más elektronikai megoldású lesz, és ahhoz is jobb ez a kialakítás, de ez most csak halványan rémlik.


Talán SRAM helyett tervezik eDRAM vagy ZRAM alkalmazását L3-nak.

A virtualizációval kapcsolatban régóta ismert a nested pages bevezetése. A kérdés a teljesítménybeli vonatkozása volt.

Szerkesztette: special 2007. 03. 31. 21:54 -kor


#2319 Felhasználó inaktív   hvuk 

  • Senior tag
  • PipaPipaPipaPipa
  • Csoport: Fórumtag
  • Hozzászólások: 4.857
  • Csatlakozott: --

Elküldve: 2007. 03. 31. 23:45

Idézet: special - Dátum: 2007. márc. 31., szombat - 20:59

Igen, elképzelhető olyan szituáció, ahol a konfliktus és a méretből és asszociativitástból fakadó relatíve magasabb késleltetés jelentette overhead teljestíménycsökkenéshez vezethet, ez viszont statisztikailag az x86-os chipek által lefedett kódok esetében bizonyára kisebbséget képeznek, különben az Intel nem döntött volna a bevezetése mellett, ami egyébként gyökeres cache-hierarchia áttervezést és extra ráfordítást igényel -- nem beszélve a gyárthtósági hátrányról, ami az Intel szempontjából #1 prioritás.

Ehhez azért erősen hozzátartozik az, hogy az Intel a Nehalemmel követni fogja az AMD-t, azaz dedikáűlt L2 cache lesz és osztott L3 cache. Innentől nehezen védhető az, hogy a dedikált L1 + közös L2 jobb mint a dedikált L1 + L2 + közös L3 cache. Szerintem írjuk alá, hogy az AMD ebben előrébb jár. Mindenkinek az élete egyszerűbbé válik így. :D

Idézet

Az osztott cache előnye többek között a magasabb kihasználtság, a koherencia biztosítása és ezátal az ilyen jellegű forgalom csökkentése és a cache és magok rendelkezésre álló sávszélességének hatékonyabb kihasználása, továbbá az I/O logika is egyszerűbb lehet az 1 L2 port miatt, és nagyobb sebességek érhetőek el. Osztott cache-t alkalmaz egyébként a Power4 és a Power5 is, az UltraSPARC IV+ és a Niagara is. Az Itanium egyelőre nem, és úgy tűnik, a Tukwila is dedikáltakat alkalmaz majd -- hogy miért, az jó kérdés, talán mert a folyamatosan magas többszálú terhelés miatt egyenletes a terhelés a magok között. Erre gondoltam, mikor azt írtam, hogy a nem biztos, minden esetben megéri a befektetést az osztott felépítés. Persze jó kérdés, hogy akkor a többi nagy szerver MPU-tervező is miért döntött mellette, és az Intel miért nem -- talán hogy minél alacsonyabban tartsa a késleltetéseket. Mindenesetre úgy tűnik, erre halad mindenki.


Nem, mindenki afelé halad, hogy az utolsó cache szint osztott, az előtte lévők meg dedikáltak. Azt kell észrevenned - és ez az amit nem akarsz az istennek sem -, hogy az AMD cache-je is osztott, csak ők ezt nem az L2 szintjén, hanem az L3-nál valósítják meg. Vagy te komolyan azt hiszed, hogy nehezebb az L2 cache-t osztottá tenni mint az L3 cache-t? Mert a fenti megjegyzésed, ami szerint az Intel extra erőforrásokat feccölt bele ebbe, szerintem erre utal.

Idézet

Talán SRAM helyett tervezik eDRAM vagy ZRAM alkalmazását L3-nak.


Szerintem inkább a Fusionban fogják használni a GPU cache-jéhez. Mármint a ZRAM-ot.

Idézet

A virtualizációval kapcsolatban régóta ismert a nested pages bevezetése. A kérdés a teljesítménybeli vonatkozása volt.


Abban mindenki egyetért, hogy az Intel virtualizációja szar. Már a jelenlegi AMD verzióhoz képest is vannak hátrányai. A nested pages pedig minden eddigi cikk szerint is jó dolog és sokat fog javítani a virtualizációs teljesítményen.

Szerkesztette: hvuk 2007. 03. 31. 23:48 -kor

Athlon 64 939 2 GHz Winchester mag, GigaByte NF4 K8N Ultra-9 (passzív chipset), GigaByte X800 (passzív), 2x512 KingMax HC 500 MHz, Hitachi 160 Gb, NEC 3520, Coolink BAT01VS (1040 ford.), Chieftec 420W, Chieftec ház, Samsung 193P TFT monitor

#2320 Felhasználó inaktív   special 

  • project 2501
  • PipaPipaPipaPipaPipa
  • Csoport: Stábtag
  • Hozzászólások: 11.962
  • Csatlakozott: 2001. jan. 16.

Elküldve: 2007. 04. 01. 00:28

Idézet: hvuk - Dátum: 2007. ápr. 1., vasárnap - 0:45

Ehhez azért erősen hozzátartozik az, hogy az Intel a Nehalemmel követni fogja az AMD-t, azaz dedikáűlt L2 cache lesz és osztott L3 cache. Innentől nehezen védhető az, hogy a dedikált L1 + közös L2 jobb mint a dedikált L1 + L2 + közös L3 cache. Szerintem írjuk alá, hogy az AMD ebben előrébb jár. Mindenkinek az élete egyszerűbbé válik így. :D



Nem, mindenki afelé halad, hogy az utolsó cache szint osztott, az előtte lévők meg dedikáltak. Azt kell észrevenned - és ez az amit nem akarsz az istennek sem -, hogy az AMD cache-je is osztott, csak ők ezt nem az L2 szintjén, hanem az L3-nál valósítják meg. Vagy te komolyan azt hiszed, hogy nehezebb az L2 cache-t osztottá tenni mint az L3 cache-t? Mert a fenti megjegyzésed, ami szerint az Intel extra erőforrásokat feccölt bele ebbe, szerintem erre utal.

Sok a tévedés. Először is az AMD táblázata a dedikált L2-ről és az L3 meglétéről, mint kettős előnyről beszélt, ami BS, mert legfeljebb együtt hozhat ki fölényt, mint cache-hierarchia. Másrészt pedig a Barcelona L3 szimplán egy addícionális cache-szint, mivel ez volt a legolcsóbb módja annak, hogy a K8-at inkrementálisan fejlesszék, mint L2 szinten belenyúlni az egészbe. Igen, gondolom, hogy shared L2-t megalkotni még 2x2-es felépítésben is nagyobb problematika egy architekturálisan dedikáltra tervezett design esetében, mint hozzácsapni egy osztott L3-at. K8 reuse + inrekementális mikroarchitekturális fejlesztések + arbiter + L3 = Barcelona.

Ráadásul ekkor megmarad a magszintű mikroarchtektúra moduláris újrahasznosítása kétmagos designoknál is, ahol nincs L3, viszont kell a volumen és a költségek miatt a kis méret. Persze az jó kérdés, ha ez így van, akkor egy csupasz K10 2x512k, vagy 2x1M cache-sel mi a jó rossebbet fog kezdeni a Penrynekkel szemben.

Az sem igaz, hogy az utolsó cache-szint az osztott csak. A Power4 és 5 az L2 és L3 szintjén is osztott, ahogyan a Rock minden szinten osztott. A Nehalemmel kapcsolatban nem tudom, honnan az infó, én erről nem hallottam.

Téma megosztása:


  • (153 Oldal)
  • +
  • « Első
  • 114
  • 115
  • 116
  • 117
  • 118
  • Utolsó »
  • Nem indíthatsz témát.
  • A téma zárva.

1 felhasználó olvassa ezt a témát.
0 felhasználó, 1 vendég, 0 anonim felhasználó