[d n . r]

Idézet: bogdan - Dátum: 2006. márc. 9., csütörtök - 11:18

en is. miben mond ez ellent a latency-nek? (a masik problemat sikerult legalabb megertened? )

Mármint ezt?

Idézet

mondom kettore! ott van, abban, amit ideztel tolem!

És szerinted mi történik minden második clockra, hm?

[d n . r]

Idézet: bogdan - Dátum: 2006. márc. 9., csütörtök - 11:18

en is. miben mond ez ellent a latency-nek?

Olvasd el Samott hozzászólását, mert ugye én arra válaszoltam, és akkor megérted, mire gondoltam.

[bogdan]

igazabol mindegy, mire valaszolsz, ha hiaba gondolod, hogy egy pipeline ugy epul fel, hogy 1 lepcsoje 1 clock hosszu... mert kulonben ket processzor kozott nem lenne kulonbseg, csak a MHz-ben pipeline alapu feldolgozaskor, hiszen mindig egy adat esik ki egy clock eseten.. pedig van!

es az sem nagyon izgat, hogy pontosan kinek valaszolsz a latencyvel kapcsolatban, ha egyszeruen hibasan kezeled a kifejezest. egy pipeline eseten a pipeline hossza a latency. egyszeru definicios kerdes. te meg azt irod, hogy "nincs"! nem is ertem mit ertesz latency alatt, ha ilyet mondasz..

[hvuk]

Idézet: d n . r - Dátum: 2006. márc. 9., csütörtök - 9:28

Igen, de erre írtam, hogyha X adat jön (és X jó nagy szám), akkor ennek nincs sok jelentõsége

(hiszen a pipeline végén _minden_ clockra kiesik egy adat (épp ez a lényege) hogy 1 vagy 2 clock, ami "utazással" telik, annak csak a feltöltéskor van jeletõsége)

Nem, az 1 vagy 2 clock ami utazással telik, az a latency. Itt másról van szó. Arról van szó, hogy a pipeline nem feltétlenül köp ki minden órajelnél adatot, special az SSE utasítások némelyikénél ez csak minden második órajelnél történt meg. Ez fele akkora sávszélességet/átvitelt jelent ezeknél az utasításoknál, mintha minden órajelnél megtörténne.

Ez különben igazából úgy mûködik, hogy az FP pipeline ilyen utasítások után 2 ciklust vár és a következõ utasítás csak 2 ciklus múlva képes fogadni.  Valahogy így (A - accept, B - Busy):

2 ciklusos esetben:
ABABABABABABABABABA...

1 ciklusos esetben:
AAAAAAAAAAAAAAAAAAA...

Jól látszik, hogy ha folyamatosan töltöd adatokkal, azza 100%-on járatod a pipeline-t, akkor az elsõ esetben csak fele annyi adatot tudsz feldolgozni, mint a másodikban. Ennek semmi köze nincs a késleltetéshez, az könnyen lehet 10-20 órajel nagyságrendû is.

[d n . r]

Idézet: bogdan - Dátum: 2006. márc. 9., csütörtök - 11:34

te meg azt irod, hogy "nincs"! nem is ertem mit ertesz latency alatt, ha ilyet mondasz..

Latom, hogy nem érted...
Értsd: nincs _jelentõsége_
Ez világosan kiderült az eddig irottakból.

[d n . r]

Idézet: hvuk - Dátum: 2006. márc. 9., csütörtök - 11:39

Ez különben igazából úgy mûködik, hogy az FP pipeline ilyen utasítások után 2 ciklust vár és a következõ utasítás csak 2 ciklus múlva képes fogadni.  Valahogy így (A - accept, B - Busy):

2 ciklusos esetben:
ABABABABABABABABABA...

1 ciklusos esetben:
AAAAAAAAAAAAAAAAAAA...

Jól látszik, hogy ha folyamatosan töltöd adatokkal, azza 100%-on járatod a pipeline-t, akkor az elsõ esetben csak fele annyi adatot tudsz feldolgozni, mint a másodikban. Ennek semmi köze nincs a késleltetéshez, az könnyen lehet 10-20 órajel nagyságrendû is.

Rendben, de miért kell várnia?

[bogdan]

hat ha neked a "nincs" es a "nincs jelentosege" kifejezes ugyanazt jelenti.. haat. Te tudod.
varnia meg azert kell, mert nincs kesz meg az eredmeny, nem?
egyebkent nagyon egyszeru, feljebb le is irtam: a pipeline lepcso nem azonos egy clock-al. (sot, van amikor meg csak nem is tudjak pontosan korulhatarolni, hogy mi egy lepcso.) ergo egy lepcso nem feltetlenul 1 clock alatt hajtodik vegre. az persze a pipeline definicioja, hogy 1 lepcso alatt 1 eredmenyt ad, de ha a lepcso nem egy clock.. innentol radbizom!

[hvuk]

Idézet: d n . r - Dátum: 2006. márc. 9., csütörtök - 10:50

Rendben, de miért kell várnia?

Mert ezt jelenti a "throughput" kifejezés. Ezt magyarázzák neked a többiek már egy ideje. Nem igaz, hogy a pipeline minden órajelben képes adatokat fogadni. Gyakran várni kell, amíg a pipeline képes új adatot befogadni. Ez a várakozási idõ lett most 1 az összes SSE utasítás esetén. Tehát mostantól minden órajelnél képes fogadni a pipeline új adatot.

