Ha levédette a szabadalmat,akkor van terve vele. Max nem sikerül belőle piacképes terméket hoznia.
Amikor nincs remény! Jusson eszedbe nincs isten, csak én!
Ha levédette a szabadalmat,akkor van terve vele. Max nem sikerül belőle piacképes terméket hoznia.
Amikor nincs remény! Jusson eszedbe nincs isten, csak én!
Lásd: Heterogen Computing ?
"The Morru'Khan is not satisfied with your peformance"
Kérdés(ek), az egyik, ha pusztán a fogyasztást nézzük, nem jobb csökkenteni pusztán az órajelet? Akár nagyon-nagyon-nagyon. A másik, mi a helyzet az AMD-féle chiplet dizájnnal? Egy ilyen dolog működőképes lehetne amellett is.
Igen-igen, még mindig Win7-et használok, és ha így haladunk még 2030-ban is így lesz.
Nem, mivel az energia takarékos magok sok esetben kicsit máshogy is vannak tervezve szerintem.
Igen, asztali és noti fronton ennek az egésznek nem látom az értelmét... olyan szinten vissza tudnak már venni a mai procik, hogy itt minimális a lehetséges energia spórolás (a többi komponens fogyasztásához mérve).
Ráadásul ez is... oké, szuperül ment, vált a másik magra... és ez mennyit fog lassítani a futáson? (plusz a max teljesítmény azért is esni fog, mert a butított magok ilyen helyzetben várhatóan semmit sem fognak csinálni, hiszen nem támogatják a szükséges utasításokat... tehát nem fog hozzáadódni, csak majd a marketingesek asztalán persze kis csillagozással)
Tablet, telefon, ahol esetleg megéri, ott ez a kicsi spórolás is jó lehet, de a gyártóknak is lehettek kétségeik erről, azért is születtek Big.Little esetén olyanok, ahol ugyan azok a magok voltak mindkét kupacban, csak eltérő órajellel...
dobpergés... és az amd feltalálta a mobil procit
nemigazán értem, hova lenne ez jó, vagy megint megpróbálják az x86 android telefon/tablet vonalat?
okoskodom, tehát vagyok
Engem az erdekelne, hogyan tudja detektalni a nagy mag, hogy vissza lehet dobni a szalat a kicsi magra?
[ Szerkesztve ]
ha sok kódban a NOP utasítás
okoskodom, tehát vagyok
Nem feltétlen a tiedhez kapcsolódik, csak kb.
A Bulldozer jutott az eszembe. Megy az integer mag, csinálja amit kell, és ha befut egy FPU utasítás, akkor az kimegy a megfelelő helyre. Utána megy tovább az élet az integer ALUn, FPU pedig alszik.
Nem lehetne vmi ilyet csinálni, hogy a kakukktojás utasítást magát lefuttatja a nagyobb mag, neadjisten szimplán kiszervezett egység, aztán folytatódik minden ahol abba maradt?
pezo77 #5 2017.12.14. 13:29 Hmm. És ez az e-hajó akkor hol is tud kikötni? Az e-bay -ben? ;)
Annak az lenne a hátránya, hogy a már betöltött regisztereket és mindent másolni kéne a másik magra, egy csomó órajelciklust elpazarolva, ergo a végén több lenne az elpocsékolt teljesítmény, mint amennyit esetleg nyernénk rajta
Gondolom én, ugyanúgy ahogy a frekvenciaszabályozás is meg van oldva C és P state-kel.
Mondjuk 2000 MHz alatt nem a 1800 MHz jön, hanem a kisebb magra migrálás. Persze a váltás mondjuk 10 ms-ént lenne ellenőrizve, tekintve hogy a L1 cache és egyebek migrálása is sok időt és energiát vesz igénybe.
Érdekes az lenne, ha ezt a működést teljesen elrejtenék az operációs rendszer elől. Maximum beállíthatod a battery módot, ahol csak a light magok vannak használva.
[ Szerkesztve ]
-
Egyébként egy ilyen mezei folyamatábrát is le lehet szabadalmaztatni?
Kb ebben semmi eredeti sincs.
ha a microsoft a duplaclicket le tudta, vagy az apple a téglalapot...amerikában mindent lehet
okoskodom, tehát vagyok
Még nézegettem itt, hogy a saját rendszeremen mi hogy fogyaszt. Üresjáratban a CPU 11-13W között mozgott, egerészés/böngészés közben felment 16W-ig is, emellett a memória 20% terheltség mellett 9-10W körül fogyasztott. 30%-os terhelés mellett a CPU 35-50W között mozgott, a memória 80%-os terheltség mellett 13-15W között. Míg a CPU változtatta az órajelét, a memória (DDR3 2133-as) állandó órajelen üzemelt és üzemel és ez minden gépnél így van. Nos ha már fogyasztáscsökkentés, akkor nem lenne érdemesebb a rendszermemória órajelét ugyanúgy vezérelni, mint pl a VGA memóriája órajelét, ha nincs terhelés visszavenni egy alapállapotra, ha kell akkor meg visszaemelni a beállított szintre. Meghatározni egy olyan fix memória profilt, feszültség, órajel, késleltetésértékekkel, amin biztosan stabilan üzemel. Jó ettől még lehet a CPU-t is diétára fogni, de a rendszerben vannak más komponensek, amiknek a fogyasztása csökkenthető lenne, ami által az egész rendszeré is.
Valahogy nehezen veszi be a gyomrom ezt a megközelítést. A Lakefield 4 kis magja kb akkora mint az egy nagy, de a 4 mag összesített teljesítménye nem éri el az egy magét. Lehet hogy összességében a fogyasztásra pozitív hatással van, spórolunk vele 20%-ot, de a tranzisztorszám/teljesítmény mutatója már rosszabb, azaz tranzisztort pazarlunk. Inkább akkor építsenek be az eszközbe 20%-al nagyobb akkumulátort.
Igen-igen, még mindig Win7-et használok, és ha így haladunk még 2030-ban is így lesz.
túl gyorsan végez a számítással és várni kell a memóriákra (l2-3 cache, esetleg, ram)
A bortól bolondokat gondol az ember, DE A PÁLINKÁTÓL MEG IS CSINÁLJA!!!
Na igen, az a könnyű része, hogy jön egy olyan utasítás, amit csak a nagy tud, akkor átdobni rá, de vissza... lehet, hogy onnantól marad a nagyon az adott szál?
Terhelés csökkenés is lehet, amit a többiek írnak, de az meg sok dobálást okozhat, ha nem konstans a terhelése az adott szálnak, viszont a hiányzó utasításra meg mindig szüksége van, amikor van számolni valója.
Duck663: Az még egészen sokat eszik akkor. Nekem a kis gép, Celeron 1610-el, minimális terheléssel (netet oszt, letöltés), konnektorból mérve benéz 20W alá... és ebben proci, alaplap, memória, 2 SSD, egy plusz hálókártya egy gigabites switch (a gépből kapja az áramot), 3 darab 12-es venti és a táp hatásfoka is benne van. Ebből a procinak nem sok jut ilyenkor... 5W fölé nem tippelném... ha a két normális mag helyett két kis mag dolgozik benne, akkor mennyivel kevesebb ez? 5 helyett 4W? Ez a teljes rendszerre nézve kemény 5% megtakarítás, nagyobb chip méret mellett, és rengeteg probléma árán... és közben a chipsetet meg legyártják hozzá nagyobb csíkszélességen, mert annak az is jó alapon, és ennek a többszörösét elbukják azon ...szóval ez nagyon olyan iránynak néz ki, mint amit sokan mondanak most az autók kapcsán, hogy iszonyatos költségek árán faragják le a károsanyag kibocsájtásukat, aminek az össz szennyezésre minimális a hatása, miközben más területeken nagyságrenddel kisebb befektetéssel összességében sokkal többet javíthatnának a helyzeten. (Amit írsz is, lehetne faragni a memóriákon, de a chipset részen is.)
azta... hol tart már a technika meg az amd fejlesztési tudománya...
2020-ban feltalálták azt a módszert, ahogy anno a koproci emulátorok futottak a régi procikon...
le a kalappal... rotfl.
azért az is elgondolkodtató, ha erre lehetett szabadalmi védettséget kapni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Ha megnezed az abrat, akkor 4-essel kezdodik, ami arra utal, hogy ez a negyedik abra, azaz elotte van meg 3 (amik valoszinuleg nagyobb ivuek, ez egy kifejtese lehet azok egy reszenek). De amugy nagyon nagy vonalakban, ha megfelelsz az alabbi kriteriumoknak: legyen ujdonsagtartalma, ne legyen trivialisan kovetkeztetheto meglevo dolgokbol es ne legyen elotte semmilyen formaban publikalva, akkor igen, gyakorlatilag egy workflow siman mehet a szabadalmi hivatal ele. A 3. pontom az ellenorizheto, a 2. az ertelmezes kerdese, az 1. meg nagyban fugg attol, hogy a biralo aznap milyen labbal kelt fel
[ Szerkesztve ]
Ashy Slashy, hatchet and saw, Takes your head and skins you raw, Ashy Slashy, heaven and hell, Cuts out your tongue so you can't yell
"Ráadásul ez is... oké, szuperül ment, vált a másik magra... és ez mennyit fog lassítani a futáson?"
Nyilván az elhagyott mag terheléséből tudjuk, hogy milyen sebességű magra tehető át az adott program szál. Ha a terhelés növekszik, amúgy is menne vissza egy gyorsabb magra.
Ennek a megoldásnak nem feltétlenül az energia takarékosság a lényege.
Ha tartalmaz olyan magokat a processzor, ami túlhatva is alulmúlja a gyors mag energiatakarékos fogyasztását, akkor másodlagos teljesítmény veszteség nélkül lehet a gyors mag(ok)hoz rendelni, magasabb hőtermelési keretet.
Sőt megnyithatja az utat az ARM magok integrálásához. Olyan olyan utasítások esetében amikor az ARM processzor sokkal (energia vagy sebesség) hatékonyabban teljesít, kihasználható lehetne a képessége.
Legyen béke! Menjenek az orosz katonák haza, azonnal!
az arm binárisok nem futnak x86-amd64 architektúrán.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Maga a váltási idő, ha nem egyszer vált át, hanem oda-vissza pakolja a szálat, az mennyit lassít... erről írtam.
Ha nem energia takarékosság, akkor meg semmi értelme, a kisebb magokat ez esetben el is lehetne hagyni.
Az ARM-ot meg bambano közben írta is... már az is rengeteg problémát vet fel, hogy eltérő képességű magokat pakoljanak így össze, hát még ha nem csak pár utasítás megléte a különbség, hanem kompletten más architektura... ( aztán ha megcsinálják valahogy, komoly szoftveres támogatással, mert anélkül nem fog menni, na abból mennyi biztonsági rés jön majd létre... )
"Maga a váltási idő, ha nem egyszer vált át, hanem oda-vissza pakolja a szálat, az mennyit lassít... ": ugyanannyit, mint ha az ütemező nem ugyanarra a procimagra ütemezi vissza a programot.
számomra az a kérdés, hogy a fordító majd tudni fogja, hogy mikortól nem használ extra utasításokat, és akkor berak egy egyedi utasítást a programba, hogy mostantól ütemezze vissza little magra a kódot? a másik irány egyszerűbb, ha a little mag ráfut egy olyan utasításra, amit csak a big mag tud, akkor dob egy trap-et vagy kivételt, és az oprendszer lekezeli, hogy másik procira ütemezze a processzt.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
En is ezt akartam kerdezni. Ennyi erovel minden dolog levedheto, meg a levego meg a viz is. Az USA-ban tenyleg nagy a sotetseg.
Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.
Maga a szabadalom legalább három, alapvetően különböző lehetőséget tárgyal a heterogén processzormagok közös cache elérésére. Már csak ebből is látszik, hogy nem célirányos a szabadalom, erősen valószínűtlen, hogy terméket akarnának rá építeni. Viszont az Intel most indult el ebben az irányban, és az AMD saját birtokába vette az egyik (mármint három) lehetséges problémakezelési, illetve fejlesztési módot.
A vérem piros. A sznoboké kék. Zöld a szörnyeké. avagy "Én annyira nagyon irigyellek téged, hogy beszélhetsz velem."
"Maga a váltási idő, ha nem egyszer vált át, hanem oda-vissza pakolja a szálat, az mennyit lassít... "
Már ma is dobálgatják a programszálakat a magok között.
Egyetlen mag sem léphet át egy kritikus hőmérsékletet. Négy mag esetén nem engedhető meg, hogy egy mag túlmelegedjen, míg a többi három malmozzon "hidegen".
A mai sokmagos processzorok esetében nem mindegy, hogy melyik magra kerül az egymagos túlhajtás. Ha nem a legjobban hajtható magra kerül a programszál, akkor alul fog teljesíteni a processzor.
Az ARM integrálás nem annyira lehetetlen dolog.
Az x87 lebegőpontos processzorok óta ismerjük a megoldást.
Legyártunk egy új utasítást. Ehhez tartozik egy x64 processzor kompatibilis gépi kódú utasítás sorozat. Ha nincs segédprocesszor, akkor végrehajtódik a x64 utasítás sorozat. Ha van segédprocesszor, akkor végrehajtandó utasítás azonosítóját és a szükséges adatokat megkapja a segédprocesszor. Az eredmény visszaérkezéséig várakozik a program szál. Mind a két esetben.
Nem az a cél, hogy ARM app futhasson. Az a cél, hogy a gyorsabban futhasson a x64 program.
Legyen béke! Menjenek az orosz katonák haza, azonnal!
Dobálgatja, de azonos magok között... és ma is gyorsabb, ha lefixálod egy adott magra az adott szálat.
Az ARM kompletten másik architektura, nem csak egy pár másik utasítás amit az x64 nem ismer... ott a cache, ott a memória például... nem lehetetlen, csak éppen bonyolult és költséges.