[TOPIC UFFICIALE] Quale ROM per il mio Galaxy Ace? Consigli e Confronti

Ciao a tutti, è da un pò di tempo che uso la rom di bieltv.3... ma il mio cellulare è rallentato di molto, ci mette molto ad aprire un app... mi potete dire una rom 4.2.2 veloce e fluida? Grazie a tutti ...
P.S. : ho visto che bieltv.3 ha rilasciato una nuova versione (RC4).. per aggiornare a quella rom come devo fare? Perdo i dati? Grazie a chi risponderà!

Usa la cm10.1 di maclaw studio o la aok di utaker3

Quote:

---

Originariamente inviato da Sheldon97

Leggevo anche io questo fatto della mezza compilazione, ma mi spieghi una cosetta??
Le app per android sono "scritte in java"
Il linguaggio java per essere eseguito deve seguire un iter: scrittura del codice sorgente, compilazione e relativa generezione del bytecode, interpretazione del bytecode da parte di una macchina virtuale che genera il codice eseguibile in linguaggio macchina.
OK
Android con relativa dalvik funzionavano così. Giusto?? No ancora mi son perso un passaggio...
Ora. Stanno introducendo LA art (a mio avviso come LA dalvik, in quanto sono LE macchine virtuali) e hanno parlato di semi-compilazione. Ma di cosa? Come? Si riferiscono al bytecode? Ma quello non è già compilato per essere eseguito dalla macchina virtuale? Semi compilazione direttamente verso il linguaggio macchina? Ma non andremmo contro "l'idea di java" della portabilità? A sto punto fanno prima ad affiancare l'assembly al java(cazzata immane, lo so XD)
Sono confuso, se qualcuno riesce a spiegarmi è bene XD


Si ma anche ai devs non funziona -.-" è quello il problema XD


1.confermo :) una bella aosp decente, a meno che la cm 11(??) non la fanno davvero bene (ogni riferimento alla cm10.2 è puramente intenzionale)
2.confermo che maclaw non mi piace e non ero nemmeno entusiasta delle sue ROM (siamo stati molto senza una cm9 buggata aggiustata solo dopo da wayland)
3.ma io sto altius non lo conosco nemmeno...
4.Armv8?? Davvero?? Questa me l'ero persa o.O
5.fai bene XD Passa ai nexus, abbiamo i biscotti :P



Il buon vecchio ace <3 credo che nessuno di noi lo possa di menticare, nemmeno quando avremo i telefoni incorporati nel cervello XD
PS. che per caso hai un pollo a cui vendere il mio di ace?? XD

---

Direttamente verso linguaggio macchina si, vai contro al Java, si, ma ci vai contro anche adesso perchè il dex è interpretato per arm. L'assembly è inusabile! Per fare anche cose semplici ci metti moltissimo! Per non parlare del debug!, Semmai un buon sostituto è il C, veloce e potente. Forse il problema è che per molti è complicato

Quote:

---

Originariamente inviato da Sheldon97

Ah è vero, l'audio, ehm, l'Apple a7 è a 64 bit. Vabbé ma relativamente ad android non penso che li vedremo molto presto in giro (eccetto che sul nuovissimo galaxy perché Samsung può) perché non hanno un supporto del sistema operativo valido ed andrebbero a sfruttare solo le istruzioni a 32 bit (tanto alla Samsung non importa) e non penso proprio che google, che dice che kitkat è più leggero ed adatto anche ai telefoni non troppo performanti, si metta a complicarlo a tal punto (a meno che non rilasci due versioni, a 32 e 64 bit, anche questa per me da scartare).
Che comunque anche apple mi deve spiegare sta trovata dei 64 bit. Davvero porta miglioramenti al sistema? Anzi, meglio, davvero il sistema sfrutta 64 bit? Mi sembra un po' strano che la Apple, che fino ad adesso ha usato dual core e un giga di RAM, se ne esca con un processore a 64 bit.... (*coff*marketing*coff*)
Può anche darsi, visto che il sistema operativo e la maggior parte dei software li produce lei stessa, ma mi interesserebbe saperne di più

---

