Új hozzászólás Aktív témák
-
Reggie0
félisten
Nem lehetetlen NDK-val megcsinalni, de az Android alapbol nem igy megy. Az OS scheduler donti el a futas kozbeni parameterek alapjan, hogy melyik thread milyen magot kap (es azt is, hogy mi legyen a mag frekije), az app pedig azt se tudja, hogy processzoron fut-e, vagy egy kinai szamolja kockas fuzetben.
"Mármint papíron megfelelő teljesítményt, de vannak olyan problémák, amik csak akkor derülnek ki, amikor már elindult a munkamenet. "
A futo threadnek tud domaint valtani. A dinamikus frekvenciaallitas is igy megy, nem a threadek vagy a program mondjak meg, hogy na most nekem x MHz kell.
DinamIQ-nal pont emiatt vittek arra az iranyt, hogy a big es little magok parban vannak es osztott a memoriajuk, hogy ne az interconnect-et terhelje, mint a hagyomagyos big.little eseten.[ Szerkesztve ]
-
Reggie0
félisten
Szerintem nehez megmondani, hogy mi legyen a flageles, mivel annyifele proci van, hogy elegge horror lenne. Szerintem a ontanulo profilozas kell a schedulerbe(azaz el is menti a tapasztalatait, nem csak futasidoben hasznalja) es par glitch utan mar felismerheti a problemas appokat es azok taskjait.
De a dynamiq igazabol arra viszi az iranyt, hogy a domain switch olyan gyorsan tortenjen meg, hogy ne legyen gond ezt menet kozben intezni.
Aztan a masik erdekes temakor, ami az light appoknal erdekes igazan, az az energy aware scheduling. Itt mar nem csak a processzor tipusatol fugg az eredmeny, hanem a szilicium-lotto-tol is, ezt meg nehezebb lenne elore flagelni.
Az apple-nek az az elonye, hogy van kb 5-10 proci tipus ami parhuzamosan letezik es supportalt, ugy nem nehez megoldani. Foleg, hogy a dinamiq elhozta a magonkent frekiallitas lehetoseget(alap big.little eseten domainenkent lehetett).
[ Szerkesztve ]
-
Reggie0
félisten
válasz Dr. Akula #69 üzenetére
Sok a low cost task. Fogyasztasilag sokkal jobb sok kis magra szetszorni oket, mint egy nagy magon futtatni. Illetve ez igaz a nagyon jol parhuzamosithato feladatokra is, jobb sok kicsin szetszorni, mint par nagyon futtatni. Az eros mag ketfele tasknak kell: amelyikkel minel elobb kell vegezni vagy amelyik rosszul parhuzamosithato.
[ Szerkesztve ]
-
Reggie0
félisten
Pont az ellenkezoje van leirva:
"You can set Android N to permanently run the processor at lower clock speeds, reducing battery drain.
Android N has a sustained performance mode API that is guaranteed to run indefinitely at a lower performance level. While a fast peak performance is attainable on mobile, you cannot sustain it indefinitely due to heat and battery drain concerns."Amugy logikus, ha ki tudja a fejleszto optimalizalni a kodot alacsony fogyasztashoz, akkor a proci teljesitmeny ingadozas sem fog problemat okozni, mert onnan csak felfele tud ingadozni. Egy atlag telo meg a waze-tol is elizzik, nagyobb teljesitmenyt igenylo jateknal garantalt a trottyling, legfeljebb nehany gamingre optimalizalt es nem is tul szeles korben elterjedt telefont vagy tablet leszamitva.
[ Szerkesztve ]
-
Reggie0
félisten
"Nem mellesleg azért érdemes lenne megjegyezned, hogy 2/3/486 - mindegyikből az AMD csinálta a leggyorsabbat."
Miert lenne erdemes? Ezt az AMD mindossze pl. a 286-os proci inditasa utan 7 evvel erte el, addigra mar reg a 386-os ment az intel reszerol. Es ez sem a szuper AMD-s tervezoknek koszonheto, hanem annak, hogy az intel kezdetben 1500 majd 1000 nanometeren gyartott, mig az AMD a nagy kesese utan rogton 800 nm-en inditotta a gyartast. Azaz az eltelt ido technologiai fejlodeset vitte be, nem a csodalatos processzoroptimalizalo kepesseguk.
De a 386-osbol is a release utan 6 evvel tudta kihozni az AMD a 40 megas verziot, addigra mar 2 eves volt a 486.E
[ Szerkesztve ]