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

• #105 Abu85 HÁZIGAZDA DRB #102

  Új Válasz 2011-01-04 18:19:53 #105

  Ú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 DRB #102 üzenetére

  Igen az APU heterogén programozása az lényegében CPU+GPU, de nincs közte lassú busz, vagyis az eddigiekhez képest az adatcserével sokkal bátrabban lehet bánni. Ez adja az egész előnyét. Ez csak az első lépés az úton. Mint írtam a hírben is, még ennél is lehet jobb kommunikációs lehetőségeket biztosítani, így még többször lehet az adatokat a magok között vándoroltatni, ami még gyorsabb feldolgozáshoz vezet.

  (#104) lenox: Arra gondolj, hogy egy feladatot átadsz a GPU-nak, akkor az időbe telik. Például a flashgyorsítás jelenleg úgy működik, hogy a CPU átadja a dekódolásra váró streamet a GPU-nak, majd a feldolgozás megtörténik, és a GPU visszaadja az eredményt a CPU-nak, majd az utómunka után mehet ki a végső eredmény. Ezért hal meg az Ion 2 a Hulu weblejátszón már 720p-ben. A PCI Express x1 egyszerűen akkora késleltetéssel jár, hogy ez az út járhatatlan. Ilyen helyzetekben előny az integráció.
  Ez láthatóan minden cég számára világos, nem véletlenül van/lesz a hátuk mögött platform. Attól nem kell félni, hogy az izmos GPU-kat kiváltják ezek a rendszerek, de az egész IT ipar erre megy, és ennyi cég nem tévedhet. Nyilván dönthetnek a még több CPU mag mellett is, de az ábrából látható, hogy elértük a korszak végét. Ugyanezt az ábrát mutatta be az NVIDIA az SC10-en, ahol magyarázták, hogy miért raknak latency optimized CPU magokat a következő generációs lapkáikba. Persze ők más szempontból közelítették meg a kérdést, hiszen nekik GPU-ik voltak, de a konklúzió dettó ugyanez volt, vagyis az egyetlen út a hibrid rendszer. Azt nem tudni, hogy a latency optimized CPU az NV-nél mit jelent, de gyaníthatóan ARM architektúrát. Az lenne a leglogikusabb, mert az ARM-ra elkészül a Windows 8, vagyis az NV onnantól kezdve nem függ az AMD és az Intel processzoraitól, mert egy cGPU-val képes futtatni a rendszert.

  [ Szerkesztve ]

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

• #106 con_di_B tag DRB #102

  Új Válasz 2011-01-04 18:26:54 #106

  Ú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

  

  con_di_B

  tag

  válasz DRB #102 üzenetére

  Ez egyszerű válasz lesz. Vagy van egy összetákolt programfelületed, amiben minden hardverre külön írsz kódot (CUDA, CTM), procikra külön írsz assemblyben kódot a kritikus részekre, vagy van egy egységes, általános felületed, amiben a különböző dolgokban jeleskedő hardvereket egyszerre érheted el (OpenCL). Ez egyszerűsít a képleten. De ehhez tényleg nem kell Fusion.

  Fusion ahhoz kell, hogy ne a gépek 1%-ában legyen elég gyors OpenCL implementáció, hanem minden újonnan vásárolt gépben legyen, akár desktop, akár notebook, akár netbook vonalon => onnantól fogva máris megérni elkezdeni (ki)használni.

  (Szerk: meg az, amit Abu írt )

  [ Szerkesztve ]

• #107 opr veterán DRB #102

  Új Válasz 2011-01-04 18:52:18 #107

  Ú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

  

  opr

  veterán

  válasz DRB #102 üzenetére

  Na, mire hazaértem melóból már látom meg is válaszolták
  röviden, amiért könnyebb programozni:
  a kisebb késleltetés miatt nem kell annyira kínosan ügyelni az optimalizációra, kisebb adatcsomagokat is megéri küldözgetni, adott kód sokkal kisebb darabokra bontható, így amellett, hogy esetenként könnyebb, akár gyorsabb eredményt is dobhat, mint egy brutl különálló vga
  amiért ugyanolyan nehéz:
  Szintén "szét kell szedni" a programokat a megfelelő módon, mint eddig.

  Szal, tömören: ugyanolyan nehéz rá kódolni, mint eddig, csak mégsem(tudod, a veréb között semmi a különbség, mert mindkét szrnya ugyanolyan, főleg a bal ), és potenciálisan gyorsabb az eredmény.

  Nagyjából ennyi. Plusz ehhez jön még, hogy a programozók is kezdenek hozzászokni a többszálban gondolkodáshoz, plusz egyre kiforrottabbak a nyelvek/fejlesztői környezetek.

  [ Szerkesztve ]

  "Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin

• #111 freeapro senior tag DRB #102

  Új Válasz 2011-01-04 19:06:40 #111

  Ú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

  

  freeapro

  senior tag

  válasz DRB #102 üzenetére

  DRB kicsit fárasztó vagy!

  Eddig volt egy jó elméleti lehetőség. Azt ígérte az OpenCL, hogy tudsz CPU-n meg GPU-n is feladatokat végrehajtatni. Írtál rá egy programot ahogy elképzelted, hogy működnie kellene. Kipróbáltad: nem ment. Akkor elkezdted az elképzelést közelíteni a valósághoz, meg optimalizálni, meg guglizni, hogy hol a hiba, mások mit találtak ami működik, mik a soha nem publikált best practice eljárások stb. Nagyon sok vesződés árán csináltál valamit ami alig lett jobb mint a sima egyszálú program. Jó esetben. Rossz esetben kiderült, hogy ezt még nem lehet megcsinálni. És itt elment a kedved az egésztől.

  A heterogén felépítés pedig végre azt nyújtja mait ígért. Fut a cucc az APU-n amihez ha CPU kell akkor ahhoz nyúl, ha GPU akkor ahhoz, kicsit még mindíg rosszabb mint vártad, de lényegesen jobb mint az egyszálú program. És ekkor megszereted.

• #116 P.H. senior tag DRB #102

  Új Válasz 2011-01-04 20:36:17 #116

  Ú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 DRB #102 üzenetére

  APU-n azért könnyebb programozni, mert az ember jópár dolgot, ami diszktét GPU-n lassabban megvalósítható volt, már előzetes számítások (adatcsere időigénye pl. - alapján) is eleve elvetett, megoldható.
  Igaz, nem könnyebb programozni, de kifizetődőbb. Az FPU-t sem volt anno könnyebb, aztán egyre többen használták, be is épült a CPU-ba.
  Pedig ahhoz egyetlen dolog kellett, a CPU felismerte a nem neki szánt utasításokat, és továbbította megfelelő lábain az FPU-nak. Erre pl. az Intel-nek manapság is vannak már megoldásai pl., csak ugye minek, amikor már vannak a piacon kész, platformfüggetlen megoldások.

  A heterogén megoldások jobban kiterjesztik a párhuzamosítás lehetőségeit, mint a többszálúsítás, ez a grafikai eredetükből is látszik: klasszikus példám az, hogy egy nagyméretű színes képet akarsz fekete-fehérré tenni. Ha CPU-programozó vagy, akkor egy processzoron írsz egy (minőségigénytől föggően) 5-10-15 utasításból álló ciklust, ami lefut minden pixelre, egymás után - némi átfedéssel, OoO miatt. Majd beleizzadsz, hogy jó teljesítményt nyújtva 2-4-8 magon jobban, gyorsabban fusson le ugyanez (az adminisztáció, elosztás, szinkronizáció időigénye miatt). Ugyanezt megírod egy GPU-like architektúrára, hogy fusson le minden pixelre ugyanaz az 5-10-15 utasítás, a hardware + driver pedig kezeli neked, hogy hogyan, mi módon párhuzamosítva, te csak azt látod, hogy gyorsabb, mint CPU-n (pl. OpenCL).

  Hozzátéve, hogy egy GT9500-ból vagy egy GT220-ból ily módon kihozható számítási teljesítmény kb. egy 4/6 magos CPU-éval egyezik, a CPU-többszálúsításánál könnyebben elsajátítható programozási modell mellett, akkor szerintem billen a mérleg asztalon is.

  [ 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