Ú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
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
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
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
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: LPA 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
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
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.
-
hallador
addikt
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
Í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
"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..
-
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 ?
-
-
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
"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
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#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?
"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
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.
-
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
É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.
-
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
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.
-
Chiller
őstag
És pont ezzel indítottam a #23-ban
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
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 ]
-
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
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
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
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
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
"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
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.
-
Reggie0
félisten
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
É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.
-
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
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
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
"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.
-
Dr. Akula
nagyúr
Ha sok Celeron meg Atom magot zsúfolnának még bele a fullos magok kárára, akkor mégnagyobb lehetne a parasztvakítás faktor, hogy nézd mennyi magja van...
-
icp1970
senior tag
Szerintem jó út a hibrid vonal.12 .gen,igen jól sikerült, nem vitás.
-
fatpingvin
őstag
válasz Dr. Akula #51 üzenetére
ez is csak azon múlik, hogy a célfeladat mit követel meg. ha van változatosság a piacon, felőlem lehet olyan dizájn is hogy van benne 12 Atom mag meg két HT-képes, bikább Core. vicces módon simán el tudom képzelni hogy ez hova férne el.
[ Szerkesztve ]
A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
Ribi
nagyúr
Szerintem fogyasztást power magokkal is meg lehetne oldani soookal jobban.
Most is miközben netezek a proci állandóan fel fel boostol, 15-20Wot is beszippantva amikor 1 ablakot megnyitok. Viszont power save módban 2.2GHz-en marad és pont olyan gyorsan nyílik meg az ablak, csak közben 5Wal ugrik csak meg a fogyi. Szóval a mostani magokkal is sokat lehetne sprórolni ha rendesen kezelnék. Nem kell 2-3 féle mag, hogy keveset fogyasszon. Csak nem kellene állandóan a szart is kitaposni a magokból ha kell ha nem.
Csak a szokásos dolog megy, 0 SW optimalizálás, majd eladunk HW fejlesztést ami meg kell venni, mert az mindenkinek jobban megéri.[ Szerkesztve ]
-
Ribi
nagyúr
Nem úgy gondoltam, hogy ténylegesen jobban, hanem sokkal közelebb egy powersave maghoz. Mert most ordas fosul van megoldva a power magok kezelése. Ha power save módban megy a win, akkor kb soha nem emeli a frekit, bármi más módban meg állandóan küldi a magokat ameddig feszből bírja.
[ Szerkesztve ]
-
hallador
addikt
53 év alatt? Elég sokat szerintem, Nem az elmúlt 10 évre gondoltam, hanem az elmúlt 53-ra.
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]
-
Kansas
addikt
Szerinted, vagy valami forrásod/bizonyítékod is van? A "biztos úgy van" az nem elég...
#59Gyok2: ezeknek kb. a fele: 64-bit, APU, Raja... AMD-től ment Intel irányba... az L3 cache nem épp nagy fejlesztés... csak egy újabb cache level L2 utá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.
-
hokuszpk
nagyúr
-
-
Kansas
addikt
Nem, az ékezetek hiányáról volt szó, de mindegy is...
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.
-
Egon
nagyúr
Elég végiggondolni a kezdeti éveket. 386-ig konkrétan minden CPUI Intel klón volt, egy az egyben másolat (a 486-os éra elején is). Aztán Slot1 -> Slot A, majd a visszatérés a jelenleg is használt foglalattípusokhoz. A CPU sapkázása (lesarkazni csak a P3-akat tudtad, a P4-eket már nem; ellenben az akkori AMD-ket még igen).
Ez csak annyi, amennyi séróból megy, biztos lehetne még találni egy párat."Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)
-
Kansas
addikt
Nem "klónozták" az Intel CPU-kat, hanem gyártották őket, mert az IBM-nek szüksége volt egy második beszerzési forrásra a PC procik kapcsán, nem akarták hogy az Intel "single point of failure" legyen. Tehát akkoriban ha nem az AMD gyártotta volna őket, akkor vagy más, vagy az IBM nem az Inteltől vette volna a CPU-it.
Keress rá a "second sourcing"-ra, ha érdekel.Akkor kezdték el az AMD-nél revers engineering használatával koppintani a procikat, mikor az Intel szerződést szegve abbahagyta a tervek átadását. Innentől viszont nem ritkán ugyanaz a termék AMD kiadásban jobb volt, mint az azonos modellszámú Intel(nekem volt AMD 486DX4/100-am ami 10-15%-ot vert az Intel párjára)
A két cég nem lenne ott egymás nélkül, ahol ma van, és ez pozitív és negatív értelemben is érvényes kijelentés.
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.
-
hallador
addikt
Pár példa kellene, akkor kezd el összehasonlítani, csak azt, hogy a foglalatokat ki fejlesztette 1997-ig, mert nem az AMD, de az utasításkészletekkel mi a helyzet? Máig mennyit is implementált magától az AMD? 3DNow? Ja igen kb semmit nem jelentett.
A Szerver fejlesztések 90 %-át az Intel vitte, az AMD, meg átvette, vagy licencelte. Az utóbbi 5 évben sikerült saját fejlesztéseket is implementálni, igaz az az Intel találta ki, az AMD továbbfejlesztette. Ha meg nem így képzelted el, akkor menjél bele jobban a technológiákba, nagyon hamar rájössz, hogy az AMD nem sok mindent talált ki itt sem ami 2 - 3 évnél tovább élt volna.
Nagyon érdekes, hogy szerinted az AMD majdnem mindig rávert az intelre, ehhez képest minden esetben az AMD kullogott az intel után hogyan lehet ez szerinted, ha nem csak úgy, hogy az intel előrébb járt?
Egyedül az utolsó 5 évben nem így van, egyelőre, bár érdekes módon nem jelentetek meg abban a topikban, ahol kiderült, hogy az AMD-nek rosszul sikerült ezt ezt lemásolni.Persze veled ellentétben, én tudok mondani kettő olyan technológiát ahol az egyiket sikeresen licencelte az AMD, ez a NUMA node implementálása x86-ra, és az összes hozzá tartozó technológia, azt sem ők találták ki, hanem igazából a DEC. A másik ami nekik köszönhető, a x86-64.
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]
-
KROK640
veterán
"hanem lesz egy kis teljesítményű magokból álló klaszter (akár kétféle paraméterezéssel), míg a nagyobb teljesítményű opciók tekintetében a legújabb magból maximum egy-kettő kerülne beépítésre, a többi pedig az előző generációból származó tempós mag felújítása lenne, amolyan közepes teljesítményű alternatívaként." - ember legyen aki majd követni tudja, hogy akkor most hány szálas, hány magos és milyen sebességű az adott proci.
Inkább azt kérdezzék miért nincs szobrom, mint azt, hogy miért van...
-
Full offtopic, de azért: x64 az AMD-é, nem 5, hanem 15 éve; x86 integrált memóriavezérlő megvan? Mantle, amiből aztán elég sok egyéb grafikus alrendszer lett? Nem mellesleg azért érdemes lenne megjegyezned, hogy 2/3/486 - mindegyikből az AMD csinálta a leggyorsabbat.
Mindig jössz ezzel marhasággal, ami 1000x bebizonyosodott, hogy legjobb esetben kamu, legrosszabban bruttó hazugság.
https://www.coreinfinity.tech
-
Dr. Akula
nagyúr
Az is, meg hogy ha kell, mit tudsz megcsinálni vele. Nem nagyon értem ezt a 8-10 gyök 2-es mag + 1-2 komolyabb mag felállást, én valahogy úgy látom, hogy a lowcost mag akkor kell, ha nem kell terhelni a procit, de abból meg minek ennyi? Ha már 8 magra van szükség, akkor esélyes hogy a nagyágyút kéne inkább beröffenteni. Tehát inkább fordított, kevés lowcost, sok performance mag felállásra szavaznék. Gondolom az Intel is, ha bírná a lemaradt gyártástechnológiája a magszám versenyt az AMD-vel, és azért csak a lowcost magokat tömi, hogy legalább a marketingesek rányomhassák a "nem vagyunk ám lemaradva, ugyanannyi magunk van mint a konkurrenciának" plecsnit. Ha már erre futja a gyártástechnológiából, akkor inkább kevesebb mag legyen, de abból több a performance.
-
Reggie0
félisten
válasz Dr. Akula #69 üzenetére
Sok a low cost task. Fogyasztasilag sokkal jobb sok kis magra szetszorni oket, mint egy nagy magon futtatni. Illetve ez igaz a nagyon jol parhuzamosithato feladatokra is, jobb sok kicsin szetszorni, mint par nagyon futtatni. Az eros mag ketfele tasknak kell: amelyikkel minel elobb kell vegezni vagy amelyik rosszul parhuzamosithato.
[ Szerkesztve ]
-
ShiTmano
aktív tag
A chiplet designt is izzadva próbálja lemásolni az Intel. Talán majd jövőre...(ML) 3D V Cache nem tudom mikor lesz nekik. PCI-E 4 is előbb volt AMD-nél. Sajnos az AMD egyéb fejlesztései ritkán terjedtek el, de csak a mérete miatt. Századrésze volt az Intelnek. Most viszont már tényező. Utolsó pénzügyi jelentésben már csak 5-ször annyi volt az Intel bevétele (ha jól emlékszem). Xilinxszel a markában már sokkal komolyabban veszik. Meglátjuk, hogy alakul, de az AMD már nemcsak porszem a sivatagban.
[ Szerkesztve ]
"Ilyen dolog ez, folyamatos növekedés, egy állandó méretű bolygón :D Rip rendszer..." by Crim
-
fatpingvin
őstag
azért a PCIe 4.0 implementációját annyira ne tapsoljuk, POWER vason évekkel korábban volt már. 2016-ban már volt a piacon PCIe 4.0 képes desktop alaplap, a Talos II.
A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
Kansas
addikt
válasz fatpingvin #72 üzenetére
Nem azt írta, hogy náluk volt először, hanem azt, hogy előbb.
Gondolom, a Talos II széles réteg számára elérhető és megfizethető termékként komoly eladásokkal büszkélkedhet... POWER vas előfordulási gyakorisága meg adatközpontokon(ld. IBM i-Series) kívül a fehér hollóéval vetekedik, különösen a lakosság körében, de KKV-knál se jellemző...
Még ha amit írsz technikailag igaz is, a jelentősége nem valami nagy.
OK, a PCIe v4 jelentősége összességében se világrengető(inkább inkrementális), leginkább gyors de drága SSD-k és agyonvágott(x8, x4 sávos) videokártyák kapcsán hallottunk róla a legtöbben, a mainstream jelentősége még mindig korlátozott, pedig már az Intel és is támogatja.
A fórumtárs leglényegesebb/legérvényesebb érve az hogy számos esetben azért az Intel megoldásai terjedtek el és/vagy váltak szabvánnyá, mert az Intel jelentősen nagyobb cég volt, úgy a tőzsdén, mint eladott darabszámban. Az AMD-féle Fusion is gyaníthatóan szebb karriert futott volna be, ha a méretviszonyok fordítottak(nem, nem konkrét termékekre gondolok, mint a joggal fikázott Bulldozer széria, hanem az alapötletre).
Hogy a méret- és piaci viszonyok miért úgy alakultak, ahogy, nem fogom n+1-edszer is részletezni vagy linkelni, akit kicsit is érdekel, az tudja/tudhatja, de nem azért, mert az AMD ne lett volna eléggé innovatív.[ Szerkesztve ]
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.
-
hallador
addikt
Persze veled ellentétben, én tudok mondani kettő olyan technológiát ahol az egyiket sikeresen licencelte az AMD, ez a NUMA node implementálása x86-ra, és az összes hozzá tartozó technológia, azt sem ők találták ki, hanem igazából a DEC. A másik ami nekik köszönhető, a x86-64.
Nem sikerült elolvasni az utolsó bekezdést ugye? Nagyon okosnak gondolod magad? Akkor miért nem sikerült értelmezned a NUMA node fogalmát? Te szoftveres ember vagy, és ez nagyon is jól látszódik, azt nem értem, hogy miért okoskodsz bele valamibe amihez nincs háttered?
Na mutass meg hol állítottam, olyat, hogy az X86-64 első implementációja nem 2003-ban jelent meg? Még a bekezdés is más ember, nem zavar?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]
-
"...Nagyon érdekes, hogy szerinted az AMD majdnem mindig rávert az intelre, ehhez képest minden esetben az AMD kullogott az intel után hogyan lehet ez szerinted, ha nem csak úgy, hogy az intel előrébb járt?
Egyedül az utolsó 5 évben nem így van..."Te nagyon okos, a fenti mondatok implikálják, hogy véleményed szerint az AMD az utóbbi 5 évben kezdett el fejleszteni, tehát ha nem akarod, hogy félreértsenek, húzd ki a fejed a német s.ggekből és tanulj meg újra magyarul, hardveres szaki.
https://www.coreinfinity.tech
-
Abu85
HÁZIGAZDA
-
vicze
félisten
"nem lehetetlen NDK-val megcsinálni" nem éppen azonos azzal, hogy "Androidon is úgy működnek az alkalmazások, hogy kiválasztanak egy klasztert" és az egyéb rengeteg mellébeszélés és információ amit leírtál egyáltalán nem igazak.
Abban se vagyok teljesen biztos hogy DynamicIQ esetében lehetséges-e bármilyen célzott mag kiválasztás, pusztán abból adódóan, hogy nincs sok értelme, mert bármilyen lassulás pár pillanatra lenne csak érzékelhető(ez még alkalmazás indításkor), amíg a folyamat nem kerül az erősebb magra.
Nem találkoztam semmilyen gyártói dokumentációval, SDK-val vagy úgy általánosan bármivel, ami ezt lehetővé tenné, és te se tudtál semmit se linkelni erre.
Szóval lehet hogy 4éve lehetett big.Little-lel, de elég könnyen meglehet hogy DynamicIQ-val már nem lehet. De ha lehet is mivel specifikusan kell SoC-okra ezt megírni, 0 esélyt látok rá, hogy bármelyik fejlesztő foglalkozna ezzel bármilyen formában, egy ennyire fragmentálódott platformon. Azt is erősen kétlem, hogy valaha foglakozott volna ezzel bárki, amíg big.Little volt, ugyanazért.Tehát azt állítások, hogy az alkalmazások bármit is választanának hamisak, ahogy az is, hogy az OS nem csinál "semmit" az teljesítmény igény meghatározáshoz, mert gyakorlatban csak az OS dönti el Androidon.
-
Abu85
HÁZIGAZDA
A Big.Little esetében is hintekkel dolgoztak a fejlesztők, és ugyanúgy lehet hintet alkalmazni bármilyen rendszerre. Nagyon is hasznos dolog ez, mert ugye borzasztó akadásokat kapnának a játékosok, ha az OS csak úgy rárakná a parancskreálást a kis magra úgy, hogy közben legalább tíz parancsot batch-el az adott csomag. Gyakorlatilag fél másodpercig megállna a feldolgozás. Aztán hiába korrigálja magát, hogy megy vissza a nagy magra a szál, a baj már megtörtént. Az Intel nem véletlenül vezette be a flagelést, mert nyilván ez náluk is ugyanolyan probléma, mint az ARM-nál, és ezt az okozza, hogy az egyik mag látványosan kisebb teljesítményű a másiknál.
Ha ezt pusztán az OS-re bíznák, akkor az elég nagy gondokat okozna, mert az OS-nek se jósgömbje nincs, hogy pontosan lássa mi lesz, és időgépe sincs, hogy a rossz döntéseket visszacsinálja. Egyedül és kizárólag a fejlesztők tudnak tenni azért, hogy ne legyen egy lagfest a program. Persze az Android már önmagában egy akkora szarlavina, hogy komoly játék nem érkezik rá, de technológiailag lehetséges lenne.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
vicze
félisten
"Big.Little esetében is hintekkel dolgoztak a fejlesztők"
Azon kívül hogy ezt te kitaláltad, az ég világon egyetlen egy bizonyítékot nem tudsz erre mutatni...Biztos IKS-el is volt hint mi? GTS csak 2016-2017 környékén tejedt el a gyártók körében.
Tényleg nem ártana egy kicsit utánajárj az egész big.Little és DynamicIQ vs. Linux kernel témakörnek. Linaro anyagokat ajánlom. Energy aware scheduling-nek se ártana utánaolvasni."ugyanúgy lehet hintet alkalmazni bármilyen rendszerre"
Totál hülyeség, mikor gyártó SDK specifikus..."Gyakorlatilag fél másodpercig megállna a feldolgozás"
A nagyotmondást lehet még hova fokozni?[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Ugyanilyen hintekkel dolgozik a Qualcomm HetCompute SDK.
Próbáld ki mekkora akadást eredményez egy tíz parancsból álló batch, ami nem a nagy magon fut le. Az Unreal Engine Vulkan leképezőjével sok ilyen szituációt tudsz majd tesztelni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
vicze
félisten
Még egyszer Qualcomm HetCompute SDK elavult és nem működik újabb SoC-okon, ezenkívül 2018-ban lett kiadva, és 2019-ben már jött a DynamicIQ és el is avult. Elődleges feladata pedig a CPU/GPU/DSP heterogén programozása volt. Biztos sokan használták...
És csak egy gyártó a fene tudja hány Android SoC gyártó közül.
Azt is leírtam, hogy mikkel kéne tisztában lenni hozzá.Hol van ez a Unreal best practice leírva pontosan?
Van egy elméleted, ami egyszerűen nem igaz és képtelen vagy beismerni...
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
A HetCompute a hint-ekre egészen egyszerű módszert használt. Annak megvan az utódja.
Most belinkeltél egy 2017 májusában írt dokumentumot miközben maga a motor Androidon a Vulkan API-t 2018-ban véglegesítette. Szó sem volt akkoriban arról a problémáról, hogy az explicit parancsgenerálása a Vulkan API-nak rossz magra rakhat a parancskreálást, mert akkoriban az OpenGL ES egy szem magon futott, és nem volt skálázható. A skálázás nagyjából másfél éve jelent gondot, mivel elég sokat fejlődött ahhoz az UE4, hogy default explicit párhuzamos legyen ultramobilon a leképező skálázása (töltsd le a legújabb motorverziót, és nézd meg, hogy így van már beállítva). Mert ugye 2020 előtt hiába volt maga az API explicit párhuzamos, a default működés egy szálra volt korlátozva Androidon a motorban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Reggie0
félisten
Pont az ellenkezoje van leirva:
"You can set Android N to permanently run the processor at lower clock speeds, reducing battery drain.
Android N has a sustained performance mode API that is guaranteed to run indefinitely at a lower performance level. While a fast peak performance is attainable on mobile, you cannot sustain it indefinitely due to heat and battery drain concerns."Amugy logikus, ha ki tudja a fejleszto optimalizalni a kodot alacsony fogyasztashoz, akkor a proci teljesitmeny ingadozas sem fog problemat okozni, mert onnan csak felfele tud ingadozni. Egy atlag telo meg a waze-tol is elizzik, nagyobb teljesitmenyt igenylo jateknal garantalt a trottyling, legfeljebb nehany gamingre optimalizalt es nem is tul szeles korben elterjedt telefont vagy tablet leszamitva.
[ Szerkesztve ]
-
vicze
félisten
"Annak megvan az utódja."
Aha, Unicorn amit senki se látott...De vagy 100x-ra ez csak is kizárólag pár Snapdragon SoC-ot érint és semmi mást...
És megint a mellébeszélés...
A Vulkan maszlag meg borzasztó fárasztó, úgy hogy a 2 kezemben meg tudom számolni a játékokat, amik Vulkan-t használnak...Köszönöm a linkeket...
[ Szerkesztve ]
-
hallador
addikt
Elmeséled, hogy megint miért hagytad ki az utolsó bekezdést? Ember, te csak kötekedni jöttél, hiába, na nagyon jól látszódik, ha nincs is igazad, akkor is kötekedés éltet. Szerinted ebből még meg lehet élni? Úgy tűnik igen...
Csak tisztázzuk mi az a NUMA node gyakorlatban, mikor jelent meg, és mi a célja? Ha ezt megértetted volna, nem irkálnál butaságokat, de jól látszódik, hogy te már csak okoskodni jársz ide nem értesz hozzá. Ha tudnád ez mit jelent..... Inkább maradtál volna csendben.
húzd ki a fejed a német s.ggekből
Kicsit sem vagy primitív....Ha nem tudsz mit írni, akkor már csak ez jut, abból is látszódik, hogy mennyit ér a tudásod, hogy csak ennyit tudsz hozzátenni szakmailag.
És mielőtt előjönnél azzal, hogy személyeskedem, nem! Nem téged minősítettelek, hanem a tudásodat.
[ 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]
-
Reggie0
félisten
"Nem mellesleg azért érdemes lenne megjegyezned, hogy 2/3/486 - mindegyikből az AMD csinálta a leggyorsabbat."
Miert lenne erdemes? Ezt az AMD mindossze pl. a 286-os proci inditasa utan 7 evvel erte el, addigra mar reg a 386-os ment az intel reszerol. Es ez sem a szuper AMD-s tervezoknek koszonheto, hanem annak, hogy az intel kezdetben 1500 majd 1000 nanometeren gyartott, mig az AMD a nagy kesese utan rogton 800 nm-en inditotta a gyartast. Azaz az eltelt ido technologiai fejlodeset vitte be, nem a csodalatos processzoroptimalizalo kepesseguk.
De a 386-osbol is a release utan 6 evvel tudta kihozni az AMD a 40 megas verziot, addigra mar 2 eves volt a 486.E
[ Szerkesztve ]