[Laa-Yosh]

Sztem meg az, hogy a kiemelkedõen magas FP teljesítmény nem jelent elõnyt, még nem egyenlõ azzal, hogy nincs rá szükség. Elég összetett rendszerek ezek, valszleg a cache/FSB körül van egypár különbözõ kaliberû szûk keresztmetszet; de igenis kell FP kód a játékokhoz és igenis marha sok mindent még mindig a CPU csinál...

[bogdan]

Idézet: special - Dátum: 2006. márc. 8., szerda - 18:45

ezt az 1,4-es szorzót erõs túlzásnak érzem. chiprõl chipre változik az elektronikai peak, és az empirikus közti arány, de jellemzõen 15-30 százalék között mozog az általam eddig látott adatok alapján.

erdekes.. mik is voltak ezek az adatok??

[d n . r]

Idézet: Asker - Dátum: 2006. márc. 8., szerda - 19:30

Szvsz elég erõs bennem az az érzés hogy leginkább az 1 ciklusos throughput SSE miatt hasít így a Conroe. ami eddig 2 ciklusnyi volt és így effektíve megduplázódótt.

Hát nem tudom... Persze nem biztos, hogy jól gondolom (majd valaki megmondja, aki jobban otthon van mikroarchitekturális szinten), de elvileg az SSE-t (már csak a nevébõl következõen is) a streaming jelelgû adatfeldolgozásra találták ki, azaz amikor egymás után kell X adatot (ahol X az egy jóóó nagy szám ) áthajtani a pipeline-on. Márpedig ilyenkor akárhánylépcsõs a pipeline, ha egyszer feltöltõdött, akkor órajelenként kiköp egy eredményt. Viszont ha X egy jóóó nagy szám, akkor olyan mindegy, hogy a teljes mennyiséget X vagy pedig X+1 clock alatt dolgozta fel...

(vagy ez azt jelentette, hogy régebben _kétszer_ kellett végigmenni az adatnak az SSE pipeline-on? (mert mondjuk az nem volt elég széles, vagy valami egyéb okból) Mert akkor jogos a duplázás)

[bogdan]

inkabb azt, hogy anno 2 ciklusonkent esett ki egy adat a pipeline vegen.

[d n . r]

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

inkabb azt, hogy anno 2 ciklusonkent esett ki egy adat a pipeline vegen.

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)

[alvaro]

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-nem, éppen hogy arról van szó, hogy ezzel tényleg minden órajelkor kiesik egy adat a pipeline végén, mert a latencyjük az eddig se meg most se 1 ciklus szerintem.

[d n . r]

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

Nem-nem, éppen hogy arról van szó, hogy ezzel tényleg minden órajelkor kiesik egy adat a pipeline végén, mert a latencyjük az eddig se meg most se 1 ciklus szerintem.

Csakhogy _streaming_nél nincs latency! Éppen ez a lényege!

[bogdan]

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

hiszen a pipeline végén _minden_ clockra kiesik egy adat

mondom kettore! ott van, abban, amit ideztel tolem!
(persze boszen kevered a pipeline ciklust es a clock-ot! fel sem merult benned, hogy a ketto nem feltetlenul azonos?)

(latency meg van, ne beszelj butasagokat! pont a pipeline hossza a latency..)

Szerkesztette: bogdan 2006. 03. 09. 10:14 -kor

[d n . r]

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

(latency meg van, ne beszelj butasagokat! pont a pipeline hossza a latency..)

?

_Folyamatos_ az adatáramlás

(azaz arról beszélek, amikor a pipeline folymatosan mûködik, és ezért fontos, hogy X elég nagy legyen)

[bogdan]

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

Szerkesztette: bogdan 2006. 03. 09. 10:19 -kor

[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.