Valahol olvastam régebben egy szép táblázatot az egyes processzorok throughput-járól és latencyjérõl. Be is raktam még anno ide az ars technica-ba. Megpróbálom elõkeresni.

[hvuk]

Na, megvan a táblázat, bár vagy õ vagy én összekeverem a fogalmakat vagy legalábbis más értelemben használjuk. A lényeg, hogy a latencyt ha jól értem, akkor õ olyan értelemben használja, hogy mennyit kell várni két utasítás között. Azaz pont az, amirõl mi beszélgetünk. De nem biztos, hogy igazam van persze.

link

Upd: Úgy néz ki, hogy nem direktbe összevethetõek az adatok. Attól még érdemes nézegetni.

Szerkesztette: hvuk 2006. 03. 09. 11:10 -kor

[bogdan]

szerintem meg nem ugy, mert akkor a ketto egymas reciproka lenne. es bar nagyon sok esetben ez igy is van, joparszor megsem. egy 6-os latency egy 1-es thoroughput-al osszevetve nehezen lenne igy ertelmezheto!

ugyhogy en tovabbra is tartom magam ahhoz, hogy a latency azt jelentene, hogy mennyi ido mulva kapom meg az eredmenyt. egy pipeline eseten ez pont a pipeline (idobeli) hossza.

[Darwin]

Anandtech folytatja a Conroe tesztelését

Pár korábban jelzett problémára is választ adnak (BIOS etc.)

Szerkesztette: Darwin 2006. 03. 09. 12:25 -kor

[Balala]

Hello,



Udv,
Balala

[Zollka]

Idézet: Darwin - Dátum: 2006. márc. 9., csütörtök - 12:23

Anandtech folytatja a Conroe tesztelését

Pár korábban jelzett problémára is választ adnak (BIOS etc.)

A korrekció után átlagosan a legjobb indulattal is csak 20%-kal jobb játékokban a Conroe...Namost ha belevesszük ebbe az ATI chipset gyengeségét AMD procik alatt akkor közel sem biztos ,hogy akár bármilyen játékban is megverjen egy AM2-es 3,2-3,4Ghz körüli A64-et a 3Ghz-es Conroe...A tervezett L3 cacherõl még nem is beszéltünk ami még szintén sokat dobhat...

Másrészt ha megnézitek memo késleltetés növelésével is alig változik a teljesítmény a conroe-nál, logikusan a nagyobb cache lehet hatással erre...Szal a 800-as változat sem lesz igazán durvább...

Visszatérve Special megjegyzésére...Mért is olyan bika jó a fogyasztása a Conroe-nak??? 65 watt TDP 2,8Ghz-en? Namost ezt az Intel féle TDP-ben biztos vagyok ,hogy egy 3Ghz-es 65 nanos DC A64 simán hozni fogja IMC mellett! Most akkor mért kell hanyatt esni?

A K8L egy összefoglaló megnevezés ahogy az én olvasatomban létezik a dolog...Szerintem a K8L mind mást fog jelenteni szerver, mind desktop és laptop verzióban is optimalizálva arra ,hogy mit mire is használnak jobban...

[d n . r]

Idézet: Zollka - Dátum: 2006. márc. 9., csütörtök - 15:44

(1) hogy akár bármilyen játékban is megverjen egy AM2-es 3,2-3,4Ghz körüli A64-et a 3Ghz-es Conroe...

(2) A tervezett L3 cacherõl még nem is beszéltünk ami még szintén sokat dobhat...

(1) mgint meg kell kérdeznem: miért ez az összehasonlítási alapod?

(2) szerintem _desktop_on a hammernél az L3 cache nem fog túl sokat jelenteni, mivel neki ott az IMC.

Négy magnál és sokutas rendszerekben már lehet komoly szerepe - csakhogy az egy egész más téma.

[bogdan]

nagyon kivetelesen egyet kell sajnos ertsek d n.r-el..

[Asker]

Na dejó kis vita keletkezett belõle

Az 4ik vajon azért kellett hogy meg tudják csinálni az 1ciklusos SSE enginet?
Vagy az ment volna anélkül is?

Egyébként Zollka meg 65nanóra érthette amit értett.

[special]

Idézet: d n . r - Dátum: 2006. márc. 9., csütörtök - 15:12

(1) mgint meg kell kérdeznem: miért ez az összehasonlítási alapod?

mert szerinte mire kijön ez a Conroe, addigra ilyenek szaladgálnak.

Szerkesztette: special 2006. 03. 09. 16:44 -kor

[d n . r]

Idézet: special - Dátum: 2006. márc. 9., csütörtök - 17:43

mert szerinte mire kijön ez a Conroe, addigra ilyenek szaladgálnak.

Ez világos!
Csak _miért_ gondolja?
(és miért áll meg a Conroe viszont 3 ghznél? )

[special]

Idézet: d n . r - Dátum: 2006. márc. 9., csütörtök - 17:23

Ez világos!
Csak _miért_ gondolja?
(és miért áll meg a Conroe viszont 3 ghznél? )

mert...hát mert....tudod mit dn.r, hülye intel fan vagy.

[d n . r]

Idézet: special - Dátum: 2006. márc. 9., csütörtök - 18:39

mert...hát mert....tudod mit dn.r, hülye intel fan vagy.

...ja tényleg...