[Asker]

THX. Nahátakkor csak belenyomtak egy kis NOS-t az SSE-be, nem is kicsit. :Ð
Ha van vmi pdfed a felépítésre akkor azt szívesen venném.
Elég nagy leap az a 3*128 a 2*64el szemben.

Szerkesztette: Asker 2006. 03. 10. 07:13 -kor

[Balala]

Idézet: Asker - Dátum: 2006. márc. 10., péntek - 6:12

Ha van vmi pdfed a felépítésre akkor azt szívesen venném.

Ha tudsz annál jobbat, mint amit tegnap beszúrtam, nekem is szólj, pls.

Innen lehet leszedni az IDF pdf-jeit. User: idf pass: spring2006. Sajna a Pawlowski eloadas pdf-je nincs itt...

Szerkesztette: Balala 2006. 03. 10. 08:49 -kor

[Asker]

Idézet: Balala - Dátum: 2006. Mar. 10., Friday - 8:41

Ha tudsz annál jobbat, mint amit tegnap beszúrtam, nekem is szólj, pls.

Innen lehet leszedni az IDF pdf-jeit. User: idf pass: spring2006. Sajna a Pawlowski eloadas pdf-je nincs itt...

áhh, pedig igazából Õ tervezte nem pedig az a Rattner, má nemazé hogy fikázzam de azért tud vmit Phd nélkül is. 
de azér THX

nah átnézva a pdfet továbbra is azt mondom hogy a dupla SSE throughput miatt nagylegény + a Smart Memory Acces miatt, ami lényegesen lecsökkenti a latencyt.

Szerkesztette: Asker 2006. 03. 10. 09:33 -kor

[Balala]

Idézet: Asker - Dátum: 2006. márc. 10., péntek - 7:57

áhh, pedig igazából Õ tervezte nem pedig az a Rattner,
de azér THX

Az itt látható screenshotok vszeg a Pawlowski elõadásból vannak.

[Balala]

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



Mint az ábrából látszik, nem a latency, hanem a throughput csökkent 1-re a(z) (e)NGMA-ban.

• Utasítás latency = az az várakozási idõ, amíg egy másik, ugyanolyan típusú, függõ utasítás végrehajtását el lehet kezdeni
  
• Utasítás throughput = az az várakozási idõ, amíg egy másik, ugyanolyan típusú, független utasítás végrehajtását el lehet kezdeni

Ez egy X2 3800+:

SSE2  :ADDSD xmm, xmm            Lat:   1.99ns=  4.0c TP:   0.50ns=  1.00c
SSE2  :ADDPD xmm, xmm            Lat:   1.99ns=  4.0c TP:   1.00ns=  2.00c
SSE2  :MULSD xmm, xmm            Lat:   1.99ns=  4.0c TP:   0.50ns=  1.00c
SSE2  :MULPD xmm, xmm            Lat:   1.99ns=  4.0c TP:   1.00ns=  2.00c
SSE2  :DIVSD xmm, xmm            Lat:   9.95ns= 20.0c TP:   8.46ns= 17.00c
SSE2  :DIVPD xmm, xmm            Lat:  16.92ns= 34.0c TP:  16.92ns= 34.00c
SSE2  :SQRTSD xmm, xmm           Lat:  13.43ns= 27.0c TP:  11.94ns= 24.00c
SSE2  :SQRTPD xmm, xmm           Lat:  23.88ns= 48.0c TP:  23.88ns= 48.00c

Ez meg egy P4 640:

SSE2  :ADDSD xmm, xmm            Lat:   1.56ns=  5.0c TP:   0.63ns=  2.00c
SSE2  :ADDPD xmm, xmm            Lat:   1.56ns=  5.0c TP:   0.63ns=  2.00c
SSE2  :MULSD xmm, xmm            Lat:   2.19ns=  7.0c TP:   0.63ns=  2.00c
SSE2  :MULPD xmm, xmm            Lat:   2.19ns=  7.0c TP:   0.63ns=  2.00c
SSE2  :DIVSD xmm, xmm            Lat:  12.50ns= 40.0c TP:  12.50ns= 40.00c
SSE2  :DIVPD xmm, xmm            Lat:  22.19ns= 71.0c TP:  22.19ns= 71.00c
SSE2  :SQRTSD xmm, xmm           Lat:  12.50ns= 40.0c TP:  12.50ns= 40.00c
SSE2  :SQRTPD xmm, xmm           Lat:  22.19ns= 71.0c TP:  22.19ns= 71.00c

Ez meg egy Yonah 1833MHz:

