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

• #16 Petykemano veterán dokanin #13

  Új Válasz 2021-08-23 16:49:39 #16

  Ú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

  

  Petykemano

  veterán

  válasz dokanin #13 üzenetére

  Az intel koncepciója a big.LITTLE tekintetében nem "Efficiency + Low Power", hanem "Performance + Efficiency"
  A kis magok célja nem az alacsony fogyasztás, amikor nem vagy alig használod a készüléket, hanem az energia- és tranzisztorhatékonyság, amikor igen.

  A Performance magok csak a magas IPC miatt kellenek. Arra nem fogják kímélni a tranzisztort és az energiát.
  Ha Multithreadre képes alkalmazástokat használsz, akkor viszont láthatod, hogy a jelenlegi magok se nagyon mennek 3.5-4Ghz fölé, mert afölött már túlságosan sokat fogyaszt 1 mag.

  A cél az, hogy egy 4 szálra skálázódni képes alkalmazás ugyanabból az energiából és transzisztorból 2x akkora throughputot érjen el 4 kis magon futva, mint 1 nagy magon.

  Találgatunk, aztán majd úgyis kiderül..

• #25 Petykemano veterán dokanin #19

  Új Válasz 2021-08-23 21:17:18 #25

  Ú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

  

  Petykemano

  veterán

  válasz dokanin #19 üzenetére

  Az 8 magos zen megjelenése előtt ugyanezt a kérdést fel lehetett tenni - és fel is tették: mégis mi értelme lenne 6-8 magos procit venni, 4 mag (i5) mindenre IS elég, aki egy kicsit flancolni akar az meg megveszi a 8 szálas i7-et.
  Eltelt pár év és eléggé standarddé vált a 6/12 konfiguráció, ennél gyengébbet csak az vesz, aki kifejezetten spórolni akar, vagy amd esetén apu-t.

  Természetesen nem állítom, hogy minden program hatalmas lépéseket tett abba az irányba, hogy több szálon skálázódjon. a DX12 és a Vulkan megjelenésével leginkább a játékokon lehet ezt tetten érni. De tegyük hozzá, hogy ha megnyitod a rendszerfigyelőt, azt láthatod, hogy a chrome is kismillió szálon fut. Ezek nem terhelnek nagyon, de annyira biztosan, hogy lehessen rajta energiát spórolni azzal, hogy egy kisebb mag szolgálja ki.

  Ezen a ponton látszólag kicsit ellent fogok mondani magamnak. Mindenesetre a "mi ételme a kis magoknak?" kérdésre a válasz az, hogy az Alder Lake elsősorban mobil fejlesztés. (Ahogy ez mindig is volt az intel asztali processzorai esetében)
  Tehát az lesz a 8 kis mag értelme, hogy amikor meg van nyitva a notebookon 10-20 chrome tab, akkor azokat elviszik a kis magok is.

  Amiben viszont szerintem különbözni fog az Intel megközelítése az Apple-től, hogy jelenlegi ismereteink szerint a throughputot az Apple nagy magokkal, míg elképzelésünk szerint az intel a kis magokkal fogja megoldani.
  (Ahogy azt tanult kollégám paprobert #20 is mondta)

  8 kis magtól nyilván nem várható átütő erő throughput vonatkozásában. A későbbiekben fog ez a szám emelkedni. A raptor lake-ben 16, később talán már 32 lesz. (a 8 nagy mag mellett persze)
  32 kis mag, ami rendelkezik 16 nagy mag teljesítményével, de elfér 8 nagy mag helyén és beéri 8 nagy mag fogyasztásával.*

  (* a tényleges teljesítményadatokkal majd várjuk meg a teszteket)

  És hogy ez hová lesz majd jó?
  Mondjuk egy 8+16-os konfog bárhová jó, ahová jelenleg az AMD 16 maggal lő. Én nem tudom kik azok pontosan és milyen felhasználási területen van szükség 16/32 processzora, de az biztos, hogy az intel ezt a kihívást throughput szempontjából 16 nagy magnyi lapkaterület lés fogyasztás helyett csak 12 nagy magnyi lapkaterületből és fogyasztásból fogja kivitelezni.

  Találgatunk, aztán majd úgyis kiderül..

• #33 Petykemano veterán tha_answer #26

  Új Válasz 2021-08-23 23:41:11 #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

  

  Petykemano

  veterán

  válasz tha_answer #26 üzenetére

  Érdemes elolvasni/meghallgatni Jim Keller legutóbbi témában adott interjúját.
  Szerinte az ISA önmagában kevésbé számít.
  [link] [link]

  Minél régebbi egy ISA, persze annál terheltebb lehet saját múltjával való kompatibilitással.

  Ma legalább annyira fenyegeti az x86-ot az arm, amennyire az armot a RISC-V.

  Találgatunk, aztán majd úgyis kiderül..

• #50 Petykemano veterán dokanin #47

  Új Válasz 2021-08-24 12:15:34 #50

  Ú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

  

  Petykemano

  veterán

  válasz dokanin #47 üzenetére

  Szerintem megint egy elég távoli helyről hozol példát.
  A Xeon Phi célja x86 alapon egy olyan gyorsító megvalósítása volt, amilyen célra máskülönben mondjuk inkább GPU-kat használnak.

  Ahogy korábban is mondtam, 16, meg 32 Efficiency mag azokon a felhasználási területeken lesz hasznos, ahová, amire ma a 16 magos Ryzen-t vagy 16-64 magos Threadrippert veszik jelenleg. a 64 magos Threadripperre is azt mondanád, hogy hülyeség az, mert a bulldozer, meg Xeon Phi is megbukott?

  Összehasonlításképp:
  A Gracemont-tól a Golden Cove mag csak 33%-kal magasabb IPC-vel rendelkezik.
  A 64 magos TR esetén se mennek a magok 2.9Ghz-nél többet teljes terhelés esetén.

  Találgatunk, aztán majd úgyis kiderül..

• #53 Petykemano veterán dokanin #52

  Új Válasz 2021-08-24 13:41:47 #53

  Ú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

  

  Petykemano

  veterán

  válasz dokanin #52 üzenetére

  Nem "gyenge mag"
  Ahogy mondtam, elvileg a Gracemont mag IPC-je elég magas, valahol ott van, ahol a skylake. Attól az intel épp csak most kezdett elrugaszkodni. Elvileg a Golden Cove magok IPC-je "csak" ~33%-kal magasabb. Legyen 30-40%. [link]

  jól skálázódó több szálas terhelés esetén (ahol létjogosultsága lehet a 16+ magos DT/HEDT Ryzennek), a magok nem tudnak a turbó frekvencián ketyegni. De 1Ghz differencia azért biztosan lesz a két magtípus között még úgy is.
  Tehát ha egy Golden Cove magot 1 egységnyinek veszünk (MT terhelés esetén turbó nélkül), akkor IPC alapján egy Gracemont 0.75 és mondjuk frekvencia szempontjából is 25%-kal kevesebbet ér el, akkor valahol 0.6 körül találunk egy Gracemont magot.
  De az 1 Golden Cove magra is 2 szál jut a HT miatt, vagyis valójában a Golden Cove 1 szálon szintén csak valahol 0.6 - 0.65 körüli értékkel fog rendelkezni.

  Viszont 1 Golden cove mag (2x0.65) helyére elfér 4 Gracemont (4x0.6)

  Az egész persze azon fog múlni, hogy az ütemező tudja-e ezt kezelni, hogy mikor érdemes egy programszálat a kis magra tolni. Az ezzel kapcsolatban megszólalok azt mondják, hogy a windows 11-ben elég jól sikerült megugrani ezt a kihívást.

  Azt nem tudom, hogy .net esetén neked milyen kontrollod van/lesz arra nézve, hogy a programszálak milyen processzor szálakra ütemeződnek. De remélhetőleg kevés szálon futó program esetén lesz olyan okos az ütemező, hogy ne kutyulja, vagy okosan kutyulja a szálakat.
  Egyébként a 8 magos cpu esetén ha a programod 8 szálnál többel dolgozik, akkor az mindenképp egy "melyik ujjamba harapjak" szituáció, nem? Ha keletkezik egy 9. szál, akkor az nagy eséllyel egy már amúgy foglalt mag második szálját fogja befoglalni.

  Mindenesetre biztosan lesznek problémák kezdetben. Csakúgy, ahogy a zen 4magos CCX felépítésével kapcsolatban is voltak.

  Találgatunk, aztán majd úgyis kiderül..

• #67 Petykemano veterán Pingüino #62

  Új Válasz 2021-08-24 23:32:15 #67

  Ú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

  

  Petykemano

  veterán

  válasz Pingüino #62 üzenetére

  Elméletileg a GPU nyilván alkalmasabb lehet sokszálas throughputra.
  Amiben nem értek veled egyet az az, hogy szerintem ahhoz viszont az egyes szoftvereket kellene átírni. Gondolom hosszútávon ez a cél, az Intel nemrég arra verte a nyálát, hogy náluk mennyi minden különböző célű részegység - CPU, GPU, FPGA, etc - megvan, míg a konkurenciáknál semmi.

  Szóval a GPU-s futtatásra való átírást a szoftvernél kell megoldani, míg a kis és nagy magok közötti megfelelő ütemezést el tudták intézni a MS-tal - akivel közös érdek, hogy ez jól menjen.

  Azt a Kaveri óta várjuk, hogy megtörténjen a GPU-ra való terhelés offloadolás. Jó, én értem, hogy az AMD kis piaci szereplő, de az intel esetén generációk óta ott van minden asztali és notebook processzorban az IGP és mégis elég kevés, ahol GPU-ra való offloadolás létezik.
  Hogy miért, azt én nem tudom, de azt gyanítom, hogy valami olyasmi van, hogy az IGP ugyan memóriakoherens, de túl gyenge ahhoz, hogy megérje vesződni vele, a dGPU már elég erős volna, de a memóriatartalom másolás/elérés/késleltetés túl nagy ahhoz, hogy megérje vesződni vele.
  Arra is csak várunk, hogy legyen valami middleware, ami anélkül oldja meg a IGP-re való offloadolást, hogy a programot kifejezetten úgy kelljen megírni.
  Az is álom, hogy - az AMD - majd a vektorutasítások CPU-ba való integrálása és implementálása helyett a az AVX-AVX2-AVX512 utasításokat offload-olja a GPU-ra, amiben a SIMD egységeket pont erre találták ki, nem csak valami "ritkán használt, hülye" kiterjesztés.

  Persze elméletben lehet, hogy igazad van, szuperszámítógépekben nyilván nem véletlenül használnak GPU gyorsítókat. De ilyen jelen viszonyok között valószínűleg egyszerűbb (profitábilisabb) volt gurítani egy 64 magos Threadrippert.

  Egyébként az azért látszik, hogy az intel sem nyomott all-in-t azért. az ALder Lake egy elég óvatos próbálkozás, amivel leginkább az ütemező lesz tesztelve. Ha mégse jön be bármi okból, akkor tulajdonképpen bármikor nyomhatnak egy hátraarcot és építhetnek csak Cove magokból procikat. Azt gondolnám, hogy ha az Alder lake bukó lesz, akkor a Raptor lake utáni generációban még korrigálhatnak.

  Találgatunk, aztán majd úgyis kiderül..

• #71 Petykemano veterán dokanin #66

  Új Válasz 2021-08-25 11:18:29 #71

  Ú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

  

  Petykemano

  veterán

  válasz dokanin #66 üzenetére

  Nem teljesen értem az aggodalmad.
  Jelenleg ha van egy 8 magos procid, és a parallel framework (PF) 8 szálat indít és egyenlően osztja el a terheket, akkor azok nagyjából egyenlő időben végeznek. Tételezzük fel, hogy 16 egységnyi feladatod van, akkor 2 egység idő alatt végeznek.

  Természetesen ha 16 magos procid lenne, akkor 1 egységnyi idő alatt lenne kész 16 szálon.

  Az alder Lake esetében azt fogod tapasztalni, hogy 16 szálat indít a PF, ebből 8 szál egységnyi idő alatt lesz kész, a másik 8 pedig 1.5 egységnyi idő alatt. Az sem kizárt, hogy miután a nagy magokra ütemezett szálak végeznek, az ütemező a kismagokon futó szálakat átütemezi nagyjából 2/3 állapotban a nagy magokra és végeredményben mégse 1.5, hanem mondjuk 1.3-1.4 egységnyi idő alatt leszel kész.

  Ez persze nem olyan gyors, mintha 16 nagy magból álló procid lenne, de az Alder lake tranzisztor és energiaigénye csak kb 10-11 nagy magnak felel meg. Ha 10 nagy magos procid lenne, akkor a 16 egységnyi feladatod 1.6 egységnyi idő alatt lenne kész.
  Tehát összességében - ahhoz képest, amennyi helyet és energiát igényelnek a kismagok - jobban jársz.

  Találgatunk, aztán majd úgyis kiderül..

• #72 Petykemano veterán S_x96x_S #69

  Új Válasz 2021-08-25 11:26:01 #72

  Ú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

  

  Petykemano

  veterán

  válasz S_x96x_S #69 üzenetére

  OneAPi és ROCm.
  Előtte HSA volt.

  Ne érts félre, nem azt mondom, hogy soha nem fog bekövetkezni, nyilván nem véletlenül csinálja az intel a GPU-kat és a OneAPI-t .
  Biztos lesz olyan program, ami nagyon hamar használatba veszi majd ezeket.
  De én úgy vélem, hogy big.LITTLE és a GPU offload közül előbbire könnyebb/gyorsabb általános szoftveres támogatást kieszközölni.

  Találgatunk, aztán majd úgyis kiderül..

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