Berta Sándor

Egyelőre csak hátrányt jelentenek a többmagos processzorok

Hiába fejlődnek folyamatosan a hardverek, sajnos csak kevés szoftver tudja kihasználni az ebben rejlő előnyöket. Jó példát jelent erre a többmagos CPU-k piaca.

Napjainkban egyértelműen a többmagos processzorok a meghatározóak. Gyakran hallani azonban olyan híreket, hogy kevés olyan alkalmazás van, amely képes profitálni a második, harmadik vagy negyedik mag meglétéből. Thomas Fahringer professzor, az Innsbrucki Egyetem Informatikai Intézetének vezetője pedig egyenesen azt állítja: a többmagos processzorok hátrányt jelentenek bizonyos folyamatokban. "A szoftverfejlesztés egyre inkább problémás területté válik. Ennek oka, hogy bár ma már szinte mindegyik CPU többmagos, a szoftverek jelentős része még mindig nem képes kihasználni ezt" - szögezte le a szakember.

A többmagos koncepció lényege az, hogy a chipre integrált magok megosztják egymás között a feladatok és a számítási műveletek végrehajtását, párhuzamosan dolgozva fel azokat. A gond csak az, hogy a legtöbb alkalmazás csupán egyetlen processzormag erejét tudja kihasználni. A helyzetet csak súlyosbítja, hogy a többmagos CPU-k általában alacsonyabb órajeleken működnek, mint számos korábbi egymagos társuk, így a teljesítményük sok esetben elmarad azokétól. Így fordulhat elő, hogy egy feladat lefutattása sokkal tovább tarthat egy négy- vagy egy nyolcmagos processzoron, mint a magasabb órajelű egymagos modellen. Az áttörésre, illetve a folyamat megfordulásra már évek óta várnak a fejlesztők és a felhasználók.

Fahringer elmondta, hogy az Innsbrucki Egyetem egyike azoknak az intézményeknek, amelyek megkapták tesztelési célra az Intel 48 magos Single Chip Cloud Computer (SCC) processzorának egyik prototípusát. A szakemberek szeretnének új ismeretekre szert tenni a többmagos architektúrákra és a párhuzamos, több szálas adatfeldolgozásra vonatkozóan. Az SCC esetében azonban fontos kiemelni, hogy az egyes processzormagok elméleti órajele legfeljebb 1,88 GHz. Az innsbruckiak szerint ez a gyakorlatban ugyanakkor maximum 800 MHz, vagyis ebben a tekintetben jócskán elmarad napjaink néhány CPU-jától. A helyzetet bonyolítja, hogy a kutatók egy tesztprogramnak köszönhetően megállapították, hogy az energiatakarékos üzemmód használatakor az SCC órajele csupán 320 MHz (!). Vagyis hiába van az SCC-nek 48 magja, ezek nem képesek kompenzálni a rendkívül alacsony órajelet.

