Új hozzászólás Aktív témák
-
Robitrix
senior tag
Én is mindig azon röhögök, hogy a legtöbben simán elhiszik, hogy mindig minden proci mag napi 24 órában pörög 100%-on. Miközben átlagban a 20% se jön ki nagyon egy otthoni PC esetében. Nekem egy 6/12-es proci van a gépemben és általában se megy a proci terheltség 40-50% fölé még a legtöbb játék esetében se. Ha realista vagyok messze nincsen szükségem a 6 mag 12 szál maximális teljesítményére sem. Relative egy átlag PC használóhoz képest sokat játszom. Ha a tényt veszem, hogy a világ PC használóinak úgy a 2/3 része soha nem is játszik a gépén. A legtöbb PC-t azért munkára és egyéb dolgokra használnak. böngészés, multimedia, szővegszerkesztés... stb. Ehhez egyszerűen nincsen szükség fullra járatott procikra. A feladatok 95% simán ellépecol néhány kisebb számú és teljesítményű magon. Aztán majd ha véges elem számítást akarok otthon végezni akkor jöhet a full teljesítmény, de tartok tőle ez nem túl gyakori feladat egy otthoni PC-nek.
-
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 ]
-
Robitrix
senior tag
olcsóbb... részben. de ha hűtőt, alaplapot hozzá számoljuk már nem.
Gyorsabb? hát 4 magot használó játékban igen olyan alkalmazásban, ami kihajtja a magokat és szálakat már egyértelműen lemarad vagy 35%-kal a Ryzen mögött... Kérdés úgye, hogy 4 magos játék miatt veszek 12 szálas procit? vagy annak reményében és jogos feltétlezése okán, hogy a jövöben tovább fog emelkedni az átlagos játékok mag és szál igénye. A trend végül is ez. Szóval én azt mondanám, hogy a válasz nem fekete vagy fehér... Pontosabban ebben az esetben piros vagy kék.... -
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
na ja viszont a 5600X vagy 30%-kal erősebb, mint a 3600X vagyis még durvább különbség a 10400F-hez képest teljesítményben. Ha vizsgálok mondjuk egy 3600-ast és egy 10400F-et, akkor nagyjából az 1 magos teljesítményük megegyezik. össz magon már széthajtva viszont már a sima 3600-as is erősebb úgy 43%-kal, mint a 10400f. Ha 5600X-et nézem az már leveri egy magon a 3600-at is közel 31%.os teljesítmény többlettel
ha minden kihajtanak csutkára belőle, akkor már veri a 3600-at 24%-kal egy 10400F-et meg több, mint 77%-kal gyorsabb szintetikus teljesítmény tesztekben. Hiába beszélünk gyakorlatilag egyforma 6/12-es procikról a teljesítmény különbségük, mint a Gellért hegy és a Himalája... kis túlzással. Te se gondolod komolyan, hogy a 77%-kal erősebb proci ugyan annyiba kerül, mint a 77%-kal gyengébb. A különbséget föleg az okozza a többszálas maxra kihajtott teljesítményben, hogy valahogy sokkal nagyobb teljesítményt lehet elérni az AMD SMT-je által, mint az Intel HT-je. Persze a gyakorlatban azért nem jön ki ez a hatalmas teljesítmény különbség, hiszen a legtöbb alkalmazás esetében a proci teljesítmény csak egy rész képvisel az össz teljesítményben. Ha fut egy program és mondjuk egy komplex feladatot le fut benne 600 másodperc alat. Miközben használ, memóriát, hátértárat, grafikát stb. a CPU átlag meg mondjuk 15%(nem is használja ki egy időben az összes magot és szálat.) Ha beteszek elméletben egy a szintetilkus cpu tesztek szerint egy dupla teljesítményú procit, akkor simán lehet, hogy a 600 mp komplex feladatom lemegy 578 másodpercre, vagyis korlátozottan érvényesül a futásban magának a CPU.nak a számítási teljesítménye. Még a csutkára kihajtott CPU mellet se fog a teljes idő igény a felére lecsökkeni, hiszen attól, hogy a CPU-m kétszer olyan gyors még a memoria átvitelem nem fog gyorsulni drasztikusan. Na most a játékok is ilyenek. A elméletben szintetikus tesztben dupla teljesítményt elérő procitól nem lesz a játékban 100 FPS helyett 200 FPS teljesítmény, lehet, hogy csak 112 FPS lesz. Hurrá aztán az más kérdés, hogy játék közben mennyire venné észre az ember ha nem mérné az értéket, hogy adott pillanatban 112 FPS-et jelenit meg neki a monitor vagy csak 100-at. Nagyjából full értelmetlen centire méregetni a teljesitmény különbségeket, mert úgyse érzékeljük a gyakorlatban. Az megint más kérdés, hogy jelenleg mennyire reális a Ryzen procik árazása a hatalmas kereslet miatt. Mennyire reális mondjuk egy Ryzen 5 3600-s procinál, hogy több mint 2 évvel a megjelenés után(2019 május) még mindig 200 dollár körüli az ár. Miközben tavaly nyáron voltak olyan időszakok, mikor egy 3600-ost már 160 dollár körül mértek. Az eddig piaci logikák alapján mát valahol 120 dollárnál kéne járni egy 2 éves procinak az árának különösen annak fényében, hogy kijött az utod generáció és lassan megjelenni év vége fel majd az unoka proci is. Azelőtt a gyártók negyedévente felül vizsgálták a procik árait és folyamatosan árazták lefele a régebbi modelleket 5-10 dollárral. Mindig helyet biztosítva a közben megjelenő új modelleknek. A mostani helyzet irreális piaci szempontból, visont a hatalmas kereslet és a szintet tartó ár azért valahol azt mutatja, hogy a Ryzen 5 3600-s például egy igen jól sikerült proci, ami remekül megfelel egy átlagos számítógépben még játékra is ha nem akar extra igényeket az ember. Mondjuk 1 milliós videókat kihajtani 4K ultra felbontásban. Bár egy 3600-s végül is elvisz használhatóan egy 3090-es grafikát is. Ha nem zavarja az embert, hogy csak 135 FPS van ott, ahol a 700-800 dolláros procival volna mondjuk 150 FPS. Persze azért nem szokás összerakni a 200 dolláros procit a 1500-2000 dolláros videókártyával. -
Robitrix
senior tag
A HT kikapcsolás akkor igaz, ha mondjuk a 6/12-es procin olyan alkalmazást futtatsz, aminek elég a 4 mag. Ha olyan programot használsz, ami igényli a sok magot és szálat abban az esetben a HT lakapcsolása már ront az össz teljesitményen. Nilván ha nekem 12 programágat is tudna egyszerre futtatni a csak 6 magra kapcsolt proci kisebb teljesitmény még akkor is ha a 12 szál teljesítménye nem ér fel 12 mag teljesítménnyel. Amúgy láttam teszteket, ahol például Ryzen 5 3600-ssal kisélteztek játék közben és le kapcsolták a több száluságot vagyis knyomták a SMT-t na a kb 4 magot használó játékban simán ugrott a teljesítmény átlagosan 3-4 FPS körül átlagban. Ez persz csak a 4 magot használó játék esetén volt igaz. Tehát amig kevés mag és szál van megterhelve egy prociban akár még hátrány is a többszálú CPU. Részben a hülye Windows erőforrás ütemező miatt. Sok feladat mellett az is a feladat, hogy sporoljon az erőforrással így ha teheti hajlamos rá, hogy egy 4 magot használó progrmot rátegyen mondjuk 2 mag 4 szálára. Ahelyett, hogy a 4 program ágat hatékonyabban egy-egy mag egyetlen szálán futatná. Ha nincsen terhelve a proci simán rakhatná az első mag 1.-es szálára, a 2-es mag 1-es szálára 3-mas mag 1-es szálára és a 4-es mag 1-es szálára. Önmagukban használva a proci magokat. Ez is oka volt, hogy sokszor hatékonyabban futott a régebi intel procikon a pár magot használó játékok a 4/4, a 6/6 és a 8/8-as procikon Aztán persze a 10. generációtól kezdve kénytelen volt újra szálasítani a proci magokat az intel mert kezdett rondán elmaradni össz teljesítményben az AMD szálas prociktól. Viszont mivel éveken át nem törte magát az ő saját többszálasasítási eljárásának fejlesztésével(HT) a mai napig meglehetősen elmarad az AMD SMT hatékonyságától. Szerintem sok évni elmaradásban van az Intel HT az AMD SMT hatékonyságától. Amúgy nem lehet kategórikusan univerzális megoldást mondani a kék vs. piros kérdésben.
-
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
Pont ez okozza a gondot a szálasított futásnál. Mivel egy mag két szálának közös a gyorsító tára. Viszont a cache vezérlése adott pilanatban nem tudja a két szálon futó folyamat egyszerre jelentkező memória igényét kiszolgálni. Ha egyszerre jelentkezik az igény, akkor valamelyik szálon futó folyamatnak egy kis állj és coki van pár gépi ciklus idejére, amig lezajlik a másik folyamat kiszolgálása. A Cache kezelésénél nincsen két csatornás memória kezelés, mint a RAM esetében. Ez okozza az átlagosan 30-40% körüli teljesítmény esést a 2 maghoz képest a egy mag két szálán futás esetében. Persze ha nekem 10 párhuzamos folyamatot kell futtatnom egyszerre, akkor hatékonyabb a 6 mag 12 szál, mint a 6/6. Lévén hogy 6 magon képtelésnség egyszerre 10 szálat futatni. A szopás vagy az előny kérdése erösen függ attól, hogy adott pillanatban mi fut a gépen mennyi mag igénnyel.
-
Robitrix
senior tag
én meg azért mérem a 5600X-et az 3600X-hez, mert jelenleg nem létezik 5600-as proci bár van szó róla.
Még akkor is ha a 3600 és a 3600X ugyan az a proci leszámítva, hogy ez utóbbi órajele feljebb van húzva 100/200 Mhz-el és a TDP kerete ezáltal nem a 65 watt, hanem a 95 watt. -
Robitrix
senior tag
Persze az élet azért nem csak játék programból áll. Mint ahogy arra sincsen garancia, hogy a játék programok megmaradnak a ma a szokásos tipikus 4-6 mag igénynél. Ne felejtsük el, hogy az új konzolok már 8/16-os procival rendelkeznek. Ráadásul egy eleve ZEN 2-es Ryzen származékkal. Ami talán leginkább a Ryzen 7 3700X-hez áll a legközelebb. És ha mátr ott a müszaki lehetőség a konzol játék fejlesztök elött arra, hogy túl lépjenek az eddig korláton a régi konzolok 2*4 magján és nyújtozhatnak feljebb 16 párhuzamos szálig, akkor lesz, amikor élnek vele és talán ha tudnak alkotnak 10-12-14 vagy akár 16 szálon futó játékokat. Azt is tudjuk, hogy a sikeres konzol játékok gyakran megjelenek PC-re is(és forditva) Így amikor visszaportolják a nagyjából kompatibilis PC-re a konzol játékokat várható, hogy a PC változat is simán kér 10-12 szálat a futáshoz. Mivel a PC-k esetében is folymatosan nővekszik az átlagos mag és szál szám ennek nem lesz akadálya. VAgyis szerintem simán várható, hogy jelennek meg olyan játékok a jövöben amik nagyobb mag és szál számat használnak egy PC-n Biztos, hogy nem fogják logikailag áttervezni az egész programot mondjuk 6 magra. Az sokkal több logikai munkát igényel. A sok munka meg idő és pénz. És nyilván egy játék fejlesztő igyekezne minnél gyorsabban és olcsóban megoldani a dolgot. Én várokm a következő 1-3 évben játék fronton némi mag és szál szám növekedést átlagosan. Ha ott a hardver kéznél, akkor ostobaság volna nem használni teljesítményben. Ilyen szempontból jobb választásnak tünik egy nagyobb teljesítményű Ryzen proci sok mag és szál mellet. Aztán, hogy meddig szabadulnak el a fejlesztök a következő években majd meglátjuk. Azért az elmúlt 20-30év azt a tapasztalatot adja, hogy igyekeznek követni egy adott kor hardver teljesítményét. Mind grafikában, mind CPU-ban. A konzolok új teljesítményei minden képpen emelni fog a következő évek teljesítmény igényén szerintem. Mint ahogy egyre gyakrabban karcsú már egy játékhoz egy 4 magos proci vagy egy régi 4/8-as néha már egy 6/6-os is
-
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.
-
Robitrix
senior tag
válasz
tasiadam
#102
üzenetére
azért egy rtx 3060-ast simán kihajt egy 2700X egy RTX 3060-as teljesítménye nagyjából ott van a rtx 2080 (TI nélkül) környékén. Persze a régebbi procik már összeszednek némi magonkénti teljesítmény hátrányt az újakkal szemben, de jelenleg még a 2700X jól lboldogul minden grafikával.
-
Robitrix
senior tag
válasz
tasiadam
#102
üzenetére
Amúgy nem vagyok arról meggyőződve, hogy egy AM 5 vagy egy DDR 5 memória hoz annyit teljesítményben, mint amennyivel többe fog kerülni.
Nézd meg a PCI 3.0 és a PCI 4.0 különbségét. Tegye fel a kezét, aki érzi azt a hatalmas különbséget egy PCI 3-as és egy PCI 4-es kártya közt, amennyit elvben a specifikáció jelent. -
Robitrix
senior tag
Egyértelműen gyorsabban avul a GPU, mint a CPU. Én is terveztem idénre már egy grafika cserét. Ami a mai árak mellett nem tünik realitásnak. De általában ha veszek egy használható gépet, akkor elöbb kerül cserére benne a grafika,mint a CPU. A játékok grafikia igénye gyorsabban növekszik, mint a CPU igény.
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. 
Ú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.
- Autós topik
- Posta, csomagküldés
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- World of Tanks - MMO
- Tüzi: Geek-hatarozo
- Motorola Edge 40 - jó bőr
- Politika
- Az alaplapgyártókra hárítja az Intel az egyes Core CPU-k stabilitási gondját
- Kerékpárosok, bringások ide!
- Kínai, és egyéb olcsó órák topikja
- További aktív témák...
