- AMD GPU-k jövője - amit tudni vélünk
- Google Chromecast topic
- VR topik (Oculus Rift, stb.)
- Gaming notebook topik
- Milyen TV-t vegyek?
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen cserélhető objektíves gépet?
- ThinkPad (NEM IdeaPad)
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
Hirdetés
-
A franciáknak elege van abból, hogy minden gyerek mobilozik
it Vissza akarják szorítani a gyerekek és tinédzserek közösségi média- és okostelefon-használatát.
-
Hamarosan indul a SERUM korai hozzáférése PC-n
gp A belső nézetes túlélőjáték premierje május végétől lesz elérhető.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Új hozzászólás Aktív témák
-
Huntszy
tag
Ez csak reklámduma. Aki streamelni akart eddig is meg tudta oldani. Aki meg nagyon komolyan veszi annak úgyis van egy különálló gépe erre a feladatra, nem kell a gaming pc-n számolgatni az erőforrásigényeket, hogy mire mennyi jut.
Ez olyan mint mikor a Samsung a 32:9-es super ultrawide monitorokat azzal akarja eladni, hogy gamer miközben annak ellenére, hogy magam is tervezek egy ilyet beszerezni számos előnye miatt pont, hogy gamingre baromira nem éri meg/nem alkalmas. -
Yutani
nagyúr
Igen, én is úgy érzem, hogy ez nem felhasználói oldalról érkező igény, hanem majd az Intel megmondja a usernek, hogy mi kell neki. Előbb-utóbb nem kapsz majd mást, főleg, ha az AMD is elkezdi ezt a hülyeséget.
Most komolyan, desktopra minek kell ilyen kifejezetten mobil irányú fejleszést hozni?, ami csak megbonyolítja mindenki életét (Microsoft némán bólogat). Desktopra, hangsúlyozom.
#tarcsad
-
#16
Petykemano
veterán
dokanin
#13
Petykemano
veterán
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..
-
S_x96x_S
őstag
> nem nagyon értem, mi értelme a kicsi magoknak jelenleg.
- ha később lesz értelme,
akkor már most el kell kezdeni a szoftveres integrációt
és nem akkor amikor már késő.- tartani kell a lépést az Apple M1 -el ..
- Környezetvédelem ; Energiahatékonyság
( már ha aggaszt téged a Globális Klimaváltozás )
Főleg ha a procikat is elkezdik - a hütőgépekhez hasonlóan osztályozni.
- Notebook-ok ; NUC-ok
következő generációs konzolok;
NAS -ok;
> Nekem is sokkal inkább az az érzésem, hogy a gyártástechnológia
> hiányosságai miatt nem képesek tartani a lépést magok számában
> ezért most kitaláltak hozzá valami ideológiát, hogy miért is lesz ez jó.ettől függetlenül hasznos dolog.
Ha az Intel nem lépi meg, akkor tovább folytatódik az ARM - általi kiszorítás.
És az Apple-t már elvesztette.Szóval kényszerített lépés
Az Apple - a legjobb gyártástechnológiával - a legjobb mérnökökkel - mégis ezt választotta. Főleg azért mert ezt a procit alkalmazza az erősebb mobiltelefonokban, a tabletekben és a laptopokban és az apple mini-ben is.
Ezt jelenleg az Intel procikkal nem lehet megtenni.És ha az Intel nem lép,
az X86 elveszti a tablet és a notebook piacot is
- mint a mobiltelefon piacot.Mottó: "A verseny jó!"
-
#25
Petykemano
veterán
dokanin
#19
Petykemano
veterán
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..
-
#50
Petykemano
veterán
dokanin
#47
Petykemano
veterán
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
Petykemano
veterán
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..
-
#71
Petykemano
veterán
dokanin
#66
Petykemano
veterán
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..
-
joghurt
addikt
Ezt az ún. thread poolozást kb. minden valamire való környezet használja. Bár menet közben tudsz buzerálni a szálak paraméterein (prioritás, sőt: konkrétan magokhoz/magcsoportokhoz rendelés), alapvetően az oprendszer ütemezőjének a dolga, hogy ezt a meccset lejátssza. Persze, a saját szempontodból a saját szálad a legfontosabb, de rajtad kívül fut száz másik folyamat, aminek szintén van nagyon fontos dolga.
Ha van egy rakás lefuttatandó feladat, és ennél kevesebb processzormag (mindegy, milyen erőviszonyokkal), akkor az összes megemésztése kb. ugyanannyi ideig fog tartani - függetlenül attól, melyik mag melyik feladattal kezd. Az OS ütemezőjének meg remélhetőleg megvan az információja, hogy a vége felé (amikor már fogyóban a nagyon fontos dolgok), akkor az erős magokra ütemezze a nagyobb prioritású szálakat.
A Little.Big nem a számítási teljesítményt növeli, hanem lehetővé teszi a nagy teljesítményű magok lekapcsolását, ha azokra nincsen szükség (pl. zsebre rakott telefonnál).@Tentalus: Időkritikus dolgot nem írsz JS-ben, mert arra nem való. Ennyike.
A tej élet, erő, egészség.
-
Ezeken felesleges aggódnod. A .Net Task Parallel Library (TPL) amit konrétan felhoztál illetve álltalában egyéb .Net jóságok mutatnak a fejlesztő felé egy API-t, mint pld a Parallel.ForEach amit a programozó használhat és tudja hogy működni fog, többé-kevésbé jól.
Az hogy a motorháztető alatt hogyan működik ez, az a Framework dolga, a Framework készítői pedig pár év késéssel majd lekövetik a változó világot. Pld Ő
Ehhez hasonlóan pld a Garbage Collectort sem kell (kivételes helyzetektől eltekintve ) kézzel mikromanagelni. Pár alapszabályt betartasz és jól működik a háttérben, függetlenül attól, hogy a program mobilon, PC-n vagy szerveren fut.
Egyébként a szóba hozott Parallel Library is akkor működik jól, ha a feladatokat jól szét lehet szabdalni egymástól független részekre ahol is nincsen szinkronizáció és a szálak nem várnak egymásra. Ilyen feladatok esetén pedig a tipikus cél az időegység alatt elvégzett munka maximalizálása és nem az hogy minél hamarabb készüljön el egy-egy rész-feladat (throughput vs latency).
Ebben a konkrét kontextusban a Big.Little koncepció semmilyen törést nem fog okozni. Ha belegondolsz, a nagy magok közül is 1-2 maxra boostolgat, míg a többik pár száz Mhz-zel alacsonyabban futnak, mégsem okoz ez problémát a TPL-nek.
Programozói modell szintjén én pld nagyon egyszerű és elegáns megoldásokat is el tudok képzelni az alacsony késleltetést igénylő feladatok és a nem kritikus dolgok szétválasztására .Net-ben. Ezzel nem lesz probléma, inkább hogy a programozók kezdjék el használni illetve updateljék az öreg programjaikat. (Kb soha napján
) Illetve kíváncsi vagyok hogy pld a MS elhiszi-e azt hogy ennek a big little dolognak van-e bármi értelme. [ Szerkesztve ]
-
Robitrix
senior tag
Talán, hogy elkerülje a kevés a fóka, de sok az eszkimó szitut. Ha sok a futásra váró program szál és nem jut alá elég mag és szál, akkor lesznek várakozó programágak. Természetesen azt is tudni kell mindenkinek, hogy amikor írja a programot nem tudja milyen hardveren fog futni a program. És a programnak osztozni kell más felhasználó programokkal: aha van egy 4 gyors 4 lassú magos gépem és az összes programszál a gyors magra vár, akkor a 4 gyors magon tumultus lesz. Írok mondjuk egy 6 párhuzamos programágat használó programot. ebből 2 programág nagy teljesítményt igényel 4 meg csak keveset. HA a 4 kisebb igényű mag is a a gyors magra kerül, akkor elveszik az időszeletet a gyors teljesítményt igénylő ágaktól. Miközben ott áll kihasználatlanul 4 lassabb mag, ami alig csinál valami. Prsze nem csak az említett program fut a gépen. Így ott fog tolongani mondjuk a 4 magért egyszerre 41 folyamat. vagyis a 4 fókára les a 41 eszkimó.... Minnél nagyobb a tülekedés a 4 magért annál kevesebb fóka darab jut egy eszkimónak. Amit nyerne teljesítményt a lassabb igényű programágak gyors magon futásával lehet simán elveszti a tülekedésben. Sokkal jobban járhat, ha a kis igényű program ágakat inkább ráküldi a lassab magokra. Hiszen akkor több teljesitményt tud szerezni a gépen. 4 gyors mag < 4 gyors + 4 lassabb mag. vagy képzelj egy egy égő házat a faluban. odamegy 30 ember oltani de csak 15 darab nagy vödör van, ami mondjuk 15 literes. Ha ott ácsorog 15 ember és arra vár, hogy hozzájusson egy fordulóra a 15 literes vödörhöz az rossz hatékonyság. De ha van 15 kisebb vödröm, akkor azt is a kezükbe nyomom és a 30 vödörrel már több vizet képesek a tűzhöz hordani. Tehát vélhetően jobban járok, ha kihasználom a lassabb magok teljesítményét is, mint ha folymatosan csak a gyors magokra próbálok spekulálni.
) Illetve kíváncsi vagyok hogy pld a MS elhiszi-e azt hogy ennek a big little dolognak van-e bármi értelme. 
Új hozzászólás Aktív témák
ph Miután az Intel bevezette az utasításkészletet a Tiger és Rocket Lake-ben, kivágja az utódnak szánt Alder Lake-ből.
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i3 9100 4 mag 4 szál processzor garanciával hibátlan működéssel
- PROFESSZIONÁLIS Delid / Relid AMD Ryzen Processzorokhoz, garantált minőségben! (CSAK AM5!)
- i5-8500
- BESZÁMÍTÁS! ÚJ Intel Core i5 11400F / i9 11900KF / i9 11900K tálcás processzorok 27% áfás számlával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen