Hirdetés
-
Ellopták a Tesla akkumulátor-titkait
it Beperelte egy korábbi beszállítóját a Tesla, és azzal vádolja, hogy üzleti titkokat lopott a Tesla akkumulátorgyártási technológiájával kapcsolatban.
-
Olcsó USB WiFi AC adapter
lo Egy olcsó WiFi AC USB adapter jó szolgálatot jelenthet, ha az új router csak elvileg támogatja a 2,4 GHz-es átvitelt.
-
Dobja a változatható apertúrát a Xiaomi 15 Pro?
ma Lencsetrükkök helyett nagyobb szenzorral érkezhet októberben.
Új hozzászólás Aktív témák
-
Robitrix
senior tag
a dolog sikeressége igazán egy dolgon múlik. Mennyire sikerül optimalizálni hozzá a rendszerek erőforrás ütemezőit, hogy kihasználják rendesen a hibrid magok előnyét. Tehát, hogy optimálisan a nagy teljesítményű program ágakat a gyors magon akarja futtatni. Vagyis fel kéne hozzá okosítani a windows vagy más rendszerek erőforrás ütemező részét. Tavaly nyáron adott ki a az intel korlátozott számban egy 4+1 magos hibrid procit. Ahol 4 normál mag volt és egy gyors mag. Akkor a gyakorlati mérések alapján nem jeleskedett a windows, hogy a gyors magot eredményesen össze hozza a legnagyobb teljesítmény igényelő folyamatokkal. Vagyis korántsem volt optimális a proci kihasználás.
-
#36
Robitrix
senior tag
bitblueduck
#5
Robitrix
senior tag
válasz
bitblueduck
#5
üzenetére
ott sem működik azért kifejezetten optimálisan. például nekem olyan telefonom van ami 4 gyors magból(2,16 ghz) és 4 lassabb(1,6 ghz) magból áll. Elméletben egy magon képes a 2,16 ghz helyett felmenni 2,36 ghz-ig. Ez az elmélet. A gyakorlat az, hogy a futó alkalmazások igen ritkán használják ki a maximálisan elérhető sebességet. Az esetek döntő részében egyszerüen be se kapcsolnak a gyors magok. Ennek gondolom alapvetően energia takarékossági okai vannak. Spórolni kell az aksival. Igaziból csak pár alkalmazás, néhány játék van ami jobban kihajtja a teljesítményt a prociból. Ilyenkor lehet érezni, hogy pár perc után elkezd langyosodni a telefon hátulja. Vagyis azt kell mondanom egy andoidos rendszer is csak nagyon lagymatagon teszi oda a program alá a kakaót. Inkább lébecol csak, ha teheti.
-
Robitrix
senior tag
A buldozernek azért volt némi hardver hibája is. Elvben nem szálasított proci volt. Vagyis optimális teljesítménnyel kellett volna menni. Viszont valamilyen gyártási okból úgy volt felépitve, hogy a nem szálas proci magok 2 magos csoportokba voltak összefogva. Például egy 8 magos Buldozer proci esetében 4*2 mag volt a felépítés. Aztán ehhez a 2 magos csoportokhoz egy közös gyorsító tárat rendeltek hozzá. Vagyis a 2 magnak osztozkodni kellett a közös cache-n. Amivel gyakorlatilag pont úgy megvalosították a több szálas mag hátrányát a egy mag két szálat. Ott is az okozza a teljesitmény vesztést, hogy a közös gyorsítótárt adott pillanatban nem tudja a két program szál egyszerre használni. Így ha az egyik program szál mondjuk adatot akar olvasni a cache memóriából, akkor a másik programszálnak ki kell várni pár gépi ciklust, mikor felszabadul a számára is a cache memóriához hozzáférés. Ez okozza azt a lassulást, hogy szálasított proci teljesitménye kisebb. Ha egy mag teljesítménye 100% és a 2 mag teljesitménye 200% mondjuk, akkor a 1 mag 2 szál esetében úgy 160-165% körül van a teljesítménye. Na ugyan ezt a teljesítmény vesztést valósitották meg a buldozer proci 2 magonként hozzá rendelt közös gyorsító tárral. Ráadásul voltak teljesítmény gondok a 2 magos csoportok és a fő memória közti adatátvitel sebességével is. Ez okozta, hogy hiába volt elvben egy buldózer proci 8 magos a gyakorlatban úgy viselkedett, mint egy 4/8-as proci és azt a teljesítményt is hozta lemaradva az intelek mögött. A ryzenek estében ezt javították valamilyen szinten, ezért is gyorsabbak a ryzenek összes magon és szálon kihajtva az hasonló intelekkel szemben. Ráadásul valamilyen okból gyengébben muzsikál az Intel többszálasítási megoldása a HT, mint az AMD többszálasítási a SMT... Nem véletlenül nyomatta sok évig az intel a 4/4, a 6/6 és a 8/8 szálasítás nélküli procikat. Remekül felismerte, hogy a többség amúgy is játszik a gépen, amihez tökéletes a 4-6-8 mag. Aztén valamikor a 9-10-ig generációban kénytelen volt visszahozni a többszáluságot, mert más alkalmazásban tarthatalan volt, ahogy egy 16 -24-32 szálas AMD asztali proci hülyére veri teljesítményben az inteleket, ha sok magos és szálas alkalmazást kellett futattni. Ezért kénytelen volt nyitni a több száluság fele, hiszen a világ nem csak játékból áll. De a HT hátrány most i meg van az SMT-vel szemben.
-
Robitrix
senior tag
azért ha megszaporodnak a hibrid magok, akkor az meg fog jelenni a fordító programokban is. Utána csak annyi a dolga a fejlesztőnek, hogy mikor fordítja az alkalmazást bekapcsolja az optimalizálást a hibrid felépítésre. Bár ennek valami olyasmi előfeltételét látom, hogy magának a programozónak kéne valamilyen módon minősíteni adott program szálat, hogy milyen erőforrás igényű az adott program ág. Például valamilyen bejegyzéssel a programág elején az adatoknál. Például egy direktívával, ami megmondaná, hogy adott programszál az alacsony, közepes vagy magas erőforrás igényes. Ami valahogy belefordulna a gépi kódba, amit aztán a rendszer erőforrás ütemezője tudna kezelni és akkor igyekezne a nagy számítás igényű program szálat a gyors magokra rakni a kisebb prioritásúakat meg a normál magokon használni. Elvégre legoptimálisabban mégis csak a program fejlesztője tudja megbecsülni, hogy a programja melyik része mennyi teljesítményt igényel. persze tehetné azt is, hogy minden programágat magas prioritással lát el, de akkor lehet magával baxna ki, mert lehet, hogy a kis teljesítményt igénylő programágat akarná ráerőltetni a gyors magra a rendszer és a nagy teljesítményűt a gyengébb magra. A másik megoldás meg az volna, hogy a rendszer figyelné a futás elindulása után, hogy melyik programág mennyi időt használ futásra, amiről készitene egy statisztikát, ahol minősíti maga a program ágak erőforrás igényét. majd egy idő után ez alapján probálná meg összehozni a magok teljesítményét a programszálak igényével. A dolog hátránya, hogy kell némi idő mire előáll futásközben egy használható teljesítmény statisztika és nem biztos, hogy minden programszálra egyből sor kerül és annak minden teljesítmény igénylő része neki áll futni. Simán lehet olyan programot irni, ami elindit egy feladatra valami program szálat majd valami feltétel teljesülése esetén máshogyan számol más részét használva a programágnak egy másik feltétel esetén meg megint mást csinál. Mondjuk kétféle adat beérkezése esetén eltérő dolgot kell vele elvégezni. Az egyikhez sokat kell számolni a másikhoz kevesebbet. Így nem biztos, a rendszer által készitett statisztika pontos lesz. Jobb megoldás ha a program készítő maga határozza meg melyik program ág fog sokat számolni és melyik keveset...... Ki a fene tudná nála jobban, mint aki irta a programot?
-
Robitrix
senior tag
hát pont ezt csinálják a program magokat és szálakat legjobban kihasználó mivel ugyan azt a programot futtatják gyakorlatilag minden lehetséges program magon és szálon csak persze eltérő adatokat feldolgozva. ilyenek, a tömöntések, videó feldolgozások. rendérélésék, titkosítások stb. Más felől viszont az átlagos program nem ennyire szétosztható teljesítmény igény alapján. Lesz olyan program ág ami annyit fut, hogy megszakad és lesz olyan ami csak néha ugrik be egy kicsit edzeni a CPU-n.
Főleg egy olyan alkalmazásban, mint például egy játék program. Hiszen annak eldöntése, hogy adott pillanatban mi futhat mi mellet és melyik programágnak kell várni egy másik eredményére meglehetősen kaotikus és véletlen szerű mert esemény vezérelt.
Hibá irok egy játékot arra, hogy mikor tűzet nyit a játékos akkor elindul egy külön programszál arra, hogy kiszámolja a leadott lővés eredményét. Hasba lövöm túl éli az ellenség, vagy surolja a lövés vagy miszlikre robban a feje, mert fejbe találom stb. Semmit nem ér a külön kiszámolás program ág, ha nem nyit tűzet az játékos a célra. Nyilván nem állhatok neki kiszámolni egy le se adott lövés következményét, mert foglamam sincsen hová fog pontosan lőnni a játékos. ezért is nem lehet egy játék program tökéletesen optimalizálva a magokra és szálakra. Hiszen nehezen tervezhető a pontos futás és az események előre. Ezért is ingadozik azért erősen a játék közben használt magok és szálak száma illetve a szüksége idő a futáshoz. Egy játék program nehezen optimalizálható és előre jósolható. -
Robitrix
senior tag
nem igazán tudod hardveresen megoldani a vezérlést. Hiszen ma annak eldöntése, hogy egy adott program valamelyik program ága melyik mag melyik szálán kap futásra időszeletet kizárólag az rendszer erőforrás ütemezője dönti el. Tehát az, hogy adott pillanatban egy programnak fut 4 párhuzamos program szála, hogy az a következő időszeletben éppen melyik mag melyik szálára kerül. Ezt jelenleg kizárólag maga a windows(vagy más operációs rendszer dönti el) Ez az erőforrás ütemező feladata. a rendszer felügyelete alatt futnak a programok Ellenkező esetben ha maga az alkalmazás akarná eldönteni, hogy ő hol fut a totális káoszhoz vezetne. Kell egy "főnök", aki irányit és rendet tart a rakoncátlan folyamatok és szálai közt.
Nem ott kezd neki futni egy programszál, ahol neki eszébe jut, hanem ahová a főnök elküldi. Te mész a 2-es magra, te a 6-osra és a 8-asra, te mész a 1-es és a 5-ös magra. te harmadik a következő időszeletben kapsz egy lehetőséget a 7-es magon. A maradék magokon meg fut a következő pillanatban ez a három rendszer folyamat egy-egy folyamata. Mindenki másnak kuss van és pihi és várja, hogy sorra kerül, ha kap lehetőséget. ÉN vagyok a fönök és az lesz, amit én mondok. aki nem engedelmeskedik azt kibaszom a rendszerből, mint a macskát szarni.
Na kb ez zajlik csak kevéssé szines módon. Tehát nem lehet magára a programra bizni, hogy ő hol szeretne futni. ha minden program a saját feje után menne akkor pillanatok alatt anarchia lenne a rendszerben. -
Robitrix
senior tag
Egyértelműen megfigyelhető, hogy minél több magot és szálat használ egy CPU, annál inkább csökken a használható órajel nagysága. Oka, hogy minnél több magot zsúfolnak össze fajlagosan egyre kisebb területre egyre megoldhatatlanabb a hatékony hűtése. Nem mindegy, hogy egy egy gyufásdoboznyi felületen 8 magot hűtenek vagy 24-32 magot. Muszáj visszafogni az órajelet egyre inkább a hőtermelés miatt. Jó példa, hogy pár évvel ezelőtti világ leggyorsabb számítógépe kínai volt, amihez egy egyedi tervezésű 262 magos procit használtak. egy olyan proci már csak 1,4 ghz-en tudott működni. A második helyen levő amcsi gépben hagyományos szerver procikat használtak a grafikus gyorsítók mellett úgy 500 ezer magot. Persze azok képesk volta 3 Ghz-3,2 Ghz környékén is menni. (talán 16 magos cpu-k voltak benne valami AMD szerver proci) A kínai gép mégis gyorsabb volt összteljesítményben mivel kapott 10,16 millió magot. Vagyis a 16 magos proci tudott azért 3 ghz környékén futni. (lehetett hüteni még) a 262 magos proci már csak maximum 1,4 Ghzen futott.
-
Robitrix
senior tag
valami hasonlót csinálnak az ARM-os android eszközök. Amig kicsi az igény a 4 kisbb órajelű és teljesítményű magot használjál, ahogy sokat kell számolni belépnek a magasabb órajelű gyorsabb magok is. De ennek oka nem a teljesítmény, hanem a fogyasztás optimalizálása. Spórolni kell az aksival, ha nem akarja az ember 6 óránként tölteni a telefont.
Új hozzászólás Aktív témák
ph A cég javarészt kisebb teljesítményű magokkal tömi ki az alacsonyabb fogyasztású termékskálát.
- Konzolokról KULTURÁLT módon
- Kiszivárgott egy lista a várható Lunar Lake modellekről
- Bestbuy játékok
- NieR: Automata™
- Google Pixel topik
- Redmi Note 12 4G - valaki fizetni fog
- Ősszel jönnek az új Intel chipek
- Anglia - élmények, tapasztalatok
- Ubuntu Linux
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- További aktív témák...
