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

• #33 DraXoN addikt hokuszpk #32

  Új Válasz 2024-01-27 21:18:38 #33

  Ú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

  

  DraXoN

  addikt

  LOGOUT blog

  válasz hokuszpk #32 üzenetére

  a zen5 mellé nem ment volna zen4c, zen5c volt tervezve mellé mint "egyszerűbb mag". A zen4c inkább csak cache-ben kisebb és méret optimalizált (az elérhető órajel "kárára", a lényeg az volt kompaktabb legyen a mag).
  A zen5c elvileg ugyan ezen koncepció alapján egyszerűsített zen5 mag.
  érdekesség lesz olyan cpu (laptopba) amiben csak zen5c mag van, abból viszont 16db (32szállal).. meglátjuk milyen lesz, ha lesz.

• #22 DraXoN addikt [CS]Blade2 #21

  Új Válasz 2024-01-26 09:32:05 #22

  Ú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

  

  DraXoN

  addikt

  LOGOUT blog

  válasz [CS]Blade2 #21 üzenetére

  Pontosan nem tudjuk 1 P mag helyére hány E mag fér... szép marketing lehet ez a "1 helyére befér 4), de ez tényleg így van? Mi a helyzet a cache-vel? Az IO résszel ami ezt kezeli? Az adatbusz szélességével, hogy etetni lehessen?
  Nem hiszem, hogy olyan egyszerű csak úgy kicserélni. Persze ezek mind "titkok", ami már nem része a marketing adatoknak.

  Lehet egy darabig jól skálázódik az E magok esetén, de gyanítom hamar eljön ott a "határ" ami felé csak speciális alkalmazások esetén lehet menni. Nem véletlen állt meg átlag otthoni piskike 6-8 mag körül, otthonra felesleges jelenleg több. Nem készültek fel rá a programok még mindig. Intelnél az E magok arra jók (leginkább), hogy a háttér folyamatok at átadja neki a rendszer így a P mag "szabadon" dolgozhat azon az alkalmazáson ami az előtérben van... ráadásul úgy néz ki kicsit külön "claster"-ben vannak, külön adatbuszal (? talán), mert erősen csökkenti az overhead-et teljes cpu terheléskor. De erre szerintem 4 E mag is elég lehet, 8Emag bőven sok, felé menni, kérdéses van-e értelme, persze... szépek a nagy számok.

• #20 DraXoN addikt apatyas #19

  Új Válasz 2024-01-26 09:23:14 #20

  Ú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

  

  DraXoN

  addikt

  LOGOUT blog

  válasz apatyas #19 üzenetére

  Mondjuk magok között a skálázódás sose lineáris, az adat átadás és megosztás mindig késleltetéssel jár, ami teljesítmény vesztést okoz.
  A HT lényege is ez, ezen belső késleltetéseket "csökkenteni". (az által, hogy 2 folyamatban kap elvileg egymástól független értéket, így a CPU mag részegységei egymástól függetlenül, párhuzamosan két (vagy több, ha nem 2 szálas a HT) tud végrehajtani.. (amíg nem lesz belül "feltorlódást"). Az elmélet jó, a valóság nem mindig ilyen egyszerű.
  Jelentősen lehetetne növelni a HT minőségét ha a második szál műveletei egyes esetekben korlátozva lennének... pl. ha a "fő száll" erősen terheli az ALU egységeket, akkor a második akkor csak összeadásokat tudjon csinálni (mert az ALU egység mindig lassú az összeadáshoz képes). De ez eléggé bonyolult lenne, sok tranzisztort emésztene el, így valószínű "nem éri meg".

  AMD féle bulldozer architektúra is érdekes volt (és nem működött). 1 magban 2 feldolgozó volt, és minden duplázva lett, kivéve a lassú ALU-t. Jó volt elméletben.

• #15 DraXoN addikt [CS]Blade2 #8

  Új Válasz 2024-01-25 09:31:27 #15

  Ú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

  

  DraXoN

  addikt

  LOGOUT blog

  válasz [CS]Blade2 #8 üzenetére

  Llano (és az egész koncepció), leginkább a szoftvereken ment el, azon belül is már a fejlesztő környezeteknél.
  Mivel a GPU-k külön egységként kezelhetők benne, más memória címtérrel, függvény könyvtárakkal (stb), eléggé korlátozott utasítás készlettel, nagyon nagy macera volt rájuk programozni.. egy "egységesebb kezelés" segített volna, JAVA 9-re volt ígérve is a legelején amikor épp megjelen a JAVA 7, majd csúszott a koncepció JAVA 10-re (ígéret szinten), azt az egész "elhalt" mint törekvés a "közös kezelésre egy programnyelven".. De ez csak a JAVA volt, a többi népszerű nyelvnél színtén voltak "problémák" ebben.

  A koncepció nincs ugyanakkor elfelejtve, csak "megragadt a félig kész, de jól van ez így" állapotban. Bizonyos műveletekre még mindig megéri behívni a GPU-t a folyamatba (akár akkor is ha csak egy integrált egység a cpu-n belül).

  A GPUk álalánosan számításba való befogásával az is gond volt, hogy az operációs rendszereink se úgy épültek fel, az egészet már kernel szinten kellett volna módosítani, befogni, de AMD önmagában ehhez kicsi volt, hogy ezt keresztülvigye (ráadásul neki is voltak GPU nélküli CPU termékei akkor is).. Az új megközelítés lehet látni mennyire egyszerüen kerül be.. a big-little koncepció is még mindig "nem az igazi" rendszer szintű kezelésében a windowsnál, sőt a HT-t is mai napig mostohán kezeli. Linux alatt hatékonyabban működnek ezen felépítésbeli változások, de még ott is a GPU integrálása kernel szinten, nem igazán sikerült, legalábbis azon a szinten ahol megragadt az APU-k összeépítése. Eleve AMD is félbehagyta a koncepció végigvitelét amikor a költségeket vissza kellett vágni a ZEN magok elkészültéig..

  Szép terv volt, de sajnos a programozókon és program környezeteken elment a dolog.. Nem ez az első és lehet nem is az utolsó eset. Eltudom képzelni, hogy a big-little koncepciónak is ez lesz a vége.. Eddig azért nem túl hatékonyak, oké, többre használhatóak mint a GPU-k egységei (akár háttérfolyamatok rádobhatóak, van saját process értelmezőjük az egységeken belül).
  De, hogy tényleg hatékonyan működjön a dolog, megkéne oldani, hogy ne kelljen utasítás szinjén megegyezni a kis és nagy magoknak.. Akkor tényleg lehetne hatékony magokat csinálni.

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