Be, android non andrebbe riscritto per garantire la compatibilità ai 64bit, il grosso è infatti scritto in C-C++ indipendenti dalle architetture (e quindi anche dalle dimensioni dei registri della cpu) quindi basta aggiungere qualche flag a gcc e arriva il binario a 64 bit. Il problema è forse la parte scritta in assembly che andrebbe riscritta. Per quanto riguardo l'utilità, i numeri "long" e "double" hanno dimensioni di 64bit, tutta l'aritmentica di questi numeri quindi è molto più veloce.

Quote:

---

Originariamente inviato da Apotheosys

Quando lanciano una moda non c'è niente da fare, anche se i vantaggi sono tecnicamente inesistenti l'utente comune crede che 64 bit siano meglio. E poi ricorda che le architetture a 32 bit supportano al massimo 4 GB di RAM... Quando la crescita esponenziale renderà i 4 GB obsoleti, le architetture a 64 bit diventeranno d'obbligo.
It's not my fault, it's the market baby.


Inviato dal mio Nexus 7 usando Androidiani App

---

Come ho detto sopra i 64 bit aumentano molto le performance dell'aritmetica dei "long"-"double", si è vero i calcoli nei numeri a virgola mobile sono eseguiti dalla VFP tuttavia anche questa è aumentata nell'armv8. Che poi non è solo l'aritmetica che migliora, pensate a un algoritmo di compressione, lavorare un blocchi di 64bit è il doppio di 32bit, si lavora con il doppio dei dati alla volta! Altro esempio, analisi di un header di un file!, faccio tutto molto più veloce!. Chiaramente non cambia il mondo perchè la velocità di ram e flash è quella che è.

Quote:

---

Originariamente inviato da Apotheosys

Di sicuro adesso più suo 2 GB di RAM sono un'esagerazione, ma come l'Htc Dream montava (se non sbaglio) 128 MB di RAM e a quel tempo era impensabile che si potesse arrivare anche solo a mezzo giga, l'economizzazione dell'hardware porta a software sempre più funzionale ma tuttavia più esoso di risorse. Una via (quella di KitKat) è l'ottimizzazione che porta all'efficienza (prestazioni migliori a parità di hardware), l'altra è l'acefalo incremento delle prestazioni (ma è il più usato, poiché aggiungere un altro banco di RAM è più semplice che ottimizzare migliaia di righe di codice, e dà risultati migliori anche dal punto di vista del marketing).
Man mano che il tempo passa, android si evolverà, rendendo obsoleti anche 4 giga e obbligando il passaggio ad architetture a 64 bit.


Inviato dal mio Nexus 7 usando Androidiani App

---

Qui quoto tutto, anche per i pc è la stessa cosa, windows ha bisogno di 4-8gb con linux giro con massimo un gb usato.

@mm7 linux dipende quale distro, e soprattutto quale ambiente grafico... (In realtà io noto differenze anche da Wayland a Xorg.. Con netto vantaggio del primo, ma tralasciamo il server grafico)
Con ambiente grafico Unity io ho circa 1,5 GB occupati, con LXDE le cose cambiano, e molto.
E poi tra parentesi io ho un portatile con 2 GB di RAM e su win 7 ha sempre circa 1,5 occupato, è la velocità che cambia.


Inviato dal mio Nexus 7 usando Androidiani App

Quote:

---

Originariamente inviato da Apotheosys

Di sicuro adesso più suo 2 GB di RAM sono un'esagerazione, ma come l'Htc Dream montava (se non sbaglio) 128 MB di RAM e a quel tempo era impensabile che si potesse arrivare anche solo a mezzo giga, l'economizzazione dell'hardware porta a software sempre più funzionale ma tuttavia più esoso di risorse. Una via (quella di KitKat) è l'ottimizzazione che porta all'efficienza (prestazioni migliori a parità di hardware), l'altra è l'acefalo incremento delle prestazioni (ma è il più usato, poiché aggiungere un altro banco di RAM è più semplice che ottimizzare migliaia di righe di codice, e dà risultati migliori anche dal punto di vista del marketing).
Man mano che il tempo passa, android si evolverà, rendendo obsoleti anche 4 giga e obbligando il passaggio ad architetture a 64 bit.


Inviato dal mio Nexus 7 usando Androidiani App

---

Non metto in dubbio che sia giusto seguire questa via, ma è ancora troppo presto!! Al momento dico io, con android che va benissimo su 2 giga e ios su 1, mettere un 64 bit per poter aumentare la RAM non ha molto senso, se non puramente di marketing. Ovviamente se poi i 64 bit portano altri benefici è un altro conto, solo dico che, al momento, non ne vedo il bisogno