SSE2  : ADDSD xmm, xmm       Lat:   1.64ns=  3.0c TPut:   0.55ns=  1.00c
SSE2  : ADDPD xmm, xmm       Lat:   1.64ns=  3.0c TPut:   1.09ns=  2.00c
SSE2  : MULSD xmm, xmm       Lat:   2.73ns=  5.0c TPut:   1.09ns=  2.00c
SSE2  : MULPD xmm, xmm       Lat:   2.73ns=  5.0c TPut:   2.18ns=  4.00c
SSE2  : DIVSD xmm, xmm       Lat:  17.45ns= 32.0c TPut:  16.91ns= 31.00c
SSE2  : DIVPD xmm, xmm       Lat:  33.82ns= 62.0c TPut:  33.82ns= 62.00c
SSE2  : SQRTSD xmm, xmm      Lat:  31.63ns= 58.0c TPut:  31.09ns= 57.00c
SSE2  : SQRTPD xmm, xmm      Lat:  62.18ns=114.0c TPut:  62.18ns=114.00c

Szerkesztette: Balala 2006. 03. 10. 10:17 -kor

[Asker]

Idézet: Balala - Dátum: 2006. Mar. 10., Friday - 9:43

Mint az ábrából látszik, nem a latency, hanem a throughput csökkent 1-re a(z) (e)NGMA-ban.

Errõl beszéltünk eddig is, sõt nagy vita is kerekedett belõle. 

Szerkesztette: Asker 2006. 03. 10. 09:50 -kor

[special]

szvsz az amd az fp turbósításáról az ngma-ról megszerzett infók alapján döntött, így inkább felzákózásról beszélhetünk majd részükrõl.

most már nagyon kíváncsi leszek linpack, specfp eredményekre, sokan már nagyon dörzsölik rá a mellbimbójukat.

[bogdan]

valamit most nagyon nem ertek. eddig arrol szoltak a hirek es itt a velemenyek, hogy MINDEN SSE utasitas 1 clock TP-al fog rendelkezni. Balala tablazata viszont azt mutatja, hogy az eddigi architekturak az egyszerubb utasitasokat 1-2 clock TP-al, a bonyolultabbakat tobb tiz TP-al hajtottak vegre. most akkor az az allitas, hogy ezek is 1 clock TP alatt ki lesznek szamolva? (nemi skepcicizmus lenne bennem..) mert ha nem, akkor kerdes, hogy melyek igen! (kulonben nehez lenne osszehasonlitani az AMD eredmenyekkel, ahol ugy latszik eddig is voltak 1 clock TP sebessegek..)

[alvaro]

a 'minden' alatt nyilvan csak az alapmuveleteket ertettek, a bonyolultabbakra elvi esely s.em volt

(szerk. keymedia :Ð)

Szerkesztette: alvaro 2006. 03. 10. 10:13 -kor

[Asker]

Idézet: special - Dátum: 2006. Mar. 10., Friday - 9:53

szvsz az amd az fp turbósításáról az ngma-ról megszerzett infók alapján döntött, így inkább felzákózásról beszélhetünk majd részükrõl.

most már nagyon kíváncsi leszek linpack, specfp eredményekre, sokan már nagyon dörzsölik rá a mellbimbójukat.

wtf?
de miért mikor integerben kéne? SSE?

mondjuk a 2007 elejére tervezett instruction setsrõl azt állítja az AMD hogy integer+fp perfomance.

Szerkesztette: Asker 2006. 03. 10. 10:30 -kor

[hvuk]

David Kanter írt egy jónak tûnõ cikket az RWT-n az NGMA architektúrájáról.

link

[SFIJ]

Idézet: bogdan - Dátum: 2006. márc. 10., péntek - 10:00

valamit most nagyon nem ertek. eddig arrol szoltak a hirek es itt a velemenyek, hogy MINDEN SSE utasitas 1 clock TP-al fog rendelkezni. Balala tablazata viszont azt mutatja, hogy az eddigi architekturak az egyszerubb utasitasokat 1-2 clock TP-al, a bonyolultabbakat tobb tiz TP-al hajtottak vegre. most akkor az az allitas, hogy ezek is 1 clock TP alatt ki lesznek szamolva? (nemi skepcicizmus lenne bennem..) mert ha nem, akkor kerdes, hogy melyek igen! (kulonben nehez lenne osszehasonlitani az AMD eredmenyekkel, ahol ugy latszik eddig is voltak 1 clock TP sebessegek..)

aki azt hittet, hogy Tp=1-gyel lehet negyzet- ill. kobgyokot vonni az siman csak naiv. persze lehetne, de akkor legalabb duplazhatnad a VE meretet - vagy bevetni version kedvenc LNS aritmetikajat Az LNS odabaszna a throughputnak ellenben az egekbe tolna a latency-t :Ð