Az SCC prototípusait világszerte 100 kiválasztott intézmény teszteli ősz óta. Timothy Mattson, az Intel egyik munkatársa a múlt héten pont azt emelte ki, hogy ugyan az SCC architektúra lehetővé teszi akár 1000 processzormag integrálását egyetlen chipbe, azonban egy ilyen csúcsprocesszor teljesítménye - a szinkronizációs lehetőségek felső határának elérése miatt - egyre jobban csökkenne.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • J3Surno #50


    ja

    Tipikus trágya, patt helyzet, bár számomra is igen izgalmasak ezek így elméletben, pl. a varázslatos, vagy jövőbe mutató technikák stb (nem is azzal van a baj)

    Csak nem tudom mikor jutnak el a szegény átlagfelhasználókig (lehet, hogy
    ezek nem arra vannak, de az arány akkor is siralmas) amikor így is néha 2-8 éves lemaradás van csak a pc világában sok vkinél, nemhogy ezek a szinte már katonai cuccok mikor érnek oda...

    Ráadásul kihasználva?
    Addig beköszönt egy újabb dinó-kor, vagy jön vmi meteorit (majdnem kipusztul az ember) vagy ilyesmi :)


  • Sir Ny #49
    Minek a 8 mag, a két magot sem használja ki semmi!
  • Komolytalan #48
    Minél távolabbi dolgokról beszélünk, annál helytállóbb. 2 mag tök jól el tudja csinálgatni egymás mellett az add-ot, meg a sub-ot, mul-t, meg hasonló dolgokat. Ott kezdődnek a gondok, hogy push/pop, meg mov. Főleg ha kiderül hogy azonos program szálait futtatják, és kezelni kéne közös memóriaterületet.

    Nem véletlen pl javaban - aminek a virtuális masinája verem orientált - hogy thread-hez - vagyis amit külön magok futtathatnak - van saját verem, és amíg ki nem "kacsingat" az ember a "globális" változók felé, addig van esély arra, hogy a 2 mag nem túr bele egymás memóriaterületébe.
    Egy kép/video feldolgozás meg azért másabb téma, mert ott bazi nagy memóriaterületekről beszélünk, és mondjuk 50 megában nehezebb egymásra "rálógnia" 2 mag cacheének, mint 800 byteban. Így a nagy számok törvénye alapján is "elkerülik" egymást a különböző magok cache-ei, amíg nincs "túl sok" mag.
  • Deus Ex #47
    No, ez az egész valóban jelentős csúsztatásnak tűnik. Az odáig rendben van, hogy az alkalmazásokat a valódi skálázódáshoz több magra kell optimalizálni - megjegyzem, ennek hatékonysága is feladatfüggő, nem minden folyamat többmagúsítása térül meg érdemi teljesítménynövekedésként - de a mai korszerű operációs rendszerek többfeladatúak, azaz sok, háttérben futó alkalmazást működtetnek, ha úgy tetszik, daemont vagy szervizt, ezzel párhuzamosan pedig számos interaktív vagy félinteraktív programot is. Ha az oprendszer ésszel csinálja a feladatütemezést, akkor ezeknél nettó előnyt jelent a többmagúság. Többmagos gépen külön optimalizálás nélkül is jöhet elő teljesítménynövekedés, tekintve, hogy a programnak több időszelet jut, mivel a rengeteg egyébként is futó szerviz szétoszlik a többi magon.
    A processzormaghoz rendelés XP óta elérhető lehetőség, Feladatkezelő/Folyamatok jobbklatty a folyamaton, Affinitás.
  • haveromjeno #46
    Sziasztok!
    Akkor egy nagyon alap tévedés elhárítása, amit eddig senki nem tett meg. Pedig számítottam rá, hogy valaki megjegyzi.

    "Kihasználja a képszerkesztőm, a videószerkesztőm, a játékom a több magot" című mondatok.

    Az, hogy a program több SZÁLON dolgozik. S párhuzamosan több feladatot hajt végre. (Lásd korábbi példák, hogy játékoknál egyik szálon-magon hangot, a másikon képet számol.) Az nem ugyanaz, mintha valóban kihasználna egy többmagos rendszert. Ahol is nem a feladatokat, hanem a MŰVELETEKET osztod szét magok között. Ilyen megoldások jelenleg leginkább csak a szuperszámítógépek speciális architektúráján, illetve az azokra írt speciális programokon vannak.

    Megpróbálkozom egy példával, lehet nem lesz a legjobb:

    Ha egymás mellett pörög 20x20 homokóra, akkor az 400 szálon, 400 folyamat. Ez az a "kihasználja a több magomat évek óta" című mondat. A homokórák egymástól függetlenül pörögnek, egymásra nincsenek hatással. A folyamat jól párhuzamosítható. S persze, ha van egy 8 magos HT-es inteled, akkor ez máris csak 400/8 = 50 egymás után következő művelet, magonként. Természetesen hamarabb végez, mint 1 magon 400 művelet, egymás után.

    Ha egymással összekapcsolva, töltögetik egymásba a homokórák a homokot. Akkor az 400 egymással kommunikáló mag. (A jelenlegi többmagos rendszereken ez úgy néz ki, hogy van egy központi vezérlés - általában a memória egy bizonyos része - amin keresztül öntögetik egymásba a homokot. Erre mondták azt bizonyos hozzászólok, hogy 1000-szer (Jelen példában 400x gyorsabb) memória kéne, hogy ne egymásra várjanak. Persze a valóságban az overhead miatt, még így sem lenne tökéletes, de ez más téma.
    A valódi többmagos működés, hogy közvetlen egymással beszélgetnek a magok, és nincs egy központi tár, ami lassítaná az egészet. Mindenki a saját memória darabkájával dolgozik. S annak tartalmát, csak követlen szomszédai befolyásolják.
    Utóbbi esetben ténylegesen 400x300Mhz -> kb 120 000 MHz (120GHz) dolgozna. NINCS EGYENLŐSÉG JEL! Nem is lehet. Mert a feladat maga párhuzamos, s nem lehetne ilyen módon, egy darab 120 GHz-es processzoron lefuttatni.

    A professzor által említett 300MHz es példában, a videó/kép szerkesztő, ténylegesen csak 300MHz-en dolgozna.
    Míg egy tényleges többmagos videó/képszerkesztő, pedig messze kenterbe verne, bármilyen tuningolt 4-5 GHz-es csodát.

    Köszönöm a figyelmet. Elnézést a hosszú bejegyzésért.
  • narumon #45
    Nézd meg az előző hozzászólásomat.
  • narumon #44
    Tmpgenc Xpresst használok tömörítésre ez gond nélkül használja mind a négy magot 86-96% kihasználtsággal. Ha nem csinálsz semmit mellette akkor ezt igy végig is nyomja, ha igen akkor valamelyik magot lentebb húzza.
  • MrImy #43
    És ha az egyik mag a logika/vezérlés, a másik mag pedig a renderelés, akkor helytálló a leírásom?
  • Komolytalan #42
    Már WindowsNT is kihasználta a több mag adta lehetőségeket, szóval ennek köze nincs a 32/64/akárhány bites memória címzéshez.
  • sanyicks #41
    szerintem ezt rajtad kívül senki sem tudja, mert kb olyan mintha azt mondanám:

    én szuahéli vagyok ezért a fű zöld