Quote:

---

Originariamente inviato da mm7

Direttamente verso linguaggio macchina si, vai contro al Java, si, ma ci vai contro anche adesso perchè il dex è interpretato per arm. L'assembly è inusabile! Per fare anche cose semplici ci metti moltissimo! Per non parlare del debug!, Semmai un buon sostituto è il C, veloce e potente. Forse il problema è che per molti è complicato

---

Mmm, vedi alcune cose me le ero perse... Capito, quindi sarebbe un po' più vicino alla macchina, credo di aver compreso.
Noooo l'assembly l'ho detto era una cazzata, solo per fare una somma ci vuole la mano di Cristo (non abbiamo ancor iniziato a scrivere ma con tutti i registri mi sto sparando. E stiamo facendo l'8086!!)
Si in effetti il C sarebbe una valida alternativa, però c'è il problema appunto che è in po' più complicato e "scoraggerebbe" una parte di sviluppatori

Quote:

---

Be, android non andrebbe riscritto per garantire la compatibilità ai 64bit, il grosso è infatti scritto in C-C++ indipendenti dalle architetture (e quindi anche dalle dimensioni dei registri della cpu) quindi basta aggiungere qualche flag a gcc e arriva il binario a 64 bit. Il problema è forse la parte scritta in assembly che andrebbe riscritta. Per quanto riguardo l'utilità, i numeri "long" e "double" hanno dimensioni di 64bit, tutta l'aritmentica di questi numeri quindi è molto più veloce.

---

Vedi anche queste cose mi sono perso XD beh si la parte in c non avrebbe problemi, quella in assembly sarebbe da adattare. No non metto in dubbio che i 64 bit portino vantaggi, dico solo che attualmente non mi sembrano indispensabili

Quote:

---

Come ho detto sopra i 64 bit aumentano molto le performance dell'aritmetica dei "long"-"double", si è vero i calcoli nei numeri a virgola mobile sono eseguiti dalla VFP tuttavia anche questa è aumentata nell'armv8. Che poi non è solo l'aritmetica che migliora, pensate a un algoritmo di compressione, lavorare un blocchi di 64bit è il doppio di 32bit, si lavora con il doppio dei dati alla volta! Altro esempio, analisi di un header di un file!, faccio tutto molto più veloce!. Chiaramente non cambia il mondo perchè la velocità di ram e flash è quella che è.

---

Il problema è: chi è che si mette a fare calcoli enormi con dei double o si mette a comprimere 50 giga con il telefono? A limite porterebbero ad un'evoluzione dei tablet che ingloberebbero sempre più utilizzi dei PC, ma ribadisco: io parlo solo di tempi troppo immaturi, dell'inutilità in questo momento

Quote:

---

Qui quoto tutto, anche per i pc è la stessa cosa, windows ha bisogno di 4-8gb con linux giro con massimo un gb usato.

---

Si infatti, se non ottimizzi il software usi la via più facile: aumenti l'hardware. Il problema è che con i PC lo puoi fare tranquillamente, con i telefoni ti va giù la batteria a bestia

Quote:

---

Originariamente inviato da Apotheosys

@mm7 linux dipende quale distro, e soprattutto quale ambiente grafico... (In realtà io noto differenze anche da Wayland a Xorg.. Con netto vantaggio del primo, ma tralasciamo il server grafico)
Con ambiente grafico Unity io ho circa 1,5 GB occupati, con LXDE le cose cambiano, e molto.
E poi tra parentesi io ho un portatile con 2 GB di RAM e su win 7 ha sempre circa 1,5 occupato, è la velocità che cambia.


Inviato dal mio Nexus 7 usando Androidiani App

---

Io uso debian con gnome (server=xorg, sinceramente non conosco wayland, ne avevo solo sentito parlare) e ottengo questi risultati. Unity fa schifo, ubuntu stesso è uno schifo è normale usi 1,5gb. Per quanto riguarda windows io con meno di 4gb in 7 soffro (per quel poco che lo uso).

Quote:

---

Originariamente inviato da mm7

Io uso debian con gnome (server=xorg, sinceramente non conosco wayland, ne avevo solo sentito parlare) e ottengo questi risultati. Unity fa schifo, ubuntu stesso è uno schifo è normale usi 1,5gb. Per quanto riguarda windows io con meno di 4gb in 7 soffro (per quel poco che lo uso).

---

Per il fatto di windows confermo: mia zia ha win 7 home premium su 2 gb di RAM e il PC soffre a bestia
PS. Ma una volta ubuntu non era o GNOME o KDE?

gabbo (che la mano di cristo sia con noi allora xD --> [mov rax, 0x01; mov rbx, 0x01; add rax,rbx] :o:o), double-long servono nella parte grafica, rendering, algoritmi su grandi dati, appena si apre una apk la si decomprime!, se si usa la zram anche qui algoritmi a bestia. Secondo me è un miglioramento, non dico che sia necessario, giustamente un buon software ottimizzato è meglio, giustamente pero costa e nessuno si "accorge" che monta un software ottimizzato rispetto ai 40core

Quote:

---

Originariamente inviato da Sheldon97

Per il fatto di windows confermo: mia zia ha win 7 home premium su 2 gb di RAM e il PC soffre a bestia
PS. Ma una volta ubuntu non era o GNOME o KDE?

---

Unity è basato su gnome, si tempo fa c'era gnome (e kubuntu con kde se non sbaglio)

Quote:

---

Originariamente inviato da mm7

gabbo (che la mano di cristo sia con noi allora xD --> [mov rax, 0x01; mov rbx, 0x01; add rax,rbx] :o:o), double-long servono nella parte grafica, rendering, algoritmi su grandi dati, appena si apre una apk la si decomprime!, se si usa la zram anche qui algoritmi a bestia. Secondo me è un miglioramento, non dico che sia necessario, giustamente un buon software ottimizzato è meglio, giustamente pero costa e nessuno si "accorge" che monta un software ottimizzato rispetto ai 40core

---

AAAAAAA!!! Bellissimo assembly, per fare una somma del bip (censurato da dema121) (domanda: perché hai usato i registri rax e rbx? Io ero fermo ad ax e BX O.o)
Double-long servono per la parte grafica, ma a meno che le aziende non puntano a giochi un po' più sofisticati di ruzzle non ti serve tutta sta potenza (alcuni giochi più elaborati esistono va fanno ca... per colpa dei comandi troppo limitati)
Ah per compressione/decompressione intendevi quella ._. Io avevo pensato agli zip ._. So Nabbo forte eh XD
E comunque si, sul fatto che ne avrebbero molto vantaggio le aziende pagando di meno e facendo più colpo sono d'accordo, però se non si è notato sono un fan accanito dell'ottimizzazione del codice, colpa del mio prof di informatica, e che comunque al giorno d'oggi molto hardware non è sfruttato a pieno :/

Quote:

---

Unity è basato su gnome, si tempo fa c'era gnome (e kubuntu con kde se non sbaglio)

---

ah ecco quindi ricordavo vagamente bene :P

Quote:

---

Originariamente inviato da Sheldon97

AAAAAAA!!! Fottuto assembly, per fare una somma del cazzo (domanda: perché hai usato i registri rax e rbx? Io ero fermo ad ax e BX O.o)
Double-long servono per la parte grafica, ma a meno che le aziende non puntano a giochi un po' più sofisticati di ruzzle non ti serve tutta sta potenza (alcuni giochi più elaborati esistono va fanno ca... per colpa dei comandi troppo limitati)
Ah per compressione/decompressione intendevi quella ._. Io avevo pensato agli zip ._. So Nabbo forte eh XD
E comunque si, sul fatto che ne avrebbero molto vantaggio le aziende pagando di meno e facendo più colpo sono d'accordo, però se non si è notato sono un fan accanito dell'ottimizzazione del codice, colpa del mio prof di informatica, e che comunque al giorno d'oggi molto hardware non è sfruttato a pieno :/



ah ecco quindi ricordavo vagamente bene :P

---

Negli amd64 i registri ax, bx, cx, dx sono sostituiti da rax,rbx,rcx,rdx che sono a 64 bit. Si possono "chiamare" i primi 32 con eax,ebx...., i primi 16 con ax,bx,cx... e poi ah,al,bh,.... quindi in un certo senso ax,bx,cx,dx indicano solo il primo quarto del registro :D