Új hozzászólás Aktív témák
-
opr
veterán
Ennek a hozzászólásnak konkrétan nulla értelme volt.
1) Ez így van már bő 5 éve, konkrétan nemhogy gyártótól, de még architektúrától is függetlenül.
2) Mi a tökömnek kéne átlag Bélának desktop i9? Vagy hasonló kategória a másik oldalról.
3) Ez egy szakmai portál. Ha annyi lenne a kérdés, hogy alapvetően működik-e valami, abban a kontextusban, hogy bekapcsol és képes szoftvert futtatni olyan szinten, hogy az átlagnak elég, i3/r3 felett semmiről nem lenne értelme beszélni.
4) Ismét, ez egy szakmai portál, és mint ilyen, rengeteg olyan ember van itt, akinek ezzel kapcsolatos a munkája, ezen belül is rengeteg területet lefedünk, ahol rengeteg szempont érvényesül, plusz elég sokunknak van több évtized tapasztalata. Ebből a szempontból nézzük, ne úgy, hogy ha megnyomom a gombot a prebuilt oem gépen, bekapcsol-e, amennyiben be van dugva a konnektorba, és a konnektorban megfelelő áram van.
5) Most komolyan, hogy lehet ekkora coelho szintű baromságot leírni egyáltalán?"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
Én is. Ezért írtam, amit. Skylake ipc egy alapvetően alacsony órajelre és fogyasztásra optimalizált magon a büdös életben nem fogja elverni az 1700x-et azonos körülmények között. Persze soha nem lesznek azonos körülmények, már csak a ddr5 miatt sem, de még úgy is erős kétségeim vannak.
De miért is kéne neki? Baromság az egész felvetés. Nem kell neki. A háttérben futó discordot kell etetnie a lehető legjobb hatásfokon, lehető legalacsonyabb fogyasztással.
Amikor meg el kell verni nem csak az 1700x-et, hanem az 5700x-et is, esetleg annak az utódját is, arra meg ott a zabáló, rohadt erős másik 8 mag, aminek ez a dolga.
Aztán hogy sikerül-e befogni a ddr5-ös AMD-t, ami a konkrét ellenfele lesz? Meglátjuk. Őszintén szólva nem hiszem, de remélem legalább egy kb egál lesz a meccs vége.
"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
-
#16939776
törölt tag
Szerintem nem direktben a teljesítményre mennek ezzel, inkább az a cél, hogy a nagy magot elég legyen ki/be kapcsolni, (0 és 5Ghz) így azzal, hogy azokat nem járatják feleslegesen, TDP-t tudnak megtakarítani a többi magnak. Meg még egy csomó olyan üres órajelciklust, amikor az órajel váltások pillanatában nem csinálhatott semmi hasznosat a nagy mag, de azért közben fogyasztotta az energiát.
Szóval ez szimplán egy sokkal gyorsabb energiagazdálkodás, ami lehetővé teszi, hogy a nagy magok amikor effektíve dolgoznak, magasabb órajelen működjenek ugyan annyi TDP-ből. Persze ennek feltétele, hogy a nagy magokat nem igénylő feladatok ne kerüljenek rájuk és feleslegesen ne tartsák azokat aktív állapotban, na erre kellenek a kis magok.Szerintem ez megint csak olyan helyzetben fog jól működni, ahol nem nem fogy el a TDP, nem kap folyamatos erős a terhelést a processzor. Mert akkor azt kell sakkoznia az OS-nek vagy a preset-nek, hogy a két nagy mag, vagy a 8 kicsi kapja inkább a TDP keret utolsó ~1/4-ét, melyik eset az előnyösebb.
Szóval az a case lesz a döntő "hogy melyik a jobb", hogy amit egy 16 magos proceszor rezzenés nélkül kitol de ez már köhögi kezd, az mennyire lesz esetszámban gyakori, mennyire fogja ez zavarni a usert.Itt az a buktató, hogy ennek a szélességét a szoftver/os felkészültsége
fogja eldönteni, ők meg csak a hardvert gyártják, szóval járhatnak úgy, hogy nem oldja meg más a problémájukat, vagy nem olyan jól mint ahogy ezt elvárnák/elvárnánk.[ Szerkesztve ]
-
tasiadam
veterán
válasz
#16939776
#56
üzenetére
"Szerintem nem direktben a teljesítményre mennek ezzel, inkább az a cél, hogy a nagy magot elég legyen ki/be kapcsolni, (0 és 5Ghz)"
Azért legalább az intel nem AMD, hogy van 4 state vagy 3, és vége. 2700x-em tudott párat. 800mhz, 2000mhz, 3200mhz és 4000mhz. Ezek között nem létezett semmi.
Ehhez képest egy i5 6400 meg lemegy 400mhz-ra is ha idle, és terhelés függvényében emeli a szorzókat, vagy a blck-t is.Gyermektelen, nem házas, másodrangú állampolgár
-
opr
veterán
válasz
#16939776
#56
üzenetére
Egyetertek, ugyan ezt irtam feljebb En is. Annyi kulonbseggel, hogy mivel ez i9, itt biztos, hogy a teljesitmeny is erosen a fokuszban lesz, csak alacsony uresjarati fogyasztas mellett (ha minden jol megy).
"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
Mar az elso Zen-nel is finomszemcses energiagazdalkodas volt, ami magonkent tudta 25Mhz-enkent allitani az orajelet. Konkretan ilyen teren (is) jelenleg az AMD merfoldekkel jar az intel elott:
"A Summit Ridge a megfelelő működés érdekében rengeteg, ezernél is jóval több szenzort tartalmaz, amelyek valós időben monitorozzák a lapkát, és reagálnak a különböző eseményekre. Ez teszi lehetővé, hogy az egyes magok mindig az optimális órajelen üzemelhessenek. A precíz órajel beállításához azonban az AMD bevezette a finomszemcsés P-State modellt, amely a Windows 10 P-State megoldását váltja. Ennek köszönhető az, hogy a lapka nagyon apró, 25 MHz-es léptékenként tud órajelet váltani, ráadásul magonként függetlenül, így mindig tökéletesen lehet igazodni a környezethez."
Az egy masik kerdes, hogy a chipset meg az alaplapok milyenek, amik miatt az uresjarati fogyasztas rendszerszinten megsem az igazi. Plusz ez ugye 4,5 eve volt, es meg mindig nem teljesen tokeletes a dolog, sokszor van par mag a kb semmiert felporgetve, de ugyan ez igaz a masik oldalon is. Tobbek kozott pontosan ezert vagyunk tobben szkeptikusak az Alder Lake-el kapcsolatban is, mert meg ha egy sima skalazas is nehezen megy neha, akkor a heterogen utemezes, ket fajta magon, amikbol az egyik adag HT-s, a masik nem, es mindkettonek allithato az orajele, ami egy nagysagrenddel komplexebb rendszer, az hogy fog jol mukodni.
"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
-
#16939776
törölt tag
Hogy a sok lépcső jó vagy nem annyira az, azt a felhasználás dönti el.
Azt aláírom hogy aktív energiagazdálkodásnál, kis terhelésen elég darabos tud lenni a korai zen, darabosabb mint az intel, de all core fix órajelen tuning és energiagazdálkodás nélkül megfordul a dolog. -
dokanin
aktív tag
Úgy látom abban egyetértés van, hogy a kicsi magok optimális kihasználásához szükség van a fejlesztőkre is.
De kíváncsi lennék, hogy tudna-e valaki olyan gyakorlati szenáriót mondani amiben programozóként érdemes lenne pénzt és időt fektetni abba, hogy egy feladatot a kicsi magokra helyezzek amennyiben ezek elérhetőek. Mégis miért lenne ez nekem jó? Mit nyerhetnék ezáltal? Az, hogy így esetleg kevesebbet fogyaszt a proci programozóként egyáltalán nem szempont.
A legtöbb program mellett a legtöbb mag parlagon hever most is, pedig ezeknek a befogása rengeteget hozzáadhat egy szoftver sebességéhez, mégis kevesen lépik meg. Fura lenne, ha a kicsi magok jobban vonzanák a fejlesztőket.
Jelenleg egyetlen ilyen helyzetet látok csak, oprendszer fejlesztője tud profitálni a kicsi magokból, de ezen kívül semmit. De persze ez nem azt jelenti, hogy nincs, de kíváncsi lennék ki tud ilyet és mi az?[ Szerkesztve ]
-
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
-
#16939776
törölt tag
Attól függ, hogy hogyan éred el a fix all core-t. Ha kézzel állítod be az óra-jelet, akkor megemeli a magfeszültséget, olyannyira mintha folyamatosan túrbózná a mag, és szerintem a LOD-ot is kikapcsolja a mag és a VRM közül. És ahogy tapasztaltam, nem változik a feszültség, mindegy neki ha veszed le az órajelet, szóval ez az út nem optimális hozzá.
Én csak annyit csináltam, hogy lehúztam a CPU ventilátort és a CPU megtartotta alapfesszel 1.25-28V az all-core turbó órajelet 3700Mhz-t, passzívan el van, minden hideg, még a VRM-ről is levettem a bordát és alig langyosak a fet-ek.[ Szerkesztve ]
-
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
-
dokanin
aktív tag
Emlékszem, amikor bejöttek a többmagos procik. Úgy vártam rájuk mint a messiásra. Végre valami ami kézzelfogható előnyt jelent a programozásban.
De most semmi ilyesmit nem érzek. Fejlesztőként a legkevésbé sem érdekel az üresjárati fogyasztás az ügyfélnél. Miért is érdekelne? Sosem fognak felhívni, hogy nagyon ürülünk, hogy téged választottunk és nem a konkurenciát, mert nálad sokkal kisebb lett a villanyszámla. -
tasiadam
veterán
válasz
#16939776
#64
üzenetére
all core 4ghz zen+-on, fix fesz. Fogyasztás (ha a win10 nem piszkálja azt a magot) 0.8-1.2w, ha piszkálja, akkor 2-4w. Nyilván ha fix a fesz, akkor az ampertől függ a teljesítmény/fogyasztás. Ha terhelve van, akkor asszem jelenleg 12 és 14w között van / core. Egyszóval tökmindegy, mennyi a fesz, sokat nem számít. Stock vs all core oc pont ezért nem sámít sokat win10 alatt, csak ilyen 3-5w-ot. Laptopnál ez sok lehet.
Gyermektelen, nem házas, másodrangú állampolgár
-
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
-
#16939776
törölt tag
Kiesebb hévvel de én is így gondolom.
Nem az a bajuk, hogy nem lesz elég erős a mag, /Max. TDP ()-be téve/ inkább az, hogy túl komplexé tették a rendszert, amiben ezeknek a magoknak működniük kell.
A konkurenciának egyetlen baja az idle fogyasztás/reszponzivitás kérdése, itt próbálják megtámadni. Nem azzal foglalkoznak hogy hogyan tudnának ők is egy nem ennyire komplex rendszert csinálni, amiben képes a mag be/ki kapcsolni másodpercenként több százszor, inkább bonyolítanak még egy nagyot. És vállaljak a kockázatot hogy esetleg túlbonyolítottnak tartja majd a piac ezt a megközelítést, és idővel ha lehet eltekintenének tőle. Attól hogy az aktuális intel desktop processzorhoz optimalizálják azokat a programokat, amit jóval többen mobil-on vagy ws-szerű gépeken futtatnának majd, amikor amd-nél szinte teljes átjárás van a mobil és a WS-szerver dizájn között, már ha erre igény lenne és optimalizálni is akarná ezekre bárki a szoftverét. -
ricsi99
addikt
-
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.
-
tasiadam
veterán
nekem a személyes kedvenc érvem:
Vérpistike: LEGJOBB A 3600, OLCSÓ, ALIG ESZIK
Én: A 10400F olcsóbb jócskán és erősebb is
Vérpistike: HOL, NEM JOBB, RP MONDTA, NEKI AZ VAN
Én: <mutatom h általában úgy bárhol jobb
>
Vérpistike: DE SOKAT ESZIK
(ha meg kevesebbet enne azt mondaná, hogy nem jobb, mert kék a doboza)Gyermektelen, nem házas, másodrangú állampolgár
-
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. -
sb
veterán
Már ezt is sokszor írtam de az órajelállítás, küszöbértékek, core parking, stb... sokkal többet számítanak. Meg az IF/cache/ram OC.
Ezek idle is 10-20W-ot rádobnak, a magok meg még egy kicsit a fentiek miatt de nem a core power a problémás alapvetően.Amúgy az Intel IF nélkül és monolit felépítéssel sokkal jobban viseli a light load-ot kisebb fogyasztással még mindig. Szóval nem feltétlen ez lehet a kis magok bevetésének oka. Hacsak nem vmi nagyon sokkal alacsonyabb szintre akarják belőni az idle-t.
Max load-on meg nyilván jobb lenne a több nagy mag. De perf/W már nem feltétlen.
Említve volt a Skylake IPC ami lehet, hogy egál a Zen1-el de a perf/W kb. 2x jobb utóbbin még így is az alacsonyabb órajeleken ahova ezeket szánják.Szóval lehet, hogy az Intelnél vmi kényszermegoldás tényleg az egész. De értelme akkor lenne ha tényleg light load/idle-ben adnának pluszt a kis magok megfelelő sw körítéssel, ezzel hozzájárulva a valós fogyasztási előnyhöz vagy folyamatos online üzemhez.
-
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.... -
dokanin
aktív tag
Természetesen a programozó tudja megmondani legjobban, hogy melyik szálnak mennyi kraftra van szüksége, de azt még mindig nem látom, hogy minek akarnék időt és pénzt áldozni arra fejlesztőként, hogy kicsi magokkal is foglalkozzak? Eddigi tapasztalataim alapján elég nehezen tudom elképzelni, hogy bármi gyorsabb lenne azáltal, hogy egy egy szálat inkább nem a nagy magon futtatom, amikor pl az én windowsomban most épp 2200 szál fut 8 magra elosztva. Ha pedig nem nyerek valamit vele a saját fejlesztésemmel kapcsolatban szinte kizárt, hogy használnám. Pláne valami homályos nyereség miatt. Még a több mag kihasználása is külön döntést igényel, hogy megéri-e a befektetett munka jelenleg is.
Továbbá egy másik probléma, hogy szerintem manapság a legtöbb programozó nem közvetlenül hoz létre thread-eket, hanem az általa használt keretrendszer kezeli ezeket jellemzően valami treadpool-ból újrahasznosítással, mivel nagyon nem éri meg folyton létrehozni és megszüntetni szálakat. Ebből kifolyólag pedig elemezni is lehetetlen hogy egy egy szál milyen teljesítményt kíván, hiszen hol ezt futtatja, hol azt.
És ami pedig a legnagyobb probléma szerintem, hogy akár egyetlen kicsi mag jelenléte is sokszor visszafoghatja az összes többi nagy magot a szinkronizáció miatt, így viszont inkább káros, mint hasznos a jelenléte.
A saját 20 éves szakmai tapasztalatom alapján én úgy látom, hogy kicsi magokat akkor lehet jól kihasználni, ha ezt az oprendszer teszi, nem keverve a felhasználói programokkal, hanem a saját háttérfolyamataihoz. Pl andorid esetében tényleg baromi hasznos lehet ez, ha a telefon készenléti módjában, amikor fogadni kell az értesítéseket, hívásokat, stb csak kicsi magokon dolgozik, hiszen akkor a user úgysem nyomkodja, tehát tök mindegy hogy mi mennyi idő alatt végez, viszont tényleg rengeteget lehet vele spórolni üzemidőben.
De a laptop pl pont nem ilyen. Ott ha nem használod kikapcsolod. Nincsenek háttérfolyamatok alvó üzemmódban.
De persze majd kiderül. Mindenesetre kíváncsian várom, hogy mi sül ki belőle. -
tasiadam
veterán
Nem feltétlen olcsóbb lappal se. b560 már nem drágább, mint a b450. Lehet rossz b560 és b450 is persze, pl vrm hűtés nélkül. Ram ugyan azt elviselik, tehát az 1 ár. Viszont markánsan olcsóbb a 10400F mint egy 5600x. 45-ért vetettem ismerősömmel kora tavasszal.
3600 stock vs 10400f stock azonos ramokkal és azonos játékok alatt kell érteni. Ha megkapja a 10400f azt, ami az önbeteljesítéséhez szükséges és eufóriába lép és megtudja mi az élet értelme, nem gyenge. [link]
[link]
Persze erre az is rájátszik, hogy a játékok nagy része intel bias, megh át a steam felhasználók 70%-a intelt nyom. Persze, hogy azokra hegyezik ki.[ Szerkesztve ]
Gyermektelen, nem házas, másodrangú állampolgár
-
martonx
veterán
most akkor 3600 vagy 5600x a referencia? Mert nagyon nem mindegy. Bár amennyiben magadat akarod megnyugtatni, hogy mekkora üzletet csináltál az 10400f-el, akkor végülis mindegy is
Amúgy a 11400 tényleg egész jó ár/értékű, a 10400 szvsz sosem volt az, kivéve ha CSAK az olcsón játszás a lényeg.Én kérek elnézést!
-
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.
-
dokanin
aktív tag
-
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. -
dokanin
aktív tag
-
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
-
tasiadam
veterán
válasz
Robitrix
#101
üzenetére
Ezért is van 2700X-em, meg olcsón is jutottam hozzá, de szeretnék olyan CPU-t rakni a 3060 mellé ami ki is tudja rendesen tekerni, de legalább 8 maggal. Ekkor jött hogy 11700(K), vagy 5800X a delikvens. Úgyhogy az 5800x lesz a hunyó, csak még minbdig sokallom, És remélem nem lesz olyan hatalmas változás az alder és AM5 részéről, hogy jóformán 2 gen után megint gyenge lesz a CPU. Viszont az megnyugtat, hogy 3000 nvidia super az 2022-2023 környékén lesz, aztán az Ada Lovelace kártyák meg mintha 2024ben rémlenének. Szóval 3-4 évig simán ki lehet húzni 1 konfiggal most anélkül, hogy a CPU kevés lenne a kártyának.
Gyermektelen, nem házas, másodrangú állampolgár
-
martonx
veterán
válasz
tasiadam
#102
üzenetére
A játékok gép igénye leginkább a konzolok 7-8 éves életciklusának fordulójakor ugrik meg, mert hirtelen nyugodtabban lehet erősebb vasra fejleszteni.
Azaz most pont egy ilyen ciklus fordulóban vagyunk, azaz ha mostanában veszel naprakész hardvert, akkor azzal kis túlzással, de az elkövetkező jó pár évben jó vagy.
Ellenben ha mondjuk pont 1-2 évvel egy ilyen ciklus váltáskor vásároltál be, akkor kb. 3 éven belül dobhatod is ki, amid van.Az új konzolokban Ryzen 3700x-hez hasonló proci van, és egy RX 6600 szerű GPU. Szóval az elkövetkező években ezeket a speciket kell megugrani, és akkor jó vagy (nyilván PC jóval optimalizálatlanabb, mint egy konzol).
Azaz szerintem egy Ryzen 5800x + RTX 3060-al jó darabig jó leszel. A GPU hamarabb lesz kevés, mint a CPU szerintem.
Én kérek elnézést!
-
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.
-
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 ]
-
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.
-
dokanin
aktív tag
Szerintem amikor a több mag kihasználásáról van szó a legtöbben mindig a hosszan tartó folyamatokra gondolnak, pedig üzleti alkalmazásokban is marha jól lehet használni rövid ideig tartó eseménykezelőkben is. Ha azt a rövid jellemzően 1-2 másodperces műveletet sikerül párhuzamosítani és ezáltal tizedmásodpercekre rövidíteni a válaszidőt, hatalmas ugrásnak fogja érezni az ügyfél, annak ellenére is, hogy a procija az idő 99%-ában malmozik. Szóval simán megéri ilyenkor is a többmagos procit választani.
-
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.
-
ricsi99
addikt
-
dokanin
aktív tag
"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?*"
Hát én speciel nagyjából csak a Visual Studioban dolgozom és ott bizonyos műveletekkel el tud bíbelődni egy darabig és látható egyébként, hogy bizonyos műveleteket egy szálon old, meg míg másokat már optimalizáltak és több szálon fut. Pl a build az ilyen. De a bulid során is tökre jól látszik (legalábbis az én gépemen ryzen 2700), hogy még az SMT is tök negatívan befolyásolja a folyamatot. Amin most dolgozom solution smt nélkül 30 sec alatt végez, SMT-vel 40. Szerintem ha kicsi magok is keverednének ebbe a folyamatba ugyanígy csökkenne a hatékonyság, mivel a párhuzamosított folyamatoknak időnként mindenképp be kell várniuk egymást és ha belekeveredik valahogy egy lassabb szál a sok erős közé elvész az előny, mert ilyenkor a leggyengébbre vár a többi erős.
Abban egyébként teljesen igazad van, hogy az aktív szálaknak kb 99,9%-a háttérfolyamat, de szerintem ezek kiszolgálása még mindig sokkal kedvezőbb egyforma magokon. Persze ha nem veszem figyelembe a fogyasztást, de engem az személyesen egyáltalán nem érint jelenleg.
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.
- Lakáshitel, lakásvásárlás
- Witcher topik
- Asus tuf-rtx3060-o12g-v2-gaming videokártya random kockás kép.
- Készülőben a Xiaomi 2021-es csúcsmodelljeinek HyperOS frissítése
- Nők, nőügyek (18+)
- LEGO klub
- Milyen okostelefont vegyek?
- Napelem
- Gyúrósok ide!
- Motorola Edge 50 Pro - több Moto-erő kéne bele
- További aktív témák...
- Intel Core i7-9700K / 9900K BOX Processzor - Kifogástalan Működés & Garancia
- Intel I7 8700K processzor
- Új bontatlan, dobozos, számlás, garanciális i9 13900K CPU akció!
- Beszámítás! Intel Core i7 6700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! AMD Ryzen 7 7800X3D 8 mag 16 szál processzor garanciával hibátlan működéssel