Lo ritengo un builder di buon livello. Curioso che tu me lo abbia chiesto, perchè m3dd0g è un esempio particolarmente interessante che raccoglie in se 3 variabili in una botta sola e che comparirà nel terzo capitolo...
Visualizzazione stampabile
diciamo che gli piace sviluppare su dispositivi diversi, quando ottiene un buon lavoro su uno, allora è pronto a provarne un altro! Però facendo il furbetto , chiedendo il contributo agli utenti, con la scusa di ricomprarsi il dipostivo rotto, ma poi alla fine cambia prodotto e bye bye. Peccato che si faccia una cattiva reputazione visto le sue doti, ormai lo conoscono tutti per queste furbate. Se avesse chiesto un contributo per sostenere lo sviluppo, sarei stato il primo a sostenerlo, ma inventare sempre la stessa scusa non ha senso!
Proprio così. Se uno legge i suoi commenti nel thread, non appena è andato all'IFA 2014 a Berlino e ha visto il Note4 se ne dev'essere innamorato e, per coincidenza, subito dopo ha scritto un post dicendo di aver rotto il suo OPO. Purtroppo per lui, prima ancora che qualcuno aprisse una colletta, Capitanuncino (che scrive anche in questo forum) lo ha messo subito in croce.
Una delle tre variabili è appunto l'affidabilità di chi costruisce la ROM...
si ho letto la storia sul forum oneplus. Peccato per questa variabile, la sua rom mi piaceva molto! Chissà che fine ha fatto? sul suo trhead su xda non ha più commentato!
La installi facendo solo wipe dalvik e cache. Quindi flashi la ROM e le gapps
buongiorno a tutti e al maestro, rotfl
in attesa spasmodica del fine settimane per il motivo che Bokonon ben sa :cool:, non è troppo chiedere anche una "guida" ai Governor per permettere a noi adepti di imparare ed evitare entusiasmi figli di effetti placebo o ns allucinazioni appena proviamo un governor nuovo?
con estrema devozione e rispetto
un salutone
No, perchè non ho le competenze. E' un argomento che non ho ancora esplorato a fondo perchè mi attrae poco.
I concetti di fondo però sono semplici. Usiamo un esempio artefatto con un'unica CPU che arriva al massimo ad 1Ghz.
L'obiettivo è minimizzare i consumi mantenendo al contempo un buon livello di fluidità e performance.
Se dico alla CPU di viaggiare sempre a 1Ghz ho il massimo consumo (e usura) ma anche la massima reattività.
Oppure posso dirgli di spegnersi quando non utilizzato e passare direttamente a 1Ghz non appena serve (=boost). Risparmio sicuramente energia rispetto a prima ma non è certo la soluzione ottimale.
Allora uso la testa e mi dico Perchè non creo una regola per cui il processore al massimo usa la metà della potenza e passa ad un 1Ghz solo quando scattano certi requisiti in base alla richiesta di carico? Questo è un primo passo e si chiama scaling della CPU. Quindi quando è idle va a zero. Appena viene richiesta potenza di calcolo scatta a mezzo Ghz e ci resta fintanto che viene utilizzata. Se poi c'è bisogno di più potenza la CPU passa ad un Ghz e poi torna indietro.
A questo punto però mi chiedo se non posso fare di meglio..e invece di impostare solo due scaling e ne provo 3,4,5,6,7,8,9 o 10. E guardo i consumi medi. Alla fine scopro che averne 4 è più ottimale che averne 10 dato che i consumi sono pressochè identici e la fluidità è migliore perchè la CPU non fa una miriade di scaling continuamente. Ed ecco che ho indivduato il miglior scaling per quella CPU: diciamo che creo un set di regole per cui la CPU funziona da 0 (deepsleep) /300Mhz/700Mhz/1Ghz a seconda della richiesta di potenza (=ondemand).
Fantastico, adesso ho trovato un compromesso fra consumi/performance e fluidità che migliora di molto rispetto alle scelte precedenti.
Posso ancora migliorarlo? Certo, potrei pensare ad un set di regole più efficiente per lo scaling e poi potrei impostare valori che migliorano e massimizzano l'utilizzo in lettura dando delle priorità allaCPU (=row) oppure favorire sia lettura che la scrittura (=deadline).
Questo sotanzialmente è un governor ondemand. Partendo da questo uno può sviluppare delle varianti oppure cambiare totalmente approccio (=set di regole) e crearne uno nuovo tipo come l'interactive: quest'ultimo consuma un po' di più ma è più fluido (non entro nei dettagli perchè trovate facilmente le descrizioni di tutti i governor con Google).
Tutto questo ragionamento viene poi riapplicato a seconda del numero di CPU (posso pensare di inserire regole non simmetriche per sfruttare ogni singola CPU o delle coppie in modo diverso l'una dall'altra), della loro massima velocità (inserendo più livelli di scaling) e in base alla caretteristiche specifiche di una data CPU (un Qualcomm è diverso da un Exynos e addirittura cambia da revision a revision).
Potrei anche aggiungere un sistema per eliminare la latenza quando risveglio il cell dal deesleep (=hotplug).
Insomma, ci sono una marea di variabili e di possibilità. E' opinione comune che l'interactive sia il miglior governor per il nostro OPO (e anche in generale) ma ogni developer ha la sua filosofia e ogni user ha diverse esigenze.