[special]

Idézet: Fiery - Dátum: 2004. szept. 4., szombat - 13:23

SZVSZ a 4 magos Opteronokban mar 4 csatornas DDR2 memoria vezerlo lesz, vagy vmi hasonlo.


Fiery

Ez teljesen ésszerû és talán a legvalószínûbb lépés, mivel validálni is valszeg a legkönnyebb.

[Haderach]

Idézet: special - Dátum: 2004. szept. 4., szombat - 12:58

Ezzel a technikával nem triviális feladat megoldani a sokprocesszoros kommunikációt. Eddig tudtommal egy orosz noname cég jelentette be 8-utas Opteron gépét, a Suné fejlesztés alatt van, a többiekrõl meg nem is nagyon tudni. Tekintve a dolog komplexitását, igencsak meg kell fontolni az AMD-nek vagy más cégeknek, hogy öljenek-e bele pénzeket a 16+ lapkát is fogadni tudó architektúrákba. A kétmagos lapkák esetében azért érdemes megjegyezni, hogy felezed az egy magra jutó sávszélességet és valószínûleg a buszkonkurencia miatt a késleltetés is növekszik, magyarán a hatékonyság csökken. Nyilván ezt bõven ellensúlyozza a rendkívül olcsón megduplázóott erõforrások, de a négymagos felépítés szerinetm azért már komolyabb kérdéseket vet fel -- persze ilyenkor felvetõdik, hogy a Tukwilla, amely valószínûleg 8 magot fog tartalmazni, ezt hogy oldja meg. 

na igen, lehet, hogy nem fognak 8 slot fölé menni, de dual opteronokkal már az is 16, ami bõven több, mint amire egy-két éven belül komoly szükség lehet.
amúgy meg rosszabb esetben is valahová az athlon64ek szintjére esik vissza a teljesítmény, ami szerintem még mindíg elegendõ a xeonok ellen. nem is beszélve a többutas rendszerek terén tapasztalható "alap" opteron fölényrõl.

[hvuk]

Idézet: Fiery - Dátum: 2004. szept. 4., szombat - 13:23

SZVSZ a 4 magos Opteronokban mar 4 csatornas DDR2 memoria vezerlo lesz, vagy vmi hasonlo.


Fiery

A DDR2-ben biztos vagyok (hacsak nem DDR-3 lesz, bár nem valószínû). A 4-csatornás vezérlõ azért felvet némi problémát, mert ugye ehhez már 4 memóriafoglalatot kellene kitölteni. Persze az is lehet, hogy lesz egy új foglalat szabvány, ami 128 bites lesz.

Vajon a 4 magos processzorban milyen magok lesznek? K9 vagy K8? Én az elõbbire tippelnék.

[Haderach]

Idézet: hvuk - Dátum: 2004. szept. 4., szombat - 14:34

A DDR2-ben biztos vagyok (hacsak nem DDR-3 lesz, bár nem valószínû). A 4-csatornás vezérlõ azért felvet némi problémát, mert ugye ehhez már 4 memóriafoglalatot kellene kitölteni. Persze az is lehet, hogy lesz egy új foglalat szabvány, ami 128 bites lesz.

Vajon a 4 magos processzorban milyen magok lesznek? K9 vagy K8? Én az elõbbire tippelnék.

ahol 4 magot szeretnének egy socketba tenni már szerintem nem olyan nagy gond a sok memóriamodul.

[hvuk]

Idézet: Haderach - Dátum: 2004. szept. 4., szombat - 13:57

na igen, lehet, hogy nem fognak 8 slot fölé menni, de dual opteronokkal már az is 16, ami bõven több, mint amire egy-két éven belül komoly szükség lehet.
amúgy meg rosszabb esetben is valahová az athlon64ek szintjére esik vissza a teljesítmény, ami szerintem még mindíg elegendõ a xeonok ellen. nem is beszélve a többutas rendszerek terén tapasztalható "alap" opteron fölényrõl.

Miért ne mennének 8 processzor fölé? Épp a napokban jelentette be valamelyik cég, hogy 4 processzoros node-okkal max. 32 processzoros rendszert fog építeni a jövõ év végére.

