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

  • Már minden is lesz az új Intel processzorokban. Kis mag, nagy mag, közepes mag, meggymag, tökmag, sejtmag, vasmag, megszorítócsomag...

    A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

  • hallador

    addikt

    Az egész nehézsége pont ugyanaz, ami az ARM koncepciójánál, szoftveres szinten is kezelni kell azt, hogy eltérő teljesítményűek a magok, és ez annál bonyolultabb, minél több variációval dolgozik egy lapka, de elméletben megoldható problémáról van szó.


    Sőt mi több annyira elméleti a probléma, hogy az összes Androidos, nem csak csúcsmobil, az Apple M1 gyakorlatilag a teljesítmény processzorokon felül, mint a Power, XEON, AMD Epyc, lassan minden platform erre felé megy.
    Eddig nálam nagyon úgy tűnik, hogy ez a szoftveres probléma, amit a cikk emleget, kevésbé problémás, mint az amennyi előnyt hoz ez a megoldás.

    The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

  • hallador

    addikt

    válasz lezso6 #1 üzenetére

    Ja ja kell is ez, minden platformon hülyék dolgoznak, kivéve az AMD-nél...
    A rossz hír, hogy eddig 10 alkalomból 9-szer az AMD vette át az Intel fejlesztéseit, és nem fordítva. Az pedig, hogy azokat továbbfejlesztette, meg is lett az eredménye...
    De sebaj, meglátjuk melyik platform design az előremutató x86.on.

    [ Szerkesztve ]

    The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

  • fatpingvin

    őstag

    ez annyira azért nem lep meg, figyelembe véve hogy az ARM dizájnok mekkorát mentek ezzel, illetve hogy az Intelnek már így is viszonylag régi rutinja van a műfajban: 2010-es évek eleje óta van egy beágyazott ARC/Quark processzormagra épülő hardveres rootkit a cuccaikban, IME néven ismeri az ipar. az újítás itt most csak az lesz hogy ezt a koncepciót a júzer számára is elérhetővé teszik, a rootkit persze marad ;]

    az jutott még eszembe, ezzel a sztorival talán még úgy lehetne nagyobbat dobni, ha a kicsi és a nagy magkomplexek esetleg tudnának olyat, hogy külön memóriaterületet foglalnak le maguknak, kicsit hasonlóan az iGPU megoldásaihoz. így lehetne pl a virtualizáció szeparációján erősíteni, vagy akár direkt virtualizáció nélkül párhuzamosan két kernelt futtatni ugyanazon a vason. ARM-en emlékszem megoldható, bár igaz az sokkal transzparensebb (jómúltkor olvastam egy cikket arról, hogy egy fószer szimultán futtatott OpenBSD-t meg VXW-t valami big.LITTLE ARM SoC-on, virtualizáció nélkül, kis magokon VXW, nagyokon BSD.)

    [ Szerkesztve ]

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • hallador

    addikt

    válasz fatpingvin #4 üzenetére

    De nyugtass meg ilyet csak az intel csinált senki más nem. Mert akkor nem lenne a topik teljes értékű.

    ESXi is fut rpi4-en, és semmi gond vele, nekem van is itthon 4 Ubunut-t elfuttat simán. Szóval ez is csak szofvter kérdése. Teljesítmény a kérdés, de ha elég az arm, mint nálam most, akkor éppen még jó is lehet.

    [ Szerkesztve ]

    The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

  • fatpingvin

    őstag

    válasz hallador #5 üzenetére

    az AMD PSP-je hasonló egy ARM maggal, bár ott a funkcionalitás még egész jól értelmezhető a rootkit funkcionalitás feltételezése nélkül is (memória inicializáció, device tree detection, satöbbi) mert pl önmagában nincs benne network stack.

    x86 fronton talán a VIA és a Zhaoxin az egyedüli ahol nincs beágyazottt koprocesszor (nem tudom részletesen, ők ugye nem arról híresek hogy részletesen dokumentálnák ezeket), ott viszont számomra a VIA AIS (alternative instruction set) az ami kifejezetten aggasztó: egy megfelelő utasítással a processzor utasításdekódere átkapcsol egy másik utasításkészlet használatára, ráadásul a bytecode-ok között van átfedés. ha akarsz erről olvasni, [link]

    [ Szerkesztve ]

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • Alogonomus

    őstag

    Ez csak az asztali és laptop processzorokra vonatkozik, vagy a komolyabb területeken jelentkező lemaradásukat is ezzel próbálja kezelni az Intel? Csak mert a legtöbb HPC környezetbe szánt operációs rendszer vagy komolyan küzd a P és E magok megfelelő használatával, vagy egyenesen csak az egyik típust hajlandó használni a processzoron belül.

  • Lacccca87

    őstag

    válasz hallador #2 üzenetére

    Gond az van. Kicsit olvasgatsz visszamenőleg akkor te is rájössz.
    Linuxnal lehet kevésbé gond de win alatt boven van problema (profi alkalmazasok, atlagfelhasznalas es jatekok eseteben is) , akadozasok, lassu teljesitnyem stb...
    Ugy amugy jo koncepcio, mert energia takarekossag szintjen sokat jelenthet (laptopnal uzemido sporolas, vagy asztalinal kevesebb fogyasztas, es akkor a csokkeno hotermelesrol nem is beszeltunk)

    Tematol elterve, mar nem 1990-2000 es evekben vagyunk hogy itt neked kellene megvedeni az intel becsületét vagy hitteriteni. El kellene mar engedni ezt a "butt hurt" szintű fanboysagot.

  • Petykemano

    veterán

    válasz hallador #2 üzenetére

    Az M1-hez és a többiekhez szólnék hozzá. Szerintem az Apple koncepciója (lehetőségei?) egészen más, mint az Arm-é és amit látszólag most az Intel is követ.

    különböztessünk meg három különböző architektúra designt/goalt.
    (High) Performance: P
    Efficiency: E
    Low Power: LP

    A P magokat nem kell magyarázni: maximális teljesítmény elérése tranzisztor és energia nem számít alapon. (mármint: "nem számít", mert persze számít, csak hajlandóak vagyunk kissé elengedni azokat a fonalakat)
    Az E magot az LP magtól az különbözteti meg, hogy az LP mag fogyasztása tényleg alacsony, cserébe nem baj ha lassú. A cél az, hogy ha csinálnia kell valamit is, akkor azt a lehető alacsony energia mellett végre tudja hajtani.
    Az E magokat pedig nagy teljesítményre (főleg inkább MT) tervezik, de úgy, hogy az energia és/vagy tranzisztorhatékonyság fontos szempont. Tehát amikor azt látod egy designban, hogy skálázzák az "alacsonyabb fogyasztású" magokat, akkor azok biztosan nem LP magok, mert azt skálázni semmi értelme.

    Az Arm sokáig csak P és LP magokat használt.Aztán az X1 és A78 megjelenésével vált ketté és az X vonal lett a P típus és az A7__ vonal pedig az E mag.
    (Bár előfordult olcsóbb csak LP magból álló lapka, de azokat célszerű volt inkább elkerülni.)

    Az Intel P és E magokat használ, jelenlegi designokban nincs valódi LP mag.
    Az E magokat az Intel arra tervezi használni, hogy azzal nyújtsa meg a MT teljesítményt. Jelenleg leginkább a tranzisztorhatékonyság érvényesül.

    Az eddigi Apple designok a régi Arm utat követik: vagyis P és LP magokat használnak.
    Ezt abból lehet tudni, hogy a nagyobb teljesítményű lapkák esetén nem a kis magokat skálázták, hanem a nagyokat.

    Az Intel koncepciója az ARM-ét követi, de egyelőre úgy tűnik, hogy ez csak a kliens piacokon, vagyis desktop, mobil. Szerintem a heterogén felépítésnek a legnagyobb haszna az egyfelhasználós Workstation piacon lenne: olcsón le lehetne dobni nagy MT teljesítményt. De még erre sem látszódnak jelek.
    Szerverek terén az Intel be fogja vetni az E magokat, de jelen információk szerint homogén architektúrában.
    Az Arm szerverek esetén sem jelent még meg heterogén megközelítés.

    Az AMD elvileg nem fog teljesen különböző processzorcsaládba tartozó magokat összeépíteni. De ők is készítenek olyan változatokat, amelyek esetén a változtatások célja a MT teljesítmény növelése. A megközelítés és a felhasznált építőkockák lehet, hogy mások, de a végeredm mindenképpen az, hogy olyan lapkák fognak napvilágot látni, amelyeknél az egyes magok képességeiben a korábbiaknál nagyobb különbség lesz tapasztalható.

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

  • hallador

    addikt

    válasz Petykemano #9 üzenetére

    Ezt én is tudom, a cikk írója viszont, kicsit sem részletezi ezt.
    A Technológiának is is vannak előnyei, tegyük fel itt van a MacBook AIR amiről gépelek, simán kibír egy 1x órát, ellentétben a vadi új AMD-s EliteBook-al, ami meg hogy is mondjam, nagyon szép az AMD marketingje, de nem igaz, ha csak az üzemidőt nézem meg.
    Magánvéleményem szerint az Intel ezt szeretné követni. De az AMD is rá lesz kényszerítve, mert a performance magok használatánál, az Intel kimaxolta a fogyasztási osztályokat a mobile fronton már évekkel ezelőtt, ott nem lesz túl sok újdonság a fejlesztésekben.
    És én is érzem ezen az AIR-en adott feladatoknál semmi értelme nincs a Performance magokra, mert nincs, akkor miért ne üzemelhetne inkább tovább a notebook, az Apple ezt eltalálta nagyon. Még akkor is ha LP nem pedig E magokat használnak.
    Az első lépéseket az Intel teszi meg x86-os vonalon.
    Meglátjuk mennyire lesz ennek eredménye, de ha bejött valamilyen módon az Android a komplett Apple univerzumban, lehet, hogy itt is lehet foganatja.

    A nem kliens piacon nem nagyon van még értelme, hogy kövesse, mert ott meg kell a teljesítmény, ha egy szerveren azt állítom be a power settings-ben, hogy Static High Performance Mode, akkor ott minden socket a szerverben elkezd tudni pörögni, ha szükség van arra. emellett van még 3 másik mode, amivel lehet konfigurálni a power regulatorokat. Szóval ott egyelőre én nem látom a létjogosultságát ott.
    Persze az sem mindegy, milyen szerver, most én a nagy datacenterekre értettem, ahol több ezer VM, vagy éppen több 10 000/100 000 konténer fut.

    The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

  • hallador

    addikt

    válasz Lacccca87 #8 üzenetére

    Tehát szerinted, ha van véleményem, és alapvetően nem támadok semmilyen céget, de nem azt szajkózom, amit pl sokan mások, akkor azonnal mondjuk Inteles vagyok, AMD-s EliteBook-al, meg AIR M1-el?
    Hmmmm. Érdekes.
    Igen én mindig rájövök, ha a cikkben lehet fikázni, akkor jön a troll hadsereg, ha nem akkor viszont minta gyűrűk urában a manók, eltűnnek a hely mélyében...

    The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

  • Abu85

    HÁZIGAZDA

    válasz hallador #2 üzenetére

    Az Apple M1 modellje más. Ott a két mag nagyon hasonlít egymásra, emiatt nem kell külön szoftveres háttér rá. Szóval az Apple ezt nagyon másképp csinálja, mint a többiek.

    A szerverplatformok egyáltalán nem ilyenek. Jó okkal, ott ez annyira nem lenne hasznos, mert throughput optimalizáltak. A hibrid dizájn mobil szinten hasznos, és onnan beszivároghat az asztaliba.

    A szoftveres probléma abban nyilvánul meg, hogy Androidon is úgy működnek az alkalmazások, hogy kiválasztanak egy klasztert aztán a többi magot érintetlenül hagyják. Nagyon kevés program használja ténylegesen az összes magot. Túl bonyolult.

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

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #9 üzenetére

    Az AMD megoldása az az Apple-ét másolja. Alapvetően lesznek eltérő családból származó magok egy lapkán belül, de úgy, hogy az optimalizálásukra vonatkozó követelmények megegyeznek majd, tehát a szoftver felé nem kell hibridként kezelni őket. A programozók felé így ez az egész transzparens lesz.

    [ Szerkesztve ]

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

  • pechman8

    aktív tag

    Ez szerintem logikus lépés. A különböző tempót igénylő felhasználási helyzetben, klönböző tempót pörgető mag dolgozik. Ez ha így lesz érthető...

    Saját korlátaimból nem léphetek ki, mások adottságaiba nem léphetek be.

  • Reggie0

    félisten

    válasz hallador #10 üzenetére

    ellentétben a vadi új AMD-s EliteBook-al, ami meg hogy is mondjam, nagyon szép az AMD marketingje, de nem igaz, ha csak az üzemidőt nézem meg.

    Linux alatt a 3700U procis elitebook jo ha birt 3-5 orat, feladatoktol fuggoen. (735g6).

  • hallador

    addikt

    válasz Abu85 #12 üzenetére

    Ezt leírtam válaszként a 10-esben, mint ahogyan a szerver processzorokat is.
    Ettől függetlenül is az Intel féle megoldását tartom a jövőnek, mert legalább elindultak valamerre, hogy épp az Apple vagy az Arm designja mentén, most részemről nem is érdekes, a lényeg, szvsz ezt az AMD sem fogja megúszni, ma még éppen a gyártástechnológia megmenti őket, de amint ez eltűnik, megint ott találják magukat, mint 2004-ben, ha nem kapnak gyorsan észbe. Szerintem az AMD nem hülye, ők is erre fognak elmenni, bár ezt kijelenteni 1997, 2004 és 2011 után nem biztos, hogy így lesz.

    [ Szerkesztve ]

    The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

  • Abu85

    HÁZIGAZDA

    válasz hallador #16 üzenetére

    Írtam, hogy az AMD is ugyanezt csinálja, csak azzal a különbséggel, hogy ők nem akarják azt, hogy a programozóknak törődni kelljen az eltérő optimalizálásokkal a magtípusokra, így az AMD megoldás a programozók felé transzparens lesz.

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

  • Petykemano

    veterán

    válasz hallador #10 üzenetére

    "A Technológiának is is vannak előnyei, tegyük fel itt van a MacBook AIR amiről gépelek, simán kibír egy 1x órát, ellentétben a vadi új AMD-s EliteBook-al, ami meg hogy is mondjam, nagyon szép az AMD marketingje, de nem igaz, ha csak az üzemidőt nézem meg.
    Magánvéleményem szerint az Intel ezt szeretné követni. De az AMD is rá lesz kényszerítve, mert a performance magok használatánál, az Intel kimaxolta a fogyasztási osztályokat a mobile fronton már évekkel ezelőtt, ott nem lesz túl sok újdonság a fejlesztésekben.
    És én is érzem ezen az AIR-en adott feladatoknál semmi értelme nincs a Performance magokra, mert nincs, akkor miért ne üzemelhetne inkább tovább a notebook, az Apple ezt eltalálta nagyon. Még akkor is ha LP nem pedig E magokat használnak.
    Az első lépéseket az Intel teszi meg x86-os vonalon."

    Azért itt többminden áll a háttérben és többmindenről beszélünk.
    Amikor arról van szó, hogy egy notebook mennyit bír, akkor is legalább három különböző felhasználási módot és hozzátartozó időt érdemes megkülönböztetni:
    a) idle
    amikor nem is használod a gépet, lecsukod, de bekapcsolva marad, stb. A legtöbb telefon és notebook ilyen. Ilyen méréseket nem tudom végeznek-e még. Mindenesetre a valódi LP mag ilyen üzemmód kezelésére alkalmas lehet. De megfelelő gondosság mellett jó alternatíva lehet a nagyon fejlett, nagyon részletes rész-lekapcsoló képesség. Vagy a fejlett gyártástechnológia.
    b) könnyed használat
    Böngészés, youtube-ozgatás, megkockáztatom olyan kódolás, ami nem abból áll, hogy az idő háromnegyedét kódforgatással töltöd.
    Erre kifejezetten jó az Apple megközelítése, mert magas egyszálas teljesítménnyel rendelkezik. Ugyanazt az egyszálas teljesítményt az AMD és az Intel processzorok csak úgy érik el, hogy nagyon magasra hajtják a frekvenciát, ami persze magas fogyasztást eredményez.
    c) erőteljes használat
    Amikor olyasmiket futtatsz sokat, ami erős MT igénybevételt jelent. renderelés meg ilyesmi.
    Ebben a felhasználási módban az AMD kínálata eléggé versenyképes, mert a magok frekvenciája ilyenkor már energiahatékony szintre szorul vissza.

    b) és c) esetben az LP mag nem fog segíteni.
    Az E mag c) esetben hasznos lesz majd, ha elég sok lesz belőle.

    A nem kliens piacon nem nagyon van még értelme,

    A cloudban sok esetben már most is párosával adják a magokat. (vCPU) Ennek szerintem biztonsági oka van. (valójában 1 fizikai mag két szálát adják.) De el tudnék képzelni egy olyan konstrukciót, hogy mondjuk idővel egy 6 vCPU-s konstrukciót érdemes lehet úgy kínálni, hogy az valójában 1db P magból (HT) és egy 4 magos E mag clusterből áll. És akkor végső megspóroltak kb 1 P magnyi területet.

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

  • válasz hallador #3 üzenetére

    Nincs ezzel baj, ha működik. Egyébként konkrétan mi az 9x annyi fejlesztés, amit az AMD vett át az Inteltől? Mert nekem most ilyen komoly fejlesztésekből hirtelen az integrált memóriavezérlő (és északi híd), natív többmagos dizájn, jól skálázható chiplet dizájn jut eszembe, ezekben az AMD volt az első.

    A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

  • GoldhandRent

    őstag

    nem értem (telefonoknál sem amúgy), hogy ez mikor és miért jobb, mint mondjuk 1 helyett 2 erős mag, ami ha nem kell, nem ketyeg.

    vagy megint az a cél, hogy single core teljesítményben sokat tudj(anak)unk ? :F

    -

  • fatpingvin

    őstag

    válasz GoldhandRent #20 üzenetére

    mert akármilyen hihetetlen, igen sok olyan célfeladat létezik, amihez nem kell nagy számítási teljesítmény, viszont folyamatos execution igen. és akárhogy nézem, egy nagy mag márcsak felépítéséből adódóan sem tud feltétlenül minden részegységet lekapcsolni amit nem használ. Most egy eklatáns példa jut eszembe erre: hálózati forgalom manageléséhez leginkább integer műveletek kellenek, lebegőpontos algebra nem. na most egy olyan nagy mag amiben a lebegőpontos részegység folyamatösan megy, ott hiába veszed le az órajelet, ha ez a rész üresen is fogyasztja az áramot.

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • vicze

    félisten

    válasz Abu85 #12 üzenetére

    "Androidon is úgy működnek az alkalmazások, hogy kiválasztanak egy klasztert aztán a többi magot érintetlenül hagyják. Nagyon kevés program használja ténylegesen az összes magot. Túl bonyolult."

    Már elnézést de ezt totális hülyeség. Maga az alkalmazás, azt se tudja min fut(igen van kivétel, de elég kevés), a Linux Kernel scheduler oldja meg a magok kiosztását, gyakorlatban akármennyit és akármilyent, a szoftvernek ez teljesen transzparens. DynamIQ-ban gyakorlatilag lehet 2-3-4 vagy több szint is, jelenleg egy csúcs ARM SoC-ban a 4 szint általános.
    Androidon meg aztán különösen annyi absztrakciós rétegen megy keresztül egy alkalmazás, hogy tök lényegtelen a programozói oldalról min fut, pont ez a lényege.

    [ Szerkesztve ]

  • Chiller

    őstag

    válasz GoldhandRent #20 üzenetére

    Pont hogy nem, hanem hogy multiban villoghassanak a semmire se jó tesztekben a végtelen pontszámokkal.

    Amit aztán kenhetünk a hajunkra, mert valós alkalmazásokban semmi sem lesz, ami le lesz kódolva 3 felé (magtípusok) aztán még 2 felé (hyperthreading) aztán meg még 32-64 felé (magszámok).

    Mennek bele teli gázzal a zsákutcába, mint anno a PS2 a cell magokkal.

    Engem gamerként meg különösen irritál, de ez csak magánvélemény, legyenek hülyék, amíg van helyette más, nem érdekel.

  • fatpingvin

    őstag

    válasz Chiller #23 üzenetére

    ha a PS3-ra gondolsz (abban volt a Cell), az éppen hogy egy kifejezetten jó irány volt, igazából most az Apple M1 lapkája is ezért tud ennyire energiahatékony lenni valós életben nézett felhasználáson, mert van benne egy csomó kvázi koprocesszor (a Cell lapkában ezek voltak a SPE-k) amiknek le lehet osztani viszonylag fix elemi műveletek láncából álló, de nagy számítási teljesítményt igénylő feladatokat, ahogy a Cell prociban is a SPE-k gyorsították a különféle vektor- és mátrixműveleteket, nem pedig maguk a PowerPC magok, azok aszsem csak az AltiVec lebegőpontos kiterjesztést tudták önmagukban, aztán mégis csak PS3-akból rakták össze a Condor clustert, mert a SPE-k remekül tudtak mátrixműveleteket is gyorsítani.

    a koncepciót erősen tovább is vitték, nézd meg mondjuk egy mostani csúcs x86 proci is leginkább azzal dob nagyot, hogy ki van bővítve egy csomó olyan részegységgel amik önmagukban lényegében ASIC-ek, de az utasításdekóder le tudja nekik osztani azokat a dolgokat amiket nyers erőből igencsak költséges lenne számolni (ide tartozik pl az AVX, a különböző médiakodekek, satöbbi...)

    [ Szerkesztve ]

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • GoldhandRent

    őstag

    válasz fatpingvin #21 üzenetére

    akkor egy darab LP mag az ilyen esetekre, meg 2-3-4-5 P mag, mikor használni is akarom a gépet
    kicsit mintha fordítva lenne a logika.. a kevésszer nem használásra sok gyenge mag, mikor meg kéne az erő, arra nesze neked 1 mag, meg a sok kis szar még odafingik :D

    #24fatpingvin
    telefon vonalon az ilyen esetekre van segédproci, pl a kamerának, hálózatnak
    specifikus feladatra specifikus hw (kell) illene

    [ Szerkesztve ]

    -

  • Chiller

    őstag

    válasz fatpingvin #24 üzenetére

    PS3 igen, elgépeltem, elnézést.

    Ha annyira jó lett volna, miért köpködték a fejlesztők, és miért lett kukázva? :D

    "a koncepciót erősen tovább is vitték, nézd meg mondjuk egy mostani csúcs x86 proci is leginkább azzal dob nagyot, hogy ki van bővítve egy csomó olyan részegységgel amik önmagukban lényegében ASIC-ek"
    Én az SPE-ket nem mosnám össze az utasításkészletek extra tranyóival vagy az iGPU-val de akár a HW video dekódert...

    [ Szerkesztve ]

  • Abu85

    HÁZIGAZDA

    válasz vicze #22 üzenetére

    Ez nem ennyire egyszerű. Itt nem csak a feladatok kiosztása a lényeg, hanem az, hogy egy feladat milyen magra illik. Erre vannak különböző programozási technikák az ARM részéről, illetve az Intelnél is. Az Intel kapcsán például a Hitman 3 ilyen, bizonyos kódolási feladatokat dedikáltan a kisebb magokon végez, és erre a programozó figyel a programkódban, hogy oda is kerüljön a feladat.

    Az Android esetében ennyire nincs ez elterjedve, de nem azért, mert az ARM-nak nincs rá megoldása, hanem azért, mert szarik rá a fejlesztő. Kiválaszt egy klasztert aztán a többi magot elengedi.

    [ Szerkesztve ]

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

  • sh4d0w

    nagyúr

    LOGOUT blog

    Szerintem a notepad.exe elindításához elég lesz beépíteni egy 6502-es CPU magot.

    https://www.coreinfinity.tech

  • vicze

    félisten

    válasz Abu85 #27 üzenetére

    Én csak Androidról beszélek, és konkrétan nincs olyan, hogy kiválaszt egy klasztert, mert nem látja, transzparens a programnak és a kernel dönti el, hogy hol min fut.
    Egyszerűen nem igaz, hogy a fejlesztő bármit választhat.
    Még a Snapdragon Power Optimization SDK -ban is ennyi van semmi más:
    Snapdragon Power Optimization SDK exposes two main modes through its API that allow developers to control power efficiency:
    “static mode”: controls the performance/power balance based on the current state of the application. This mode offers a number of flavors such as Window Mode, which configures the minimum and maximum frequency percentages that cores can use.
    “dynamic mode”: adjusts the core usage and frequencies through a feedback loop that self-regulates the system to a desired throughput metric.

    Alap Android API-ban nincsen semmilyen lehetőség clusteret választani, ami hülyeség is lenne, hisz nem tudod hány van és milyen fajta mert minden SoC esetében más-más, ráadásul idővel változik.
    NDK-val lehet optimalizálni, de még ott is elég véges a valós kontroll.

    Még egyszer akár 4db különböző teljesítményű "cluster" is lehet SoC függvényében, jó pár éve már nem kicsi és nagy között lehet csak választani.

  • KISDUCK

    addikt

    válasz Chiller #26 üzenetére

    Én úgy emlékszek hogy a sony azért dobta a cellt mert nehezebb volt a programozása és a 4. konzol generáció előtt meg megkérdezték a fejlesztőket hogy mit szeretnének és így jött az amd megoldása.

  • freeapro

    senior tag

    Csak egy kérdés: az ARM-ben a gyors magok általában out-of-order, a lassabb energiatakarékos magok in-order módon működnek. Egy program szerintem "csak úgy" nem váltogathat a kettő között, mert másképp kell fordítani őket. Ez Androidon nem probléma, mert egy köztes réteg van az HW (vagy OS?) és a programod között. De PC-n ez a köztes réteg hiányzik. Ez nem egy elvi akadály a PC-s little.big koncepciónak? Vagy nem jár túl nagy teljesítmény veszteséggel, ha mindent csak inorder módon fordíthatsz?

  • Kansas

    addikt

    válasz KISDUCK #30 üzenetére

    Plusz konzolok esetében az akkus üzemidő nem rémlik, hogy kritikus pont lenne... ;] (nyilván a kézikonzolok kivételével...de azoknak a használati profilja se épp a notikra/mobilokra hajaz)
    Cserébe tele vannak olyan fixfunkciós egységekkel amik 3-4-8 általános célú CPU-magot kiváltanak pl az audio, a lemezkezelés és a textúra-tömörítés kapcsán...

    Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.

  • Reggie0

    félisten

    válasz freeapro #31 üzenetére

    Szerintem egy out-of-order-re optimalizalt kodot in-order procin is sikeresen lehet futtatni, legfeljebb hatekonysagot veszithet, de nem fog hibazni.

  • Chiller

    őstag

    válasz KISDUCK #30 üzenetére

    És pont ezzel indítottam a #23-ban :DDD

    Ez a mostani helyzet nyilván annyiban különbözik, hogy a power magokból is van elég, és gondolom van olyan felhasználás, ahol elég a LP/E mag...

    Csak akkor minek a sok LP/E mag, a P magok elfelejtettek multitaskolni? :)

    Persze a körte meg az alma, meg legyünk energia hatékonyak vágom. Jól fognak mutatni ezek a procik a 600+ wattos VGA-k mellett :DDD

    Bocsánat, ez már demagógia. Vannak olyan helyzetek, ahol ezeknek van értelmük, én sem tagadom. Amíg két kattintással kikapcsolhatók, nem is érdekel, olyan mint az intel iGP.

    [ Szerkesztve ]

  • proci985

    MODERÁTOR

    válasz fatpingvin #21 üzenetére

    itt a fo problema az az, hogy az Intel keptelen target fogyasztas mellett eleg magot berakni, marketingen meg jol hangzik az a 16 core (HTvel egyutt 24), mint a 8 vagy 10. a 12900Knal erre kellett ez a felepites, mert se egy szalon, se tobb szalon nem versenykepes continous load helyzetben, hacsak nem tol a felhasznalo ala egy 300+Wra meretezett alaplapot 600 euros custom looppal (igaz ugy meg a TCO szall el, de lehet performance crownra mutogatni). viszont teszteken meg lehet mutogatni az alacsony idle CPU fogyasztast, ami mondjuk konnektorbol mar mindjart nem lesz olyan jo ertek (VRMen nagyobb veszteseg, pumpa + harom venti meg fogyaszt).

    anno q6600nal csinaltam teszteket, ott kb 8-12W koruli desktop es 15W koruli "notepad" jott ki, igaz 35-45W koruli full load mellett (default clock, alulfeszelve kb 30%al mert ott volt meg stabil). es ott volt konkretan ket CPU state (fix FSB mellett szorzot tudott valtani 6 es 9 kozott az osszes magra), ket darab voltage szint mellett. azota eltelt 15 ev, van sok p state, magokat gyakorlatilag altatni is lehet. ami kell is, mert para lenne, ha mondjuk egy 5950X uresben enne 30-50Wot.

    littlebig ott kritikus, ha minden egyes W szamit (ld snapdragon 865 vs 865+ vs 888 vs 1, az elso kivetelevel az osszes tulmelegszik es a 888 gyakorlatilag egy OC modell volt). high-end desktopon ez annyira nem kritikus mert a karacsonyfanyi vezerlot az alaplapon etetni is kell, szervernel use-case fuggo. magaban az X570 pl 10Wal tobbet fogyaszt egy X370/X470nel, ez kb egy fullra terhelt snapdragon 8 gen 1 osszehasonlitaskeppen.

    PS3 az egy kicsit mas megoldas volt, ugyan szinten aszinkron architekturaval, viszont ott volt egy dedikalt utemezo mag es egy clusternyi worker. ez a megoldas ugyan egyszerusiti az oprendszer felepiteset, de nem skalazodik.

    Don't dream it, be it. // Lagom amount.

  • koby11h

    aktív tag

    Majd veszünk megint AMD-t.

    Ha volna sonkánk, akkor csinálhatnánk sonkás tojást, ha lenne tojásunk!

  • Abu85

    HÁZIGAZDA

    válasz vicze #29 üzenetére

    Az Android is csak egy OS. És nem is az Android választja ki ezt, hanem a programban van lehetőség arra, hogy ezt megtedd. Képzeld mennyire zord világ lenne, ha nem tudnád megcsinálni. A grafikus parancskezelés random mehetne a leggyorsabb és a leglassabb mag között bármin. Durván méretes lagokat produkálnának ezek az állapotváltások. Ergo van lehetőség arra, hogy egy feladattal dedikáltan lehessen célozni egy kijelölt magot, vagy akár egy klasztert.

    A Snapdragon esetében ezt a HetCompute SDK szolgálja, amit natív Android appba lehet integrálni. De van az ARM-nak is ilyenje, tehát nem kell ám gyártóspecifikust használni, csak nyilván a gyártóspecifikus valamivel hatékonyabb lehet. Ezzel az SDK-val úgynevezett "hint-eket" adhatsz az OS-nek arra, hogy melyik feladatot hova helyezze, és ebbe beletartozik az is, hogy mindent megpróbálsz egy kiválasztott klaszterre rakni, mert marhára nincs pénzed azt leoptimalizálni, hogy minden mag jól működjön az alkalmazásod alatt. Ezért választják a fejlesztők jellemzően ezt a módszert. Egyszerű, olcsó kivitelezhető, és a tesztelhetősége hasonló a PC-s dizájnokhoz.

    A Power Optimization SDK az más, ugyanis az nem biztosít lehetőséget arra, hogy megpróbáld kontrollálni azt, hogy melyik feladat melyik magon fusson le.

    Az alap Android API-ban nincs is. Ez a baj. Erre vannak a kiegészítő SDK-t, például a HetCompute, ha mindenképpen a Snapdragont szeretnéd példának. Egyébként maga a HetCompute is jóval több annál, mint pusztán a heterogén többmagos dizájnt kezelhetővé tenni a programozó számára, mert hozzá lehet nyúlni a Snapdragon egyéb részegységeihez is, de ez most mellékes.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz freeapro #31 üzenetére

    Androidon is probléma ez. Csak azért nem látszik annak, mert a fejlesztők többsége szarik rá, és hozzá sem ér az alkalmazás az egyik magcsoporthoz. A hardver itt nem tud csodát tenni. Képes az OS kiosztani a feladatokat, de nem tudja ezt megtenni optimálisan, így a program oldaláról ezt "hint-ekkel" irányítani kell. Ebből a szempontból nem különbözik az, amit mondjuk a Hitman 3 csinál az Alder Lake-S-re attól, amit egyébként meg lehetne tenni Androidon is, ha nem szarnának bele a fejlesztők. Egyértelmű eseteket egyébként már az OS el tud dönteni a hardverből származó adatok alapján, de sajnos van nem kevés kevésbé egyértelmű helyzet is. Ahhoz mindig is programoldali segítség fog kelleni.

    [ Szerkesztve ]

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

  • vicze

    félisten

    válasz Abu85 #38 üzenetére

    Most már nagyon mellébeszélés megy....

    "Androidon is úgy működnek az alkalmazások, hogy kiválasztanak egy klasztert aztán a többi magot érintetlenül hagyják"
    Ez az állításod, és ez nagyon nem igaz, mert az alkalmazások nagyon kis töredéke működik így, ahol a fejlesztő külön megírta NDK-val a magok kezelését. Ráadásul nagy eséllyel csak specifikus SoC-okon működik így, ha működik egyáltalán.

    "És nem is az Android választja ki ezt, hanem a programban van lehetőség arra, hogy ezt megtedd"
    Továbbra se igaz!

    HetCompute SDK, egy compute SDK és CPU, GPU, DSP heterogén programozására van elsősorban, az hogy magtípust(csak big és little) lehet megcélozni egy mellékes dolog benne, és Android NDK-val integrálható, nem az SDK-val.
    Ráadásul a HetCompute SDK elavult 2019 óta nem lett frissítve, így nem támogatja a DynamicIQ-t és csak Big és Little-t lehet vele célozni. Semmivel nem működik 845 felett.

    "amit natív Android appba lehet integrálni"
    Megint csak ami kizárólag bizonyos Snapdagonokon működik...
    Egész ráadásaként még egyszer ez Compute-ra van nem általános programokra...

    Egyszóval az Androidon nem lehet alapból megválasztani, hogy min fusson egy program, csak ha valaki ezt külön implementálja az NDK-val. A fejlesztők nem szarnak rá, hanem iszonyatosan nagy munka minden egyes SoC-ra külön optimalizálni minden programot, gyakorlatban lehetetlen.

    [ Szerkesztve ]

  • Abu85

    HÁZIGAZDA

    válasz vicze #40 üzenetére

    Csak egy picit gondolj bele, hogy mi történne, ha nem lehetne "hint-ekkel" rábírni a rendszert, hogy egy célzott magra rakja rá az adott feladatot. Például a játékoknál ott a parancsfeldolgozás, ami OpenGL ES alatt egyszálú. Tehát elindítod a játékot, az OS pedig kiválasztja neki a leglassabb magot. olyan CPU-limited lenne, mint a ház, mert neked a leggyorsabb mag kellene erre a feladatra. De állításod szerint ezt nem tudod megtenni, az OS feletted dönt. A te leírásoddal random dobálná az OS az alkalmazás teljesítményét indításonként.

    A Vulkan ugye explicit párhuzamos, tehát ott még nagyobb gond lenne az, hogy a fejlesztőnek nincs beleszólása, hiszen egyrészt a parancsok nem fix hosszúságúak, az OS nem tudja előre, hogy melyik parancs mekkora batch-et tartalmaz. Ezt még maga a program sem feltétlenül tudja, akkor lesz róla tudomása, miután kiosztásra került a feladat a magra. Ellenben tud következtetni abból, hogy egy adott munkafolyamatra a múltban milyen batch-méretek voltak alkalmazva, és eszerint van az optimalizálás is. Ha úgy működne az Android, ahogy te vázolod fel, akkor egy Vulkan program tele lenne akadással, mert a magok eltérő teljesítményét folyamatosan megfogná a shader újrafordítás, ugyanis ez kiosztásra kerülhet a leggyorsabb magokra, illetve a leglassabbakra is. Gyakorlatilag másodperces lagok lennének az alkalmazásokban, attól függően, hogy a szerencsefaktor mit intézett a sorstól. :)

    Szerencsére van mód a kontrollra, az más kérdés, hogy a többség így is leszarja, mert nehéz eldönteni, hogy minek lesz rossza kis mag, és minek lesz jó. Ennek az egyszerű megoldása az, hogy a kis magokhoz ne is nyúljon hozzá az alkalmazás. Akkor nagy baj nem lehet. Mély tisztelet a kivételnek, aki jól megcsinálja.

    [ Szerkesztve ]

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

  • vicze

    félisten

    válasz Abu85 #41 üzenetére

    "A te leírásoddal random dobálná az OS az alkalmazás teljesítményét indításonként."
    Ez ugye nagyon nem igaz. Az OS tudja, hogy az adott alakaszás magasabb igényű, így elve oda rakja ahova kell. Nincs semmiféle dobálás. Az OS schedulernek vannak alkalmazás profiljai, és a profil alapján az OS a megfelelő teljesítményt adja indítástól.
    Ezért lehet profilozási benchmark cheatekről olvasni...

    Másrészt a DynamicIQ-nak az egyik alapvető lényege, hogy szinte nincs megszakítás magváltások között, legalábbis semmi ami érzékelhető lenne. Mivel teljesítmény igény alapján teljesen dinamikus a magkiosztás. Nem big.Littile van, hanem domainek, akármennyi domain. Azonos magok is lehetnek más domainek pl. más órajellel. Lehet 8db A55-öd 2db 2,5GHz, 2db 2GHz és 4db 1,6Ghz, hiába ugyanazok a magok mégis más teljesítmény szintek más domainek.

    Az egész neten kb. semmilyen információ nincs arról amit írsz, konkrétan 0.

    big.Little bevezetésekor se kellett újraírni semmit, tök ugyanúgy futottak a programok mint előtte, DynamicIQ-nál se kellett semmit csinálni. Nem kell újraforgatni a programokat minden egyes SoC-ra és sorolhatnám vételenségig. Teljesen non-sense amit állítasz.

    [ Szerkesztve ]

  • Abu85

    HÁZIGAZDA

    válasz vicze #42 üzenetére

    Az OS-nek fogalma sincs arról, hogy egy grafikai parancs milyen igényű. Ez csak akkor derül ki, amikor a batch látszik, de akkor meg már késő. Arról sincs fogalma, hogy kell-e shader újrafordítás, ez ugyanis a folyamat elindítása után derül ki, nem pedig előtte.

    Mármint papíron megfelelő teljesítményt, de vannak olyan problémák, amik csak akkor derülnek ki, amikor már elindult a munkamenet. Akkor ez a módszer nem elég jó, tehát a programnak jó lenne megmondania előre, hogy kellhet-e nagyobb teljesítmény.

    Nem az a gond, hogy nem lehet dinamikus magkiosztást csinálni, hanem az, hogy nem egy feladat van, főleg grafikus motoroknál, ahol túl későn derül ki, hogy mekkora teljesítményigénye van egy feladatnak. Ha ez nem lenne gond, akkor a Hitman 3 sem lenne úgy optimalizálva, hogy a motor dedikáltan célozza az egyes munkafolyamatokkal az egyes magokat (például úgy van megírva a grafikus parancskreálás, hogy grafikai parancsot csak nagy mag dolgozhat fel, ezzel szemben tartalomkódolást csak kis mag, stb.), és ugyanígy kellene eljárni az ARM-os rendszerek esetében is, csak Androidon nincs akkor pénz, hogy erre időt szakítson bárki is. Androidon például az is megoldhatatlan feladatnak, hogy tök szabványos textúraszűrést hiba nélkül megcsináljon az IGP. Tiszta bugok a gyártói Vulkan implementációk, ezernyi sebből vérzik a teljes szoftveres háttér, szóval kb. pont leszarják, hogy egy valami rossz magon fut, mert legalább fut, ezernyi más hibával szemben, amelyek nem is futnak jól/hibátlanul.

    [ Szerkesztve ]

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

  • vicze

    félisten

    válasz Abu85 #43 üzenetére

    Mutatnál egyetlen egy guide-ot Androidhoz vagy bármilyen bejegyzést ahol bármilyen nemű CPU profileingot csinálnak ahol bármilyen formában figyelembe veszik a CPU domaineket? :U

  • Reggie0

    félisten

    válasz Abu85 #43 üzenetére

    Nem lehetetlen NDK-val megcsinalni, de az Android alapbol nem igy megy. Az OS scheduler donti el a futas kozbeni parameterek alapjan, hogy melyik thread milyen magot kap (es azt is, hogy mi legyen a mag frekije), az app pedig azt se tudja, hogy processzoron fut-e, vagy egy kinai szamolja kockas fuzetben.

    "Mármint papíron megfelelő teljesítményt, de vannak olyan problémák, amik csak akkor derülnek ki, amikor már elindult a munkamenet. "
    A futo threadnek tud domaint valtani. A dinamikus frekvenciaallitas is igy megy, nem a threadek vagy a program mondjak meg, hogy na most nekem x MHz kell.
    DinamIQ-nal pont emiatt vittek arra az iranyt, hogy a big es little magok parban vannak es osztott a memoriajuk, hogy ne az interconnect-et terhelje, mint a hagyomagyos big.little eseten.

    [ Szerkesztve ]

  • Abu85

    HÁZIGAZDA

    válasz Reggie0 #45 üzenetére

    És ezért csinál nagy hülyeséget az Android, hogy ezt alapból nem engedik flagelni, hanem szükségesek hozzá a gyártói segítség. Az Intel nem véletlenül rakta bele az új procijaiba a CPUID Hybrid Function Table-t. Ez két flaget jelent: Hybrid Flag és Core Type. Tehát a fejlesztőnek konkrét látképe lesz arról, hogy mit tartalmaz a hardver. Ez az extra adat azért fontos, mert előre meg tudják majd határozni, hogy az adott processzorra érdemes-e irányítani a szálkiosztást. A SetThreadIdealProcessorral ez kijelölhető, noha az Intel is mondja, hogy garancia arra nincs, hogy tényleg arra osztja rá az OS a szálat, amit a program kijelöl, de megpróbálja, és azért sokszor sikerül is jó helyre kiosztani a feladatot, ami nagyon fontos annak érdekében, hogy ne legyen az egész játékélmény dadogós.

    Az ARM esetében is meg lehetne ugyanezt csinálni gyárilag (a flagek ott vannak), mert nem véletlenül van benne az Intel dizájnjában. Ha nem lenne szükség rá, akkor nyilván nem lenne az Intelnél sem használható, de sajnos szükség van rá, mert az OS ütemezője az nem jósgömb és nem is csodatevő. Az, hogy az Android azt hiszi, hogy az, elég nagy gond az egész ökoszisztémára nézve. Nyilván nem véletlenül van ennyire lemaradva az iOS mögött a high performance címek tekintetében.

    [ Szerkesztve ]

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

  • proci985

    MODERÁTOR

    válasz Abu85 #47 üzenetére

    Androidnal nem kap minden app egy sajat virtualis gepet? Regebben ez igy volt, ugy meg kb a design egyik kozponti eleme volt, hogy nemi interfacingon keresztul az egyszerubb fejlesztes cel volt, direkt hozzaferes a hardverhez meg sose, mert kb ugyse lehet minden piacon levo eszkozre optimizalni. ez nem a 80as evek, hogy van 2-3 CPU generacio amit tamogatni kell. ld amit Reggie0 is ir a #49ben, bar az o leirasa sokkal explicitebb :R

    JVMben vagyok inkabb otthon, Androidra utoljara par eve fejlesztettem. Android elejen viszont gyakorlatilag egy masszivan kiegeszitett Java volt. Kotlin is fut JVM kornyezetben.

    Reggie0: valos ontanulo profilozas validacio szempontjabol remalom kategoria, hacsak nem egy multiqueue round-robinrol beszelunk par extra lepessel.

    modern utemezok tenyleg iszonyatosan bonyolultak tudnak lenni, a lokalis hotspotok elegge megkavartak az eddig se egyszeru feladatot.

    [ Szerkesztve ]

    Don't dream it, be it. // Lagom amount.

  • Reggie0

    félisten

    válasz Abu85 #47 üzenetére

    Szerintem nehez megmondani, hogy mi legyen a flageles, mivel annyifele proci van, hogy elegge horror lenne. Szerintem a ontanulo profilozas kell a schedulerbe(azaz el is menti a tapasztalatait, nem csak futasidoben hasznalja) es par glitch utan mar felismerheti a problemas appokat es azok taskjait.

    De a dynamiq igazabol arra viszi az iranyt, hogy a domain switch olyan gyorsan tortenjen meg, hogy ne legyen gond ezt menet kozben intezni.

    Aztan a masik erdekes temakor, ami az light appoknal erdekes igazan, az az energy aware scheduling. Itt mar nem csak a processzor tipusatol fugg az eredmeny, hanem a szilicium-lotto-tol is, ezt meg nehezebb lenne elore flagelni.

    Az apple-nek az az elonye, hogy van kb 5-10 proci tipus ami parhuzamosan letezik es supportalt, ugy nem nehez megoldani. Foleg, hogy a dinamiq elhozta a magonkent frekiallitas lehetoseget(alap big.little eseten domainenkent lehetett).

    [ Szerkesztve ]

  • Kansas

    addikt

    válasz proci985 #48 üzenetére

    "nemi interfacingon keresztul" - hja, minden a szexről szól, így vagy úgy... ;]
    Ezért kell magyarul írni, ha már magyarul írsz... ;)

    Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.

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