amugy balala tablicskujabol az jon le, hogy a hammer architektura a magasabbrendu muveletek eseten lemossa a palyarol az intel-t. az egyszeru add/mul esetben a Jonas felzarkozott.

Szerkesztette: SFIJ 2006. 03. 10. 15:39 -kor

[SFIJ]

Idézet: special - Dátum: 2006. márc. 10., péntek - 9:53

most már nagyon kíváncsi leszek linpack, specfp eredményekre, sokan már nagyon dörzsölik rá a mellbimbójukat.

eleve azzal kellett volna kezdeni. ezek a kvek meg doom tesztek eredendoen a GPU-t meg az I/O-t merik.

[special]

Idézet: SFIJ - Dátum: 2006. márc. 10., péntek - 15:42

eleve azzal kellett volna kezdeni. ezek a kvek meg doom tesztek eredendoen a GPU-t meg az I/O-t merik.

marketing. most képzleteben menj el az alaplap-professzorba, és közöld a társasággal, hogy linpack, blas és specfp alatt mit produkált a conroe (tfh tudnánk). a woodcrestnél elhiheted, nem ilyen tesztek lesznek.

érdekesség: elõször a woodcrest jön, aztán a conore, év végén a merom. legalábbis ezt írják az rwt-n.

[d n . r]

Idézet: special - Dátum: 2006. márc. 10., péntek - 17:17

érdekesség: elõször a woodcrest jön, aztán a conore, év végén a merom. legalábbis ezt írják az rwt-n.

HA így lenne, egyáltalán nem lepõdnék meg, sõt!
Szerver/workstation-fronton a legfájóbb a lemaradás, a fogadó platform pedig már készen _van_ (bensley)
Én korábban is írtam már, hogy a DC Xeonok szerintem a megfelelõ chipset hiánya miatt lettek ennyire elcsúsztatva. 

[d n . r]

Idézet: Balala - Dátum: 2006. márc. 10., péntek - 10:43

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




Mint az ábrából látszik, nem a latency, hanem a throughput csökkent 1-re a(z) (e)NGMA-ban.[LIST]
[*]Utasítás latency = az az várakozási idõ, amíg egy másik, ugyanolyan típusú, függõ utasítás végrehajtását el lehet kezdeni
[*]Utasítás throughput = az az várakozási idõ, amíg egy másik, ugyanolyan típusú, független utasítás végrehajtását el lehet kezdeni

Na most lehet, hogy megint hülyeséget kérezek, mert ilyen szinten én már messze nem értek a processzormikroarchitekturához, de az ábrából nekem az a kép áll össze, hogy:

- az SSE négykomponensû vektorokkal számol

- EDDIG úgy volt, hogy _egyszerre_ csak két komponest tudott feldolgozni (mert nem volt elég "széles")

-azaz úgy csinálták, hogy elõször beadták neki az elsõ két komponenst, majd közvetlen utána a másik két komponenst (és _ezért_ van, hogy addig nem tud új adatot/utasítást fogadni)

-így természetesen minden órajelre kiadott egy adatot, de valójában csak egy _fél_ adatot, azaz 2 órajelenként tudott ideális feltételek mellett végezni egy teljes vektorral

-MOST viszont egyszerre tud dolgozni mind a négy komponensen 

Jól látom, vagy még mindig valamit félreértek?

[d n . r]

Ja, és természetesen világos, hogy van olyan eset, amikor az utasítás bonyolult (illetve másképpen: több elemi utasításból épül fel), azaz az eredmény csak részeredmény, amit vissza kell megint táplálni a pipeline-ba (esetleg többször is)

[bogdan]

Idézet: d n . r - Dátum: 2006. márc. 10., péntek - 17:25

Szerver/workstation-fronton a legfájóbb a lemaradás

nopersze. de ha ez csak a DP (dual socket verzio), es az MP meg csak bejelentes szinten sincs, akkor mit er az egesz? (kozben az Opteron meg mar a 16-32 utas NUMA-t celozta be..)

[bogdan]

mi az, hogy "negy komponensu vektor"? az SSE-nek (mint nemreg kitargyaltuk) valtozo szelessegu adatot adhatsz, csak a szelesseg osszege legyen 128. (2x64, 4x32..)

[d n . r]

Idézet

nopersze. de ha ez csak a DP (dual socket verzio), es az MP meg csak bejelentes szinten sincs, akkor mit er az egesz?

Rengeteget!
Most viccelsz?

Idézet

(kozben az Opteron meg mar a 16-32 utas NUMA-t celozta be..)

Igen ezt már õsszel is mondtad...