Az AMD szerint a két processzor egy magon esetben a teljesítményvesztés a 2 külön processzoros rendszerhez képest kb. 10%-os. Egy ilyen processzor ára lesz inkább a kérdéses. Szerintem különben a dual magos desktop processzor megjelenése után az ilyen processzorokat FX-ként fogják forgalmazni, a normál verziók meg szimpla A64-ek lesznek, de vélhetõleg 1 mega cache-el lesznek szerelve.

[hvuk]

Idézet: Haderach - Dátum: 2004. szept. 4., szombat - 14:36

ahol 4 magot szeretnének egy socketba tenni már szerintem nem olyan nagy gond a sok memóriamodul.

Ha lehozzák a desktopra is (márpedig elõbb-utóbb lehozzák), akkor már igen. Szerverek esetén nyilván nem az.

A 128 bites memória modulok megjelenése kb. 2006-2007 magasságában szerintem teljesen logikus lenne.

Szerkesztette: hvuk 2004. 09. 04. 13:42 -kor

[Haderach]

Idézet: hvuk - Dátum: 2004. szept. 4., szombat - 14:38

Miért ne mennének 8 processzor fölé? Épp a napokban jelentette be valamelyik cég, hogy 4 processzoros node-okkal max. 32 processzoros rendszert fog építeni a jövõ év végére.

4CPU/node -> cluster.
itt a node-onkénti foglalatokról beszélünk.
szerk: vagy ha úgy érted a node-ot, hogy az a node, ami egy foglalatba megy(szerintem nem így kell) akkor is 32/4=8, azaz még mindíg csak 8 foglalat, csak 4magos opteronokkal

és szerintem arra még várhatsz, míg a dell meg HP meg IBM desktop kíálatában 2000 USD alatt megjelenik egy kétutas rendszer(vagy egy utas, két magos ) .

Szerkesztette: Haderach 2004. 09. 04. 14:27 -kor

[hvuk]

A Newisys által tervezett rendszer tudtommal nem cluster lenne. A 4-node csak annyit jelentene, hogy egy alaplapon 4 processzor lesz és a 4 processzoros alaplapok között HT kapcsolat lenne. Itt is végig MP géprõl beszélnek, a cluster szó nem is szerepel a cikkben.

[SFIJ]

Idézet: Vajonész - Dátum: 2004. szept. 3., péntek - 9:11

Azt a 10 évet RISC/CISC, de nem a EPIC-re mondta Elric.
Erre a jelenlegi tudás szerint mégtöbb.
Pont ezért feszegetem azt, hogy egyáltalán lesz-e rá kiforott compiler, 2012-2015 környékén már egész más processzorok lesznek. Nem hiszem, hogy akkor jelenlegi Itanium1/Itanium2-esek üzembe lesznek, akik használnák a "kiforott compilert".

En erre mondom azt, hogy aze' mert rossz a koncepico. van 2-3 okos gyerek aki probalja kitalalni milyen is lenne az okos compiler. ehelyett olyan compiler kene hozza, ami mogott egy helyes kis AB all, juzer profile-ol reszelgeti a kodot, compiler meg szepen on the job megtanulja, hogy mit, hogyan celszeru leforditania. KB 1.5-2 ev alatt egy ilyen compiler nagyon sokat tudna 'okosodni' es kielegito eredmenyt is nyujtana.

[special]

És azt honnan tetszik tudni SFIJ bácsi, hogy ilyen evolucionista megközelítéssel nem próbálkoznak?

[SFIJ]

Idézet: hvuk - Dátum: 2004. szept. 3., péntek - 10:18

Igen, szép lassan az együttgondolkodás hatására rájövünk a tényleges indok(ok)ra. Viszont továbbra is fenntartom, hogy az IMC-re nagy szüksége lenne az Intelnek, viszont annak kifejlesztése hatalmas feladat. Ha tudná megtenné, de nem tudja

kedves hvuk. Rive szepen leirta, hogy hosszucsovu gepben semmit sem ersz el gyakorlatice az IMC-vel, csupancsak azt, hogy zabalja a szilikont. A netburst architektura nem RAM-ot hanem SAM-ot feltetelez, ez vanik

[SFIJ]

Idézet: hvuk - Dátum: 2004. szept. 3., péntek - 14:27

Elég nagyképû duma.

Lehet, hogy tanulnék, ha magyaráznál. De nem magyarázol. Ne menj el tanárnak, mert útálnának a diákok.

