Új hozzászólás Aktív témák

• #94 Rive veterán lenox #93

  Új Válasz 2006-07-27 12:32:59 #94

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Rive

  veterán

  válasz lenox #93 üzenetére

  Ha a konkrét mérésekben, hardverben lenne egy kis tapasztalatod, akkor kiegyenesedne, hogy miről is van szó. De így itt csak annyi jön le, hogy én lemértem azt, amiről kérdeztem, te meg állítólag programozol ezt-azt.
  
  Szóval sajna egyáltalán nem gyerekes a 'felejts el'.

• #92 Rive veterán lenox #91

  Új Válasz 2006-07-27 09:43:50 #92

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Rive

  veterán

  válasz lenox #91 üzenetére

  Figyi, szívózás helyett vakard fel valamelyik performance monitort, és mérj. Még a legkeményebb, kézzel buherált, streamingra kihegyezett programok között is durva dolgokat fogsz tapasztalni a sávszélesség és a latency dolgaiban.
  
  A második bekezdésed meg egy vicc. Adott két dolog. Az egyik a különféle szinteken levő memóriák késleltetése, L1-től a DRAM-ig. Prímán mérhető mind a megfelelő módon, nem részletezem, a jelek szerint fölösleges. Jelzem, itt még a HW prefetch is nagyon jól tetten érhető, ha az ember tudja, hogy mit és hogyan kell mérnie.
  A másik meg a felgerjesztett PC (performance counter) által a futásidő alatt összeszámolt stall cycle. Ez is egzakt mérés.
  
  
  Felejts el.

• #85 Rive veterán lenox #71

  Új Válasz 2006-07-24 12:07:57 #85

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Rive

  veterán

  válasz lenox #71 üzenetére

  te az egy procis rendszerben gondolkozol...
  Nem kérlek, én egy programszál viselkedésében gondolkodom. Az, hogy egy program - egy tesztprogram - csak a harmadát/tizedét tudta kitömni az adott (régi) rendszer sávszélességének, intő jel lehetne. Ha minden magon teljes load menne, akkor talán korlát lenne a sávszélesség. De erre igencsak kevés esélyt látok, kivétel néhány speciális program.
  
  a latencyt azert lehet a hardver illetve a szoftver oldalarol is kezelni.
  Amit említetél, az már megvolt régóta a végzett mérésekkor is. Ezekkel együtt adódtak a késleltetés által okozott várakozásra amár említett értékek. Azóta effektíve csak a cache mérete nőtt.

• #66 Rive veterán lenox #63

  Új Válasz 2006-07-21 09:42:34 #66

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Rive

  veterán

  válasz lenox #63 üzenetére

  Eleve vitatkoznek azzal, hogy mi az atlagos progi
  Ezen marha sokan vitatkoznak is. A lényeg az, hogy a 'régi' nagyfrekis P4-ek vs. K8 versenyt nagyjából ugye egyetlen területen nyerte meg a P4: a sávszélességre jól optimalizálható médiafeldolgozás területén. Majd' mindenhol máshol az AMD nyert. Ennek meg nem a tuti magfelépítés, hanem az IMC: a 250+ helyett 40-50-60 órajeles memóriaelérés volt. Nagyjából azonos sávszélesség mellett.
  
  Amit tudok: anno a spec2k programjai alatt a programok által igényelt/lefoglalt sávszélesség nagyjából a rendelkezésre állónak harmada/tizede volt. Ugyanakkor a késleltetés okozta várakozás a teljes futásidőnek fele/hatoda.
  
  ...ha 4 core-on fut ugyanaz, akkor elnegyedelodik a savszelesseg, rogton erzekenyebb lesz a rendszer a memory bandwidthre.
  Csak néhány olyan program esetén, amelyik ténylegesen ki tudja tömni a buszt. A legtöbb erre nem képes. Gyengülés nyilván várható, egy osztott buszos rendszer nem teljesíthet olyan jól, mint egy dedikált. De nem-médiafeldolgozással foglalkozó programok esetén továbbra is a késleltetés jelent döntő tényezőt.
  
  az intel az uj bensley platformhoz miert fejlesztett uj memoriavezerlot, ami 3-szorosara emeli a memoria bandwidth-t, de noveli a latencyt?
  Ez egy igen jó kérdés, komolyabb vizsgálódás nélkül erre nem tudok válaszolni. Érdemes lenne felmérni a szokásos tesztprogramok adott rendszereken mutatott tulajdonságait, de erre se időm, se kedvem. Se pénzem, ami azt illeti. Reméltem, hogy valaki talán többet tud a dologról, ezért írtam #53-at.
  
  ezert meg nem kene azt a kovetkeztetest levonni, hogy serverekben, workstation-okben sem szamit.
  Semmi efféléről se beszéltem.

• #61 Rive veterán lenox #55

  Új Válasz 2006-07-20 20:45:37 #61

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Rive

  veterán

  válasz lenox #55 üzenetére

  Biztos, hogy egyrol beszelunk? Szal az inteles architecturaban a procik osztoznak a savszelessegen, az AMD-snel mindenkinek dedikalt memoriaja van. Logikusan az intelnel fontosabb a savszelesseg.
  Igen, biztos. Egy átlagos progi esetében a tényleges buszra kimenő tranzakciók viszonylag ritkák, (ha eszembe jut, akkor holnap tudok viszonylag pontos számot is mondani). Ugyanakkor egy-egy ilyen tranzakcióra vár a proci cirka száz+ ciklust. A terhelés a rendelkezésre álló elvi sávszélességet nem igazán tömi ki, elballag mellette még néhány proci ugyanazon a buszon. Nagyobb gond a várakozás.
  Egy AMD IMC-nél az elvi sávszélesség nagyjából ugyanannyi, de 50 órajel körül megvan a tranzakció.
  
  Holnap megnézem a vonatkozó dolgozatot.

• #53 Rive veterán lenox #52

  Új Válasz 2006-07-20 15:24:09 #53

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Rive

  veterán

  válasz lenox #52 üzenetére

  ...Inteles nagy problema a memory bandwidth...
  Hümm.
  Az utóbbi évben nem követem már direktben az eseményeket, de addig néhány speciálisan optimalizált program kivételével nem a sávszélesség, hanem a késleltetés volt a kritikus tényező.
  
  Változott valami?

Új hozzászólás Aktív témák