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

• #34 TESCO-Zsömle félisten ddekany #33

  Új Válasz 2011-11-17 14:14:18 #34

  Ú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

  

  TESCO-Zsömle

  félisten

  válasz ddekany #33 üzenetére

  Elfelejted, hogy HPC-piacra szánják. Itt a szerver nem más, mint egy sor 2 méter magas szekrény, megtömve 4-16-processzoros fiókokkal (RACK).

  Sub-Dungeoneer lvl -57

• #35 Abu85 HÁZIGAZDA ddekany #33

  Új Válasz 2011-11-17 14:22:04 #35

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz ddekany #33 üzenetére

  Rátapintottál a lényegre. De az Intel nem is mondta azt, hogy jól fognak futni az eddigi programok, csupán azt mondták, hogy futni fognak, ami természetesen igaz.

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #37 P.H. senior tag ddekany #33

  Új Válasz 2011-11-17 18:42:20 #37

  Ú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

  

  P.H.

  senior tag

  válasz ddekany #33 üzenetére

  Valahol elveszlik a lényeg, ha így közelíted meg. Ezek az erősen párhuzamosíható feladatok nem fekszenek a CPU-knak, a kevésbé párhuzamosíthatóak pedig a GPU-knak. Mondok egy nagyon egyszerű példát, talán így jobban kijönnek a különbségek: van egy 1 megapixeles képed, amin a pixelek YUV színtérben vannak, ezt át kell konvertálni RGB-be (tipikus JPEG- vagy MPEG-feladat); ez a konvertálás kb. CPU SIMD 20 utasítás, kell hozzá 3 konstans és pixelenként 4 regiszter.

  Egy CPU-val mit csinálsz? Írsz egy ciklust, ami lefut minden pixelre. Ezek a lefutások függetlenek egymástól (egyik pixelnek sincs köze a másikhoz), OoO is a processzorod, csak az utasításdekódolás sebessége és a ROB mérete (azaz az egyszerre on-the-fly állapotban levő utasítások száma) limitálja azt, hogy mikor kezd neki a következő ciklusnak; egy modern mikroarch 4 utasítást dekódol órajelenként, azaz 5 órajelenként indulhat a következő ciklus. A ROB gyorsan betelik, mivel egyetlen összeadás vagy szorzás tipikusan 3-6 órajel, tehát nem tudja olyan gyorsan fogadni az egymást követő utasításokat, hogy hosszabb távon tartani tudja az 5 órajelenkénti következő ciklust.

  Egy GPU-val mit csinálsz? Átadod neki a 20 utasítást, megmondod, hogy futtassa le 1 milliószor, ezen az bemeneti adaton, erre a kimenetre, ekkora léptékkel. Van neki 32-512 shader processzora és hozzá egy jó nagy regiszertömbje, elkezdi a ciklusmagokat lefuttatni annyi példányban egyszerre, amennyire kapacitása van, majd ha kész az egésszel, akkor jelzi. Nincs decode, ROB, OoO; nem is kell, mert csak 20 utasításod van, amit le kell futtatni 1 milliószor: számítási teljesítményben ki van gyúrva, az utasításfeldolgozási rész kicsi, mert ugyanazon a 20 utasításon miért rágódnál el 1 milliószór?

  Egy Itanium-mal mit csinálsz? In-order CPU, de van egy kisebb halom regisztere, meg egy okos utasításkészlete, ami által megmondod neki, hogy most egy olyan programrész következik, ami ciklus, de a lefutások függetlenek egymástól. Megmondod továbbá azt is neki, hogy itt kezdődik a ciklusmag kódja, emitt van a vége, ennyi a lépésköz, kell hozzá 4 regiszter és 1 milliószor kell lefuttatni (mindezt pár utasítással). Végrehajtó egységből nem sok van neki, de belül megoldja, hogy elkezd annyi ciklusmagot futtatni párhuzamosan, ahánynak az igénye csak belefér a kisebb halom regiszterébe illetve amennyinek az utasításait tudja tárolni ideiglenesen. Egy-egy szorzás vagy összeadás időigénye továbbra is néhány órajel, de mivel a végrehajtói pipeline-osak, a következő órajelben egy másik ciklus utasítását indíthatja el, így nem sérül az in-ordersége sem (mivel ez csak ciklusmagon belül szükséges, hisz megmondtad neki, hogy ez olyan ciklus, aminek lefutásai nem befolyásolják egymást). Ha kész, akkor elindul a ciklust követő következő utasítások lefuttatása, mint minden rendes CPU-nál.

  Egy MIC-en mit csinálsz? In-order (~Atom) x86 magok, kevés regiszterrel és kevésbé okos utasításkészlettel: annyi (de minél több) szálra bontod a programot, amennyi még nem befolyásolja negatívan a teljesítményt, pl. egy szál egy képsort dolgoz fel, lehet ez akár példából kiindulva 1000 vagy több sor/szál is. Az OS majd elosztja a szálakat a magok között, magonként 4-et. Ha egy szorzás vagy egy összeadás időigénye 4 órajel és a végrehajtók pipelined-ek, akkor in-order magon pont jó, mert órajelenként indíthatja a CPU más-más szál utasításait úgy, hogy egy-egy szál akkor se futna le számottevően gyorsabban, ha csak ezzel az eggyel foglalkozna az adott mag (mivel a következő utasítás nagy eséllyel függ az előző eredményétől 1 szálon belül). Ha kész egy-egy szál, akkor az OS számára jelenti, hogy végzett; amikor az összes kész, akkor az van vége a feladatnak.

  Ha így (és kissé egyszerűsítve) közelítjük meg, akkor már talán tisztább az, hogy mire jó (és talán az is, hogy mi mire lesz jó a jövőben):
  - egy általános CPU-ra nem tervezel több 100 szálat, mert csak a bonyolultságot növeli és egy x86 mag csak 2 szálat tud futtatni; egy MIC-re ez sima ügy. Mégsem GPU: elrágódik ugyan a 20 utasításon 1 milliószor (dekódolás) külön-külön, de nincs ROB, ami betelhetne, ha elég nagy a per-thread utasítássor. Nem is Itanium, mert nem kell átírni/újrafogalmazni az egészet a független lefutású ciklus miatt, csak a szálszámot kell megnövelni, ha már eddig is többszálú volt a program (ennél azért többet kell tenni, de kb. ilyen egyszerű lépésekben).
  - ha ezt vesszük példának, akkor uop-bufferrel + kb. az Itanium megoldásával, azaz utasításkészlet-bővítéssel (független ciklusok felprogramozása) tudom elképzelni azt, hogy egy jelenlegi FPU-t a jövőben lecserélnek GPU-szerű megoldásokra.

  [ Szerkesztve ]

  Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

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