A következõt kellene megmagyaráznod:
- Mitõl nõtt meg a sávszélesség, ha nem attól, hogy lecsökkent a memóriahozzáférés latencyje? Mert ugye a rendszerekben más nem változott.
- Ha a latencytõl nõtt a sávszélesség, akkor ugyanez a növekedés miért nem lesz meg az IMC esetén?
- Hozhatnál egyetlen árva tesztet, ahol megmutatják, hogy a latency csökkenése nem növeli a teljesítményt vagy nem az elvárt mértékben, azaz egy IMC esetén kb. felére esõ latency-nél nem éri el a 10%-ot.

Addig a dumád csak nagyképû üres szócséplés.

Kedves hvuk ecceru a keplet.
a) vedd annak a latency kulonbseget hogy IMC vagy kulso MC van
b) nezd ki a CPU csovenek latency-jet a katalogusbol.

ha az 'a' sokkal kisebb a 'b'-nel akkor nem erdemes az IMC-vel pocsolni. Mint sokan irtak a svavszelesseg az meg egy tok mas dolog.

Szemleletese teszem szamodra a savszel vs latency dolgot:
1.) Szekesfehervearon lax es egy budapesti szerverrol toltogecc 56kbps-sel.
2) Van egy haverod aki megpakol egy euro raklapot irt DVD-vel es szepen bezsuppolja egy ford transitba es megindul feled Fehervarra.

1) latency (ping) kb 10-70 ms.
2) latency 1 ora.

1) savszelesseg: 56kbps
2) savszelesseg 409 Gbit/s (10000 disk/raklap)

(erre szokta volt mondogatni szegeny megboldogult Pongor tanar ur, hogy sose becsulujuk le egy jol megpakolt IFA-t mint adatatviteli kozeget )

[special]

Ezek alapján tehát pl. a UT botmatch alatt (erõteljes AI) a téves elágazások nyírják ki inkább a NetBurstöt, nem pedig a memória késleltetése?

[SFIJ]

Idézet: Haderach - Dátum: 2004. szept. 3., péntek - 20:29

az opteronnak nem felsõ korlátja a 8, csak a mem.koherens HT rétegnek.

Ez sem pontos igy, mondjunk inkabb glueless mem koherens HT retegnek. 4-es szendvicsekbol megfelelo segedlogikaval szep kis fraktalszeru cumokent bovitgetheted, ahogy jol esik. Persze a glue bridge-ket osszekotogetni mar nem HT-vel, hanem valami uberbrutal backbone busszal erdemes. Ha jol emlex pont ezt heggeszti a cray valami ami kormanyzati megrendelesre. bar ebben mar a 'packetized' HT lesz.

Szerkesztette: SFIJ 2004. 09. 06. 19:06 -kor

[SFIJ]

Idézet: Haderach - Dátum: 2004. szept. 4., szombat - 14:36

ahol 4 magot szeretnének egy socketba tenni már szerintem nem olyan nagy gond a sok memóriamodul.

bekabelezni gond csupan.

[SFIJ]

Idézet: special - Dátum: 2004. szept. 6., hétfõ - 16:23

És azt honnan tetszik tudni SFIJ bácsi, hogy ilyen evolucionista megközelítéssel nem próbálkoznak?

nos vanik PPC (IBM), compilerem. Vanik SUN Workshop compilerem. Vanik Itanic compilerem. A GCC forrasa kozkincs. egyiksem csinazza ezt, mindegyiknek 'eloregyartott' esze vanik. Egyebkent valszeg azert nem, mert egy modern C/C++ compiler mar igy is kibirhatatlanul lassan dolgozik egy java/C# compilerhez kepest, es egy ilyen tanulgatos cucc kbi 1 nagysagrendet rontana meg a mukodesi sebessegen.

[special]

Nem úgy gondoltam, hogy mindegyik fordítás evolúcióval folyna (bár az se rossz), hanem a compiler esze, esetleg a beépített profile-ok így lennének elõállítva. Mondjuk ehhez is elképesztõ számítási teljesítmény kellene, de pl. az Itanium esetében az enterprise és HPTC appok száma még mindig relatíve kicsi, így a chiptervezéshez használatos, néhány száz vagy ezer cpu klaszterekhez hasonlóan erre is lehetne erõforrást dedikálni.

[Balala]

