Új hozzászólás Aktív témák
-
#12
fatpingvin
őstag
dokanin
#11
fatpingvin
őstag
"ki a fene akarna olyan desktop procit venni, amiben 8 gyenge mag is van?"
én, kérem szépen. nekem számít a fogyasztás mert szünetmentes tápról mennie kell a cuccnak, emellett sokkal érdekesebb scheduling megoldásokat lehet összerakni egy ilyen procival.
arról nem is beszélve hogy mondjuk ha lenne egy olyan ami 2 gyenge és 8 erősebb mag, király virtualizációs cucc lenne: a hipervizor rohangál a két kicsi magon, a többin meg a vendég rendszerek.
szerintem ennek a megoldásnak abszolút van létjogosultsága, csak kérdés hogy mennyire csapnak le rá szoftverfejlesztési szintenA tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
opr
veterán
Üresjárati fogyasztás zseniális lehet. Ok, desktopon ez annyira nem fontos, majdhogynem mindegy, hogy 2w vagy 10w, de laptopoknál nagyon jól jöhet.
Én inkább attól félek kicsit, hogy a fejlesztők nem úgy fogják használni, mint kéne, hanem megint mindennél fontosabb lesz, hogy gyorsan a piacon legyen a program, és vagy le se szarják, vagy beállítják, hogy fusson az egész a gyors magokon, az a biztos és kész.
Meglátjuk, továbbra is tartom, amit fentebb írtam, eleinte valszeg lesz vele gond, de aztán akár valami nagyon jó is kisülhet a dologból."Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
opr
veterán
Vannak olyan gépek illetve helyzetek, amikor nagyon sokat számít az üresjárati fogyasztás, amikor viszont kell a kakaó, akkor kell a kakaó.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
Fücsök007
őstag
Elsősorban az OEM-ek miatt (másodsorban a hatékonyság növelése miatt) hozták létre ezt a koncepciót majd terméket. 1 gépnél nem számít pár W megtakarítás, de több száz vagy akár több ezres OEM gépparkoknál sokat spórolhatnak a villanyszámlán. AMD-nél a teljesítményért feláldozták az idle/kis terhelésű fogyasztást, ami így sem rossz, de sok gépnél már nem versenyképes. Arról már nem is beszélve, hogy 1-1 háttérfolyamat ha elindul egy adott nagy magon, akkor a régi adatokat törli a gyorsítótárból a mag, és nem tudja folytatni a régi adatokkal a félbehagyott munkafolyamatot, aztán később ezen adatokat a memóriából kell visszamásolni. Erre tökéletes több alacsony fogyasztású, kisebb teljesítményű mag, így mindegy milyen program fut, mindig alkalmazkodnak a magok hozzá. (Az más kérdés, hogy mennyi idő alatt írnak hozzá jó szoftvert, de a koncepció jó.) Azon programok, amelyek kihasználnak 20-30 magot, ott a kis magok hatékonyabbak mint negyed annyi erős mag HT-vel.
[ Szerkesztve ]
-
#26
fatpingvin
őstag
dokanin
#16
fatpingvin
őstag
nyilván nem erről a konkrét modellről beszélek, sokkal inkább a koncepcióról hogy van pár kisebb meg több nagyobb magod és tudsz köztük feladatokat leosztani, ahogy ez ARM-en már egy ideje van.
ennél már csak a heterogén utasításkészlet lenne mókásabb. nekem mondjuk nagyon tetszene egy vegyes x86-ARM/POWER/SPARC proci, x86 magok mehetnek egy virtuális gépnek, a normálisabbak meg a hipervizor alá.A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
opr
veterán
-
sb
veterán
Amiért nem veszel 16 hengeres autót otthonra? Pedig pályanapra évente 1x jó lenne.
Vagy amiért lekapcsol 4 henger a 8-ból?Amiről te írsz a brute force megoldás. Ami igazából nem is megoldás semmire mert ilyen alapon még több erős mag még jobb. 8 helyett 16 jobb, ahelyett a 32 és a 64 MÉG jobb.
De a valóságban van olyan, hogy optimum ill. más paraméterek... és általában 10-ból 9.5 ember arra törekszik.Visszakanyarodva a fenti példára, ezért nem jár senki napi szinten Ferrarival... mert erős, de kicsi a csomagtartója.... meg traktorral se, mert annyi "csomag" meg nem kell és nehezen parkol.
@opr:
A Ryzenek pl. amivel nagyon sok teljesítményt nyernek: IF, magas frekik, nagy ramfreki az idle fogyasztást is jó 20-25W-tal megdobják. Az mivel hw-s megoldás nem lehet kikerülni de ettől közel sem optimális és számít.Nem 2 vs 10W hanem 25W (4650G) vs 45-55W (3600) nálam.
Persze a legegyszerűbb úton kell spórolni először. Ha sok az idle=nincs szükség a gépre akkor minek menjen? Ez is lefelezi az átlagfogyasztást de itt jön be a többi paraméter ami szintén számít, főleg ha csak használni szeretné vki kényelmesen az eszközt.Régen elvoltunk 2 perces boot idővel is... ma már nem. A 10-15mp még belefér, de igazából (ultra)mobil OS-ekről megérkezve már ennyit se bírnak az emberek. Ha a fentit nézem: sokat eszik de kilövöm akkor valóban sokkal kényelmetlenebb 10mp is, mint a megnyomom a gombot és ott a felület.
Intelnél úgy van connected standby is egy ideje amivel az utlramobil platformoknak ezt a részét próbálják utolérni. Ha kikapcsolod nem jön meg az üzenet sem pedig ez is elég alap elvárás manapság. Ahogy az is, hogy az ultramobilt ki sem kapcsolod. Előhúzod és máris tudod használni. Cserébe mégis 4 napig online ha nem használod.Ezek olyanok amiket egy átlaguser néz. És szerintem nincs is eltévedve ha ez számít neki.
Megérkezik a mail és csipog. Miért ne jöhetne ez asztalra is, nemcsak a zsebbe? Előveszi és máris ott van. Valamit meg akar nézni, a telefonért, tabletért nyúl mert megy. Felveszi és ha nincs kikapcsolva akkor nincs lemerülve sem, mint az x86 notija...Ezek tök hétköznapi események és emellé az x86-os rendszerek olyan mintha a tárcsázós telefont kéne előkapni a hátizsákból.
Szerintem szükséges irány, főleg most amikor nem 2-4 magokról beszélünk x86-on hanem 8-16-32-ről.
Jó is az irány mert nem az agyatlan brute force megoldás. Hw-s oldalról nem is lehetséges sok esetben.
Hogy mennyire egyszerű az más kérdés... nyilván nem az mert sw oldali támogatás kell. Ami pedig bonyolult és drága. Innen jön szerintem dokanin nézőpontja is.
És ez igaz is. De meg kell lépni ha erre akarunk fejlődni. Ára az lesz. Ez van.[ Szerkesztve ]
-
sb
veterán
De mi a csúcskategória? 64 mag?
Oda valóban felesleges...Vagy már 6-8-12 mag mellé sem kell?
Most 6-8 notikat tudsz venni 1000 EUR körül amik letolják teljesítményben az 5 évvel ezelőtti desktopot kb. 3x. Oda elkelne pl...De amúgy szerintem a teljes mainstreambe mehet. Ahol kell a kraft a legritkább esetben kell mindig. Max a renderfarmon meg a bányában van így. A többi helyre - átlagfelhasználóknak - meg ez a kombó a megfelelő.
Fentebb próbáltam fejtegetni, hogy miért. Senkinek a gépe nem ketyeg 0/24-ben úgy, hogy közben 50W-ot bezabál idle. Az elég necces lenne.
Ha viszont ketyeghetne mert az 50W-ból 5W lesz akkor miért ne? Onnantól online van mindig. Notira még inkább igaz. Most olyan határon belül használjuk amin belül kevésbé látszik szükségesnek de épp azért mert ezen belül vizsgálod.Notikon se lehetett anno érdemben játszani vagy normális, erős konfigot használni bármihez. Ma meg lehet. Innentől változnak a keretek is.
-
Fücsök007
őstag
Nincs igazad, mert maximum 10 magos proci lehetne az Alder Lake, a Raptor Lake meg 12 magos, helyette kapsz sok magot 3,5-4GHz körüli órajellel és kb. Skylake IPC-vel. Egyébként a win11-nél debütáló DirectStore PC-n 4 magot elvesz ha direktre portolják konzolról, mert nincs dedikált gyorstó az asztali gépeken, plusz ugyanúgy fog kelleni hozzá gyors NVME SSD. Ezen játékok 2022 előtt nem fognak megjelenni, de azokhoz már 10 mag kevés lesz, még 12 maggal is necces, mindez háttérfolyamatok nélkül értendő.
-
opr
veterán
Hat, igazabol attol fugg. Ha elterjed a megoldas es olyan programot irsz, ahol a teljesitmeny szamit, viszont van sok olyan szal, aminek nem kell sok kraft de muszaj folyamatosan futnia, akkor azzal, hogy kipakolod ezeket dedikaltan a kis magokra nyerhetsz a masik oldalon nemi teljesitmenyt. Pl jatekoknal a hang siman mehet az egyik kisebb magon, vagy mondjuk ilyen videovago/kepszerkeszto szoftverek is ilyenek tudnak lenni, ahol az esetek 90%-ban eleg egy atom is, viszont amihez kell kraft, ott nagyon kell.
Az En problemam inkabb az, hogy nem latom, hogy tudna versenyezni egy arban valoszinuleg hasonlo helyre belott, 16 eros magos, 32 szalas SMT-s Zen 4-el. Az egyetlen, ahol erzem a dolog elonyet az az olyan irodai kornyezet, ahol valamiert annyira sok az uresjarati munka aranya a nagy teljesitmenyigenyuhoz kepest, hogy jobb valasztas egy ilyen, viszont a nagy teljesitmenyigenyu munka olyan, hogy lokalisan kell futnia valamiert.Szoval, van ebben racio, csak desktopnal eleg pici a piac, ahol ertelme van.
Mobil vonalon viszont nagyot uthet a dolog, laptopokban -ha a hattertamogatas megfelelo OS es szoftver oldalrol is- akar forradalmi is lehet. Ezert nem is ertem, hogy miert ennyire a desktopot nyomja az intel, miert nem a mobil megfelelojet.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
opr
veterán
Uresjarati energiafogyasztas.
COVID altal megsegitett pelda: Iroda, ahol van 300 desktop gep, es az uj rendszer az, hogy otthonrol remote desktopolnak a nepek laptoprol az esetek 90%-ban, tehat a desktopok kb soha nincsenek kikapcsolva. Ilyenkor olyan szintu megtakaritas lehet, ha az uresjarati fogyasztasa a teljes rendszernek akar csak gepenkent 5W-al kevesebb, hogy mar megerheti.De amugy egyetertek veled, nekem is erolkodni kell, hogy ertelmes peldat tudjak desktop vonalon mondani.
Baszki, rajottem miert desktop vonalon nyomjak!
Szerintem azert csinaljak, mert eselytelen, hogy barhogy mashogy legalabb papiron felvegyek a versenyt nemhogy a kovetkezo, de mar a jelenlegi AMD desktop csuccsal. Igy meg lehet irni a marketingre, hogy naluk is 16 mag van, meg lobogtatni azt a harom benchmarkot, amiben 2%-al nyernek, plusz az uresjarati fogyasztast (a teljes terheles alatti fogyasztasrol meg hallgatni, mint a sir). Plusz mivel a TDP az gyakorlatilag egy rolling average, mivel az uresjarati fogyasztas lemegy, es az ido nagy reszeben az a jelentosebb, igy amikor kell, lehet tolni a 200+ wattokat a masik 8 magnak max egy percig, es meg mindig ra lehet irni a dobozra, hogy 16 mag, Qrva eros, 65W TDP-vel! A sok hulye meg meg fogja kajalni.
Ok, most valszeg nekem fog esni a nep, de En ezt latom bele a dologba desktop vonalon azon felul, hogy tenyleg lehet olyan piaci res, ahol van ertelme. Mobil vonalon tovabbra is jo otletnek tartom, ami akar nagyot is mehet, ha rendesen meg van csinalva es tamogatva is van."Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
opr
veterán
Nem is téged kell érdekeljen, hanem a főnöködet.
Intel valószínű fizetni fog a megfelelő cégeknek, hogy támogatva legyen a cucc, lehessen mutogatni jó kis fogyasztási adatokat, mert érzik, hogy muszájkell."Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
ricsi99
addikt
-
sb
veterán
Diverzifikálni lehet de a probléma általános és elvi.
- Ha lesz hetegorén felépítés akkor arra kell/érdemes optimalizálni sw oldalról mert bizonyos felhasználási sávokban (én úgy gondolom, hogy az átlaghasználat 99%-ában) és hasznos lesz és ez alapján választhat simán a user gépet.
- Ha viszont ez megtörténik attól még lehet szegmens (szerintem szűk) ahova ezt nem érdemes elvinni, ebben igazad van. De ha már van akkor miért ne?Ez ott érdekes ahol nem ér semmit a fogyasztás optimalizálása az pedig szerintem csak az a réteg ahol konstans nagy terhelést adsz vagy nincs is igazán szükséged gépre (mert soha nincs terhelve). Tehát még önmagában a csúcskategória sem határozza meg.
Utóbbira csak kis mag is elég lenne.
Előbbinél meg mi marad? Renderfarm? Ahol nincs full terhelés, akár szerver oldalon ott is számít a fogyasztás, nagyon is. Sok gép, sok cpu, az üzemeltetési költség a nagyobb nem a beszerzési. Változó load mellett simán lehet optimálisabb jóval egy ilyen felépítés.Persze szerver oldalon általában feladatra terveznek, így nincs annyira eltérő feladat/terhelés. Ha van akkor eleve rohadt bonyolult a menedzsment, sw oldal. Tehát ott meg drága lehet. Drágább mint amit nyernek vele. De haszna ott is lenne elvben.
-
Robitrix
senior tag
pedig egyértelműen szükség van egy hibrid proci esetében a programfejlesztők együttműködésére a hatékonyság jegyében. Elvégre ki más tudná megbecsülni egy program kódban futó procedúrák és szálak teljesítmény igényét, mint az, aki írja a programot. Egy programozónak azért illik elképzelésének lenni, hogy a programjának melyik része mennyi CPU-t igényel. A legtöbb programban párhuzamosan futó szálak erősen eltérő teljesítmény igénnyel rendelkeznek. Lesz olyan program ág, ami szinte végig fut mivel ő a fő vezérlő ág, amiből aztán alkalom és esemény vezérelten indulnak más párhuzamos programágak. lehet egyik szálnak 5 trillió számítást kell elvégezni. a másik program ág elindul 5-ször és végre fog hajtani alkalmanként mondjuk 100 ezer utasítást. A józan logika azt diktálja, hogy ha lehet az 5 trillió számítást végző programág a lehetőségek szerint találkozzon össze a leghatékonyabb maggal. mig az 5-ször 100 ezer utasitást elvégző program ág nos ráér a lassabb magon futni. Persze azért itt hatalmas együttmüködésre nem kell számítani. Elég volna annyi hogy mondjuk a programozó egyfajta fordítási direktivával minősítené a programjának a szálait. Lenne egy alacsony egy átlagos és egy magas jelzés. Aztán ez valahogy érvényesülne a gépi kodban és ez alapján tudná a rendszer, hogy egy futtatndó process akkor most kicsi, átlago vagy nagy teljesítmény igényű. Aztán ennek függvényében igyekezne neki megfelelő magon futást biztosítani. A kérdés, hogy mi motiválná az együttműködésre a programozót és ne állítsa be a programjának össze ágára a magas minősítést. Hát alapvetően a saját jól felfogott érdeke. Egy program egyáltalán nem biztos, hogy adott pillanatban egyedül fog futni egy CPU-n. Lesznek mellette más konkurens folyamatok, amíg szintén versengenek a egy adott procimag 1-1 időszeletéért. Minnél több idő szeletet kap egy programág annál többet futhat a procin. Ha sok process vár egy mag időszeletére, akkor kevés időszeletet fog kapni a gyors magon az adott nagy teljesítményű folyamat. Így lassan fog futni. Hiszen egy procimag időszeleteinek száma korlátozott nem lehet korlátlanul osztogatni. Annyit lehet szétosztani, amennyi van. Vagyis előállhat a sok az eszkimó, de kevés a fóka helyzet. Ha lesznek eszkimók, akik beérik fóka helyett hallal is(lassabb proci mag) akkor csökken a tolakodás a fókák(gyors magok) iránt és 1-1 eszkimónak több szelet fókahús jut. Kérdés persze, hogy mennyire engedem a rendszernek, hogy ha nem jut a fókára éhes eszkimóknak elég fóka szelet akkor mennyire engedem meg, hogy párat átirányítok mégis halat enni hiába van fókára bejelentett igénye. Kérdés mikor járok el optimálisabban ha várok a kevés leeső fóka darabra vagy közben nasizom a halból is mikor nem jut fóka.
Ezért minden képen hatékonyabb ha maga a programozó minösíto a saját programjának a szálait, hiszen ha ő nem akkor kitudja minek mennyit kell adni. A másik lehetőség egyfajta statisztika készítés a futó proceseknek, melyik hányszor és hány időszeletben fut és mennyi az átlagos órajel és egyebek, majd ennek a statisztikai minősítés alapján tudja a rendszer, hogy milyen procest hová kell rakni futni. A hajtsuk kia a belünket magra vagy az ejjjjj ráérünk arra még magra. A dolog hátránya, hogy kell némi futás ahhoz, hogy valamiféle statisztika kialakuljon. A másik, hogy minden statisztikai adat már egy megtört esemény alapján készül. Vagyis a múlt adataiból táplálkozik. Attól, hogy egy process mondjuk az elmúlt 3 másodperceben gyakran és sokat futott egy CPU magon egyáltalán nem következik, hogy a következő 1 percben is sokat fog futni. Sok programnál egy programág futást valami véletlen esemény vagy egy konkrét esemény bekövetkezése váltja ki. Például egy játékprogram esetében Elöre teljesen eldönthetetlen, hogy mondjuk egy játékos mit fog cselekedni. tűzet nyit egy megjelenő ellenségre vagy fogja magát és nyúl cipöt köt és menekül. A játékos cselekdete más jövendő beli kódot fog aktiválni a jövőben. Persze egy játék program tele van véletlen eseményekkel. Mondjuk rálő az egyik tank a másikra a WOT-ban. A lövésnek van egy véletlen(RNG összetevője is) ami alapján lehet, hogy átüti a lövedék az ellenséges tank páncélját vagy lepattan róla, mint a bumeráng. Néha a papir tankot se üti be a lövés egy akkora ágyúból, mint egy hegy máskor meg a papírtank ágyúja mégis csak betalál a hegynyi monstrumba és telibe nyomja a lőszerrekeszt... Már pedig találatot kapni a lőszerrekszbe minden tankos szituba rossz ómennek számít. Vagyis operációs rendszer szinten a múlt adatai alapján elég bizonytalan felvázolni a lehetséges jövöt egy program folymatainak igénye szempontjából. Így mégis csak a programozó becslése lehet a legtöbb haszonnal kecsegtető a kiindulási adat. ki tudja, ha nem ő. Amúgy ma is bele lehet avatkozni prioritás szintján a programok futásának. ehhez csak annyi kell, hogy egy futó processnek egyszerüen magasabb prioritást adjak a feladatkezelőben.[ Szerkesztve ]
-
sb
veterán
Ez user oldalról kell érkezzen.
Nyilván ultramobil a jó példa és te nem ebben gondolkodsz. Írtam, hogy ott mekkora gáz volt a battery drain és mekkora divat lett a diagnosztikai program ami nézi mi mennyit eszik a háttérben. Innentől pedig a userek szavaztak a pénztárcájukkal. A naptár progi meg időjárás widget ami megette az akksidat ment a kukába.De desktopban gondolkodsz és csakis high perf alkalmazásokban, de ez szerintem férlevisz.
Egyrészt a "desktop" teljesítmény lejött már rég mobil vonalra. Én is most gondolkodom el, hogy miért van 2700/3600/4650G-m ha alig használom néha az erejét egy kis vidókódolásra. Más játszik de arra is elég bőven jelenleg mind. És ez pár éve nem ment bele egy noti házba de ma bedobsz egy 5600/5800-at és ha nem is 15W, de 28-35-45W-ból 90%-ban ugyanazt hozza.
Átlagra nézve meg talán 99%.
De ehhez az kell, hogy ne a full kraftra és 7/24 100%-os terhelésre optimalizálva gondolkodjuk amiből te kiindulsz.Egyébként az ultramobil is fejlődött az meg lassan a régi noti szint. Erre haladunk és ha ez működik mindenki a telefont kapja elő, notit visz ha mindenre jó. Később esetleg már csak telefont és dokkol.
Sw oldalról pedig szintén más az átlagelvárás. Már írtam korábban, nem fejtem ki bővebben de az, hogy kell néha kraft és 8-16 magot is meg tudok hajtani attól még 99%-ban a többi határozza meg a mindennapi munkát: online gép, bejövő üzenetek, háttérben futó appok, widgetek, levelezés, stb... Ha ezt mind ráereszted akkor terhelésed is lesz. Feleslegesen, nagy magokon.
Nem véletlen, hogy az x86(+Win) közel sem ez a felhasználás még ma se és nem is nagyon menne rajta. Ebben az ultramobil sokkal előrébb tart.
Ha sw oldalról sikerül felnőni és ehhez jön a hw oldali támogatás akkor lehet egyáltalán cél, hogy ebbe az irányba lépjen el a fejlesztés. Akkor meg ezzel tudsz érdemi sw-t írni, nem a régi rendszer szerint: power gomb, boot, hatalmas os betöltődik és még mindent külön elindítasz, bezársz. -
Robitrix
senior tag
Nekem 81 folyamat fut adott pillanatban 1150 szállal. Ami nem azt jelenti, hogy adott pillanatban fut is 1150 szál inkább csak zt, hogy a futó 81 folymatban benne van a 1150 szál. Simán elképzelhető, hogy el se fog indulni, mert úgy alakulnak a program eseményei, hogy nem lesz aktiv. Minden esetre jól látszik, hogy mekkora kunkurencia harc zajlik a proci magok és szálak 1-1 időszeletének megszerzése érdekében. Nekem jelen pillanatban egy régebbi 4 magos Intel I5-ös proci működik. Ha mondjuk egy procimagra másodpercente 50 időszeletet oszt ki a erőforrás ütemező az akkor azt jelenti hogy egy másodperc alatt 200 időszeletből kell gazdálkodni. Ha van folyamatban a 1150-ből mondjuk 412 szál, ami ténylegesen futni szeretne, akkor azért akadna gond. Mivel 200 időszeletet kell másodpercente 412 helyre kiosztani. Ráadásul a rendszer folyamatok előnyt és prioritást élveznek többnyire a felhasználó folyamatok szálaival szemben. Pont ez a tülekedés az időszeletekért teszi érdeklté a programozot. Ha minden programot úgy kzel a rendszer, hogy annak minden szálának a legerősebb magon kell futni, akkor még nagyobb a tülekedés az erősebb procimagok időmorzsáiért. És akkor előjön a kefés a fóka, de sok az eszkimó esete. Pont ezért érdekelt a programozó abban, hogy olyan program szálakat , amelyek nos nem kívánnak magas teljesítményt kisebb igényűnek minősítsen had fussanak a kisebb teljesítményű magokon és ne teremtsen konkurenciát a saját nagy teljesítményű szálainak. Ha rázavar egy gyors mag néhány időszeletére egy kis számítás igényű program részletet azzal a saját nagy teljesítményt igényló program részei elöl is elveszi a lehetőség egy részét a futásra. Tehát szerintem érdekelt a programozó abban, hogy a megfelelő irányba és magfele terlje a programának a a szálait. Úgy kell elképzelni a dolgot, hogy mondjuk vizet kell hordani vödörben a kútról. Van 50 vízhordó és van 30 darab 20 literes vödör. Nyilván nem fog jutni minden vízhordónak 20 literes vödör lesznek akiknek várakozni kell, hogy a következő fordulóban átvehessen egy 20 literes vödröt. Viszont ha van 20 darab 10 literes vödröm és azt mondom a lusta teszetosza bandának, hogy rendben akinek éppen nem jut a 20 literes vödörből az ragadjon meg egy 10 literes vödröt és hozzon azzal egy vödörnyi vizet. hiszen elhordott vízmennyiség tekintetében elörébb leszek, mint ha ott ácsorognak és trécselnek várva a 20 literes vödörre.
Hiszen neki azt mondták, hogy elbirja a 20 literes vödröt. Ráadásul esetünkben a vizhordás vezetője elöre eldönti ki az a satnya vízhordó, aki eleve csak a 10 literes vödör való ki az erősebb, akinek megy a 20 literes vödör emelgetése. Ráadásul a CPU tekintetében bonyolult a dolog, hiszen meg van szabva szálasított proci esetében, hogy adott pillanatban melyik program szálai használhatnak együtt közösen egy mag két szálát. Tudtommal a közös gyorsítótár miatt nem keveredhet adott pillanatban két külön program két szála. Na ezt az amúgy nem egyszerű vezérlési feladatot komplikálja meg az, hogy az rendszer erőforrás ütemezőjének még azt is figyelembe kell majd venni, hogy melyik program szálat melyik magon optimális futatni a teljesítmény miatt. Csöppet se irigylem azt, akinek irni kell egy hatékonyabb erőforrás ütemezőt a rendszerhez, hogy kihasználja a hibrid procit. Igaziból úgy egyéve már történt egy kisérlet egy olyan intel procival, ami 5 magos volt. rendelkezett egy spcibb gyors maggal és 4 sima maggal. Kiderült a jelenlegi rendszerekben pusztán a statisztikai szórás okán valósul meg az, hogy a sok számítást igénylő folymat összetalálkozik a gyors maggal vagy nem. tehát nem elég hatékony. Vélhetően pont ezért is volt sürgös a win 11 kiadása, hogy hatékonyabb legyen egy hibrid proci kezelése. -
Robitrix
senior tag
Ez igaz a mai fordító programok az általam irt végül is teljesen egyszálas programból is simán csinál akár 3-4 szálas programot is. Külön választva az objektum orientált programokban a bizonyos folyamatokat. Ha öszinte akarok lenni végül is gözöm sincsen mi a francot rak még bele az én programomba a fejlesztő rendszer és a fordító program. Teli rakja olyan objektumokkal amiket én nem is akarok használni. Ezért lesz egy olyan hagyományos egyszerű programból, mint töröld le a képernyőt, majd ird ki, hogy "Hello world!" és program vége utasítás(már ahol van).
aztán lefordítom valami interaktív objektív orientált fejlesztő nyelven és lesz belőle 5 megás exe program... Pusztán azért, mert a képernyő törlés folyamata bele van ágyazva egy komplex tulajdonképpen sok részből álló program szubrutin gyűjteménybe. Régen ezt a feladatot meg lehetett oldani egy 25-35 bájtos COM programmal. Pusztán attól, hogy ma bele teszek pár windows vezérlő elemet, mondjuk egy kiirást vagy egy program vége gombot egy ablakba máris millió objektumot és az amúgy felesleges objektumok rengeteg propertyvel és az objektumokba ágyazott soha nem használt metódusokkal. Szóval szerintem nincsen programozó, aki pontosan tudja mia faszt csinál pontosan a programja azokon a részeken kívül amit ő maga ír meg. Az biztos, hogy kényelmes a programozás és univerzális nem kiván speciális munkát. de hogy a kapott kód mennyiben hatékony az más kérdés. -
Robitrix
senior tag
Amúgy ha megnézed kicsit alaposabban mondjuk az androidos telefonokat akkor ugye ott is egyfajta hibrid proci müködik mondjuk 4 lassabb és 4 gyorsabb maggal. Viszont azt is látni egy rendesebb proci figyelő applikációval, hog bizony béna fax módon együtt kezeli mindig a 4-4 magnak a teljesítmény. Együtt mozdulnak a 4 mag teljesítménye és órajele. Mindig ugyan azt a órajelet felvéve. Ráadásul mindig ugyan azt a néhány értéket használja.
-
Robitrix
senior tag
Mint feljebb kifejtettem a egy X86-os procin sokkal dinamikusabban és rugalmasabban zajlik a magok osztás a futó folyamatok részére. Vélhetően a hibrid procik kezelése is ügyesebben fog zajlani X86 esetében és windowsban, mint az ARM és az android esetében. Ez utobbi szemmel láthatóan fapadosabb megoldás. Nem véletlen azért, hogy bár kisérleteznek ARM procira épülő szerverekkel, de amikor igazán oda kell tenni a rugalmaságot és teljesítményt, akkor simán jól elmaradnak az ARM-os rendszerek eaz X86-os megoldásoktól, mikor sok magon és szálon kell egyszere több száz proccest futtatni sok ezer szál társaságában. Nagyjából az van amit valamelyik régi humorista(valami orosz törve a magyart) mondogatott.. "Valami van, de nem az igazi!!!!"
-
Robitrix
senior tag
Ennek az lehet az oka, hogy maga a fordító program talán beéri 5(jelen esetben 5 szál) magnyi teljesítménnyel. Erre az okos erőforrás ütemező a fogja mondjuk az első mag egyik szálát, a másik szálát és fogja a 4-es mag 1-es és 2-es szálát ezzel már akkor fut egy időszeletnyit 2 magon 4 szál. aztán valahová el akarja rakni futni az 5. szálat. Igen ám de mondjuk adott esetben nem talál olyan magot, ahol szabad mind a két szál. Egy gépben azért adott pillanatban sok tucat folyamat fut akár több száz szállal. (vagy akár több ezerrel) Viszont nem fogja a forditás 5. szálát összerakni egy magon egy másik alkalmazás másik szálával. Lévén, hogy a közös gyorsítótárba ne keveredjenek az eltérő alkalmazások adatai és programutasításai. Mivel adott pilanatban nincsen neki olyan mag, ahol van két szabad szál. Közben persze futnak a párhuzamosan az rendszer és más alkalmazások folymatai, amik szintén magokat és szálakat igényelnek. Na puff neki nem tudom rátenni egy szabad mag egyik szálára az 5. szálat hát dráma nincsen akkor az 5 szál ki fog hagyni egy időszeltnyi futást. Ismét teljesitmény veszteség. A vége az a dolognak, hogy a 2 magon futó 4 szál persze nem 4 magnyi teljesítményt ad, hanem kb. 2*160%-ot néha meg akár 140-150%-ot ad csak vagyis simán lehet, hogy csak 2,6 magnyi 4 mag helyett a teljesítmény. Ha eehez hozzá jön az adott pillanatban nem elinduló 5. szál simán megkapod szálasított procin a 9 másodpercnyi veszteséget. A szálasításnak amúgy akkor van értelme, ha sok magra van szükségünk. de persze mindig olcsóbb olyan procit gyártani, amiben bizonyos logikai és aritmetikai részek meg vannak duplázva a magban és a regiszter készlet is dupla. A gyorsitótárakból viszont egy van. Olcsóbb és egyszerűbb lesz a proci mintha minden magból teljes értékű van benne. A 8 mag 16 szálas proci egyszerűbb és kevesebb transziztorból, kondenzátorból kapuáramkörből és hasonlókból áll, mint egy 16 teljes értékű magot tartalmazó proci. Gyakorlatilag egy olcsóbb egyszerűbb kivitellel szimuláljuk, mintha nekünk egy dupla annyi magos procink volna. A 8 magos proci teljesítménye mondjuk 800%(nem teljesen igaz de elvben hagyjuk rá) a 8/16-os proci meg megfelel nagyjából 12-13 magnyi teljesítménynek. Már pedig az 1300% több, mint a 800% De ez a hatás csak akkor évényesül ha olyan program fut a procin, ami belecsap a lecsóban és használja a minnél nagyobb mag és szál számot. Ezért is értelmetlen játékokat futatni nagy teljesítményű procikon és úgy mérni a teljesítmény. Mondjuk egy 12/24-es 3900X/5900X vagy egy 16/32-es 3950x/5950X Aztán csodálkoznak hogy a háromszor annyiba kerülő procin se igazán gyorsabb a dolog. Tök hasonlóan fut rajta a 4 magot igénylő játék. Persze azért számít az egymagon nyujtott teljesitmény.
-
sb
veterán
Te még mindig olyan paradigmákból indulsz ki amiről nem lesz szó a fejlesztési irányokban.
Sőt már ma sincs nagyon sokszor.Nem tudom milyen kódot írsz, de ha render/szimuláció/bányász sw akkor értem. Minden más esetben nem ez a preferencia szerintem amit írsz.
Nem nagy teljesítménye hangolt algoritmust kódolnak 100%-os terhelésre hw-gyenge környezetbe.Nézz szét most mennyi sw, de főleg mennyi folyamat fut egy x86-on a háttérben. Ezek a hétköznapi feladatok. Ezek egyike sem arról szól, hogy 4-8-16 magot fullra terhel és órákig várjuk a futás eredményét. Arról szól az sw-k 99%-a, hogy fut a háttérben és valamit pötyög.
Ettől még lehet önmagában teljesítménycentrikus, lehet, hogy amire kell ott gpu-t használ, vagy mostanság akár vmi neurális hálót, akár hw gyorsítással. De akkor sem konstans 100% terhelést ad hosszú ideig.Innentől ma sem él az szvsz amit írsz, hogy egy programnak csak az a feladata, hogy "lefusson" a lehető leggyorsabban mert nincs elég erőforrás és legszívesebben 2-4x annyi hw-t tennél alá.
És erre tesz rá még 1-2 lapáttal a mobil-ultramobil ág, ahol:
1. Hatványozottan számít az akksi miatt a felhasznált energia minimalizálása.
2. A rendszer/os is sokkal inkább el van tolódva a párhuzamosan futó sok folyamat felé még az x86-hoz képest is.
És itt is efelé megyünk úgy, hogy már ma sem az "egy algoritmus fut a gépen aminek várjuk pár nap múlva az eredményét, a köv. prímszámot".És még egy megközelítés a fenti mellé: mi van a grafikával és a dedikált hw-ivel? A cpu/sw rendert 2 évtizede elhagytuk pedig ott is ugyanez volt, x86 kód kuka és teljesen újat kellett írni kényelmetlenül.
Mi van a többi, hasonló spec ággal? Van DXVA és egyéb video encode gyorsítás gpu-n vagy fixfunkcióson. Gyk. ma se nagyon lenne filmnézés ezek nélkül. Van egyéb gpu hw gyorsítás akár böngészőben. De nagyobb rendszerben gondolkodva most Apple M1-en is "megérte" külön gyorsítani ezt-azt. Lassan jönnek az új slágerhez is a hw-s gyorsítók a neurális hálókhoz.
A te gondolatmeneteddel itt is lehetett volna bármelyikre azt mondani, hogy 10-50x Gflops kéne az akkori cpu-khoz képest, tessék a 10-100x annyi magot/hw-t prezentálni kedves gyártók. Most annyi változott, hogy nem a hw kevés hanem több a lehetőség és van tér lefelé menni sw-ben egyéb előnyök (akku, mobilitás, méret, hűtés, always online, multitasking működés) miatt.[ Szerkesztve ]
-
sb
veterán
Ezzel egyetértek de nem hiszem, hogy ez jellemző.
Számításigényes feladatokra kellhet ennyi extra és erős mag. Mi az ami UX folyamat/esemény része (gyk. nem számítás/szimuláció) és nem kéne elfutnia 1db magon ami önmagában mips/gflops szinten irdatlan teljesítményre képes?*Ill. ha erre is van szükség, akkor sem nagyon lehet a másik oldalát figyelmen kívül hagyni. A maradék időben jó lenne egy energiahatékony architektúra ami a 0.1s burst-ökön kívül az erre fenntartott 16-32 magjával idle-ben is tud valami kezdeni a fogyasztással.
És végül visszakanyarodva a fő érvhez: még mindig onnan indulok ki, hogy sokkal inkább van szükség háttérben futó folyamatokra mint 1-2 éppen UX-en aktív dologra (ennél többet nem nyomkod senki mert a szeme/keze lesz a limit). A háttérben viszont még mindig több 100 folyamat futhat, de ami user szempontból felfogható abból is 10-es nagyságrend.
*Kivéve a saját korábbi példámat hozva: Ha a chatprogramban az épp bepötyögött emojikat is neurális háló animálja majd 1.5TFlops számítási kapacitással.
De ennek meg olyna ára van, hogy csak akkor jutunk el ide, ha "ingyen" lesz a mai 1.5TFlops árához képest:
1. A hw aminek ennyi szabad kapacitása van ilyen f*szságokra.
2. A fogyasztás, mert ezzel együtt is 2 hétig elmegy töltés nélkül.
3. És a fejlesztő (team) bérét is elbírja akik 2 hónapig kódolják a gfx-et és 3 hónapig trainingelik a hálót. És ennek mind visszajön az ára a kedves chatelő userektől. Ide asszem akkor jutunk el, ha az Mi írja a kódot és tervezi a chipet is.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Oda valóban felesleges...
vagy mint 2 darab 6600 (8 esetében)
Új hozzászólás Aktív témák
ph A legnagyobb teljesítmény eléréséhez Windows 11 kell, de a Windows 10 sem jelent leküzdhetetlen akadályt.