71
  • mcsaba
    #31
    Miért volna baj hogy olyan hardware-t tudnak csinálni ami nem csak a jelenlegi de esetleg a később megjelenő programokhoz is jó? Én mindig is olyan gépre vágytam ami évekig megálja a helyét. Szerintem csak attól félnek hogy olyan gépeket dobnak így piacra ami akár pár évig is jó lessz és akkor nem tudnak félévente eladni olyan gépeket amik csak kicsit jobbakk az előzőnél de a programok rendes müködéséhez mégis arra van szükség. Egyszóval szerintem csak attól félnek hogy így nem kaszának eleget.
  • Balumann
    #30
    "A teljes újratervezésnek meg nem állnak neki, bár tisztelet a kivételnek (lásd DX9 -> DX10 váltás)."
    A DX9 -> DX10 -es váltást az előtte lévő mondatod melyik részének írtad példának, mert sajnos nemhiszem, hogy kivételhez tartozna (én legalábbis nem tudok róla, hogy bármelyik játékban lenne igazából DX10)
  • dez
    #29
    Szerverekkel kapcsolatban az a probléma, hogy pl. a 64 magot még hatékonyan használják ezek a programok, de pl. 512 magot már csak nagyon kevés program tud kihasználni.
  • dez
    #28
    Nem olyan nagyon nehéz kihasználni, technikailag. Elsősorban egyéb okai vannak a szegényes kihasználásnak:
    1. A játékok mai szerkezete alapvetően nem sokszálas, már ami a procit illeti.
    2. A grafika már ma is sokszálas, lásd a GPU-k sok-sok ALU-ját, és a pixelenként(!) 1-1 szálat jelentő shadereket! Később majd több olyan shader-kód, ami PC-n a GPU-n fut, PS3-on a Cellen futhat majd. Pl. a Geometry Shaderek, amikkel "menet közben" lehet komolyabb geometria-átszámításokat végezni. Az elkövetkező években fog jobban bejönni ez a technika.
    3. Már rég portolták a Physix-ot a Cellre, és szép teljesítménnyel viszi, csak éppen a játékok többsége nem használja, egyátalán komolyabb fizika sincs a legtöbb mai játékban. (Itt nem néhány autó leegyszerűsítetten is elég élethű fizikájáról van szó, hanem ha az egész játékteret "áthatja" a sokelemes fizika.)
    (4.-ként említhető az is, hogy a céget többsége minnél olcsóbban akarja letudni a kóder-kérdést...)

    Elmondanám még a Cellről, hogy az nem egyszerűen csak egy 9 magos proci (1db 2-szálas PowerPC-féleség + 8db matematikai kóproci [utóbbiból 1db le van tiltva a PS3-ban, így összesen 8 mag aktív]). Tehát nem egyszerűen megtöbbszörözték a kis matematikai számítási teljesítményű CPU magok számát, mint ami most x86 fronton folyik! Ennek eredménye sokkal jobb mat. szám. telj./fogyasztás.

    Megemlíteném még az IBM Octopiler nevű compilerét, ami szintén automatizáltan SIMD-esít és többszálúsít, csak kimondottan Cellre készült.
  • Divergencia
    #27
    megelőztél..
  • PLaci #26
    valszeg nem hallottak még a GTA4-ről XD
  • Divergencia
    #25
    Aki nem tudja kihasználni a több magot, az ne használjon ilyen gépeket. Valószínűleg sokhelyen túlméretezik a vállalati szervereket, és ebből vonták le a következtetéseiket. Azzal nem számolnak, hogy a virtualizáció mégjobban el fog terjedni.
    Amúgyis "64 KB memória mindenre elég".
  • Zoleeca
    #24
    Emberek, itt nem a ti kis desktop gépeitek vannak előtérben amiker Crysist futtattok hanem a szerverek. Egy szerver viszont nem egyelő egy alkalmazással. Le merem fogadni, hogy egy ESX támogat nemhogy 4 magot de jóval többet is (32), és a virtuális szerverek tuti ki tudják használni ezeket a magokat. Tehát az hogy "alig van valami" nem teljesen igaz.
  • dez
    #23
    Név szerint én sem ismerem őket, de vannak olyan programnyelvek, pl. tudományos számításokra, amik a párhuzamosítást automatizáltan végzik. Ezeket nem kóderek, hanem matematikusok és fizikusok használják.

    Ilyenek elsősorban Unix rendszerekre készültek (mini- és nagyszámítógépes felhasználás, de persze adott esetben kisebb munkaállomáson is elfutnak), így Linuxon is működnek.
  • sirpalee
    #22
    Persze ez nyilvánvaló. De logikus hogy olyan területen akarnak párhuzamosítani, ahol feladat szerkezete engedi is. Ahol meg nem, ott nyilván nem tudnak (vagy nem eléggé) párhuzamosítani.
  • A1274815
    #21
    Azok a dolgok, ahol n-szer ugyan azt kell végrehajtani, jól párhuzamosíthatók. A probléma a sekvenciális dolgokban van, főleg ha minden egyes lépés függ az előző(ek)től.
  • sirpalee
    #20
    Azért nem egy példa van olyan programokra amik nagyon jól skálázódnak több magon (tipikusan raytracer cuccok), és van egy halom lib is ami több ezer szálat képes párhuzamosan kezelni. Csak egy megfelelő feladatstruktúrát kellene kialakítani ami jól párhuzamosítható. Nem az a baj hogy nem tudnák megcsinálni, hanem valószínűleg egy szoftver 67-ik verziójánál tartanak, és sok olyan rész van amit a régi verziókból emeltek át, és azt foltozgatják. A teljes újratervezésnek meg nem állnak neki, bár tisztelet a kivételnek (lásd DX9 -> DX10 váltás).
  • atomkrumpli
    #19
    az a problémájuk hogy azok az op. rendszerek is változó eredménnyel végzik el ugyanazt a feladatot (akár 15%)
  • zola2000
    #18
    Na igen, ez kb olyan szintű probléma, hogy pl a ps3ban is van 9 mag, ami elég lenne három krízis futtatásához, de ezt kihasználni, ténylegesen még senki sem képes. Persze ez a generáció végére változhat.
  • IMYke2.0.0.0
    #17
    Erre én is kíváncsi lennék.
    Mert mindenhol csak a Linux-flame megy, konkrétumok nélkül.
  • Molnibalage
    #16
    Miért is? Alig támogat valami két magot is rendesen nemhogy négyet..
  • A1274815
    #15
    "Merthogy elég régóta vannak olyan oprendszerek + programnyelvek amik lehetőséget adnak a többmagosra irt kódok hatékony fejlesztéséhez."

    Itt konkrétan mire gondolsz? Mert a Linux + C/C++ sem alkalmasabb rá, illetve bármely Unix klon + C/C++-ra ez igaz. Tényleg kíváncsi vagyok.
  • A1274815
    #14
    OS osztja szét magokra a feladatot, az csak akkor gyorsít, ha több szálas a feladat vagy több nagy CPU igényű feladatot futtatsz. Hiába váltogat a magok között az OS (megjegyzem, ezt utoljára az XP csinálta, hogy automatikusan váltogat a magok között, Vista inkább a nagyobb sebesség érdekében nem vált magot, ha lehet, az adott feladat alatt).
  • Troppauer
    #13
    Hahó, tisztelt Gartner, nem csak a winfos létezik! Mert az valóban nem való ilyesmire.....
    Merthogy elég régóta vannak olyan oprendszerek + programnyelvek amik lehetőséget adnak a többmagosra irt kódok hatékony fejlesztéséhez.
  • saba30
    #12
    Szerintem is annak kéne, pedig mennyire nem tudja, lásd játékok többsége.
    Egyébként a proci egy magon belül próbálkozik pipekre bontani a szálakat, több kevesebb sikerrel. Az AMD-nél volt is egy terv (1 éve), hogy egy hid segítségével a több mag egynek látszódjon, és ne csak látszodjon hanem egy magként is működjön. Nem tudom, hogy hol tart ez a dolog, de lehet hagyták a fenébe, mert a marketing most a magok számának növelésében látja az üzleti sikert.

  • Sir Ny
    #11
    ez a második mondatodban volt...
  • YaniMan
    #10
    ...bocs, már az első mondatban hiba: az _OS_ osztja a magokat a folyamatok között
  • YaniMan
    #9
    Asztali témában ez egyáltalán nem érdekes. Itt úgyis a proci osztja a magokat a folyamatok között, az alkalmazásnak erről semmit sem kell tudnia.
    Szerver oldalon picit tényleg más a helyzet, mert itt nem fut annyi szál egyszerre. Itt tényleg az alkalmazásnak kellene tudni kihasználni a sok magot.
    Nekem viszont nincs szerverem, és egy önző nemtörődöm állat (hihi) vagyok, szóval kitérdeke'?
  • WoodrowWilson
    #8
    Még mindig jobb, ha valamerre fejlődik a hardver, minthogy toporogna, hogy bevárja a szoftvert.
  • dez
    #7
    Na jó, vannak programok, amik kihasználják a több/sok magot, de 1. desktop alkalmazások közül kevés program használja ki akár csak ezt a néhány magot, legtöbb a 2-t sem; 2. szerver alkalmazások közül is kevés használja ki a többszáz magot, vagy akár csak a több tucatot. Adott esetben nem is lehetséges annyifelé bontani a feladatot, és/vagy az ezzel járó pluszadminitrszáció több erőforrást használ, mint maga a feladatvégrehajtás. (Ezért pl. a szuperszámítógépek sem jók mindenre.)
  • dez
    #6
    Miért, szerinted az?
  • Nonix
    #5
    "A Gartner kutatócég úgy véli, hogy a sokmagos felépítésű processzorok esetében túlságosan gyors ütemben duplázódik meg a magok száma, amelyet a szoftveres fejlesztések egyelőre nem tudnak követni."

    Ez valami vicc ?
  • dez
    #4
    A programok többségének jó lenne...

    Mindenesetre jobb lenne jövőre egy 6-7 GHz-es 4-magos, mint egy olyan 8-magos, ami ugyanúgy ~3 GHz-en jár, mint a mostaniak...
  • B0nFire
    #3
    Nekem is sok az az 53 m2 amiben lakok, mert nem szaladgálok álló nap föl-alá a lakásban. Mindazonáltal nem szívesen korlátoznám le az életteremet mondjuk 16 m2-re. Jó az, ha a hardver fejlődik. A szoftver most éppen nem követi a fejlődését, de eljön az idő (nem is olyan sokára), amikor már a hardvert nem lehet tovább bonyolítani/miniatürizálni. Majd szép lassan a szoftver is felzárkózik. Ha lesz rá igény miért ne?
  • hodobaj
    #2
    Persze használjunk egy magot 6-7GHZ-n sokkal jobb lenne.
  • Molnibalage
    #1
    Lassan több mag lesz, mint ahány fogam van...