Hi,

Ez a'sszem itt még nem volt:

Montecito infók:

- 100 W power envelope
- dual CPU, each 2-way multithreading (4 thread/chip)
- dcache: 16 KB L1 + 256 KB L2
- icache: 18 KB L1 + 1 MB L2
- L3: 12 MB/CPU, 24 MB total/chip

Üdv,
Balala


[ Kattints ide a teljes méretû képhez ]

[hvuk]

Idézet: SFIJ - Dátum: 2004. szept. 6., hétfõ - 17:56

kedves hvuk. Rive szepen leirta, hogy hosszucsovu gepben semmit sem ersz el gyakorlatice az IMC-vel, csupancsak azt, hogy zabalja a szilikont. A netburst architektura nem RAM-ot hanem SAM-ot feltetelez, ez vanik

Leírta, de nem magyarázta meg. És még csak elméleti fejtegetést sem mellékelt hozzá, mint te. Elsõ blikkre meg nem hiszem el. Amúgy az általad leírt magyarázat hihetõnek tûnik, de azért odaírhattad volna a pipe késleltetését. Az IMC nyeresége durván 100 ciklus (3.2-es processzor esetén), kötve hiszem, hogy a pipe késleltetése közel ennyi lenne. A Prescott esetén azért elképzelhetõ persze, az általam hozott tesztek mind a Northwood-on alapulnak. Nos, mennyi is a P4-ek pipe-jának késleltetése? És mennyi az Athlon 64-é (szvsz ez is érdekes!)?

És ha az elméleti háttér szerint igazad is van, akkor is meg kellene magyarázni az alábbi megfigyeléseket:
- A 3.2 EE kb. 5-10%-al gyorsabb a legtöbb alkalmazásban, mint a 3.2C. A 2 MB-nyi L3 cache szerepe ugye elsõsorban a latency elfedésében van (és persze a cache miss csökkenésében). Miért gyorsabb ennyivel? Csak a cache miss miatt? Nem valószínû szvsz. Ja igen, egyes esetekben a gyorsulás elérte a 20%-ot!
- Továbbá amikor a memória latency-jét változtatták csak egy P4-es rendszeren (lásd általam berakott cikk), akkor 5-10%-os gyorsulást mértek. Pedig itt (ha nem számoltam el), akkor csak 16 ciklusnyival (az utolsó memória paraméternél 32-vel) csökkent az elérés ideje (ha elszámoltam, akkor 32/64). Tehát a késleltetés csökkenése lényegesen kisebb volt, mint egy IMC-vel lenne.

Rive szerint ezt a második esetet sávszélesség növekedése okozza. Ezzel két gond is van:
- Fiery hívta fel a figyelmet rá, hogy a cachemem sávszélesség mérése késleltetés-függõ. Ezt két dolog is alátámasztja: az Athlon 64 vs XP esetén is nagy sávszélesség különbséget mér (25-30%), miközben az Everest meg a Sandra csak 10%-ot, továbbá az általa mért sávszélesség lényegesen kisebb egyes esetekben, mint a fenti két programé. Tehát az általa hivatkozott memória sávszélesség növekedés a CacheMem hibás (illetve fogalmazzunk úgy, hogy a késleltetéstõl függõ) mérési módszerébõl adódott.
- Nem magyarázza meg, hogy ha - egy pillanatra feltéve, de meg nem engedve - a P4-es rendszeren a sávszélesség jelentõsen megnõtt, akkor az IMC-nek miért nincs ugyanilyen hatása. Tök mindegy ugyanis a végeredmény szempontjából, hogy az IMC-vel azért gyorsulna, mert csökkenne a latency vagy pedig azért, mert a lecsökkent késleltetés hatására megnõne a sávszélesség.

Jól látható tehát a gondom: a gyakorlat látszólag ellentmond az elméletnek. Illetve nem tudjuk, hogy ellentmond-e, mert nem tudjuk a P4 csövének a késleltetését.

Szerkesztette: hvuk 2004. 09. 07. 13:53 -kor

[hvuk]

Nem igaz, hogy a pipe csökkenése annyi órajel, mint ahány stage-bõl áll? Mert ugye elméletileg minden stage-en belül egy órajelen végez a processzor. Vagy ez nem minden stage-re igaz? Vagy most nagy baromságot mondtam?