[Curiosità] Ottimizzazione software Apple vs Android

Buonasera:)

Apro questa discussione per chiedervi, per sapere quanto Apple agisce sulle ottimizzazioni per i vari prodotti iOS per farli funzionare in maniera così perfetta su un hardware così scarso, quando in Android per funzionare bene necessitano di un Quad Core. Non capisco.

Google ha delle buone ottimizzazioni:

-Project butter con jelly bean: Ottimizzata CPU multicore, e lavoro sincronizzato tra CPU e GPU
-project svelte con kit kat: Ottimizzato il codice per arrivare a essere installato su Device con 512Mb di RAM per far si che anche i smartphone di fascia bassa ricevessero un aggiornamento e si riducesse la frammentazione.
-Project volta con Android L: cambio runtime da Dalvik ad Art, consentendo di far funzionare le app 4 volte più veloci e consumando meno batteria richiedendo più tempo per installare le app e richiedendo anche più spazio per installare.


Android in sè è ottimizzato, perché le case produttrici non lo ottimizzano adattandolo perfettamente per lo smartphone che vogliono andare a vendere? Secondo me potremmo metterci anche un octa core, ma se il software non è ottimizzato a dovere qualche lag lo vedremo sempre.

So che google con i suoi Nexus mantenendo la UI Android Pura e ottimizzando i processori in dotazione, i suoi Nexus sono praticamente privi di inpuntamento, privi di lag, ottimizzati a dovere, ma ricordiamo che il Nexus 4 e 5 sono dotati però di quad-core.
Come fa Apple a far funzionare su un semplice Dual core? A che se 5s ha oltre il processore, un coprocessore in aiuto.

A me a questo punto viene il dubbio, mi viene da pensare che sia il mercato a indurre le case produttrici a installarci un quad-core anziché un dual core, perché noi consumatori ci fidiamo di più avere un processore quad core che un dual core straottimizato, a meno che la casa produttrice sia famosa per le ottimizzazioni che fa sui propri Device.


Ditemi cosa ne pensate voi, sono curioso della vostra opinione :)

La mia opinione?
Che si parla tanto di ottimizzazione, quando l'ottimizzazione c'entra poco o nulla ;).
Senza andare su materiale complicato, basta leggere Wikipedia: Ottimizzazione (informatica) - Wikipedia

Quote:

---

Anche se la parola "ottimizzazione" condivide la stessa base di "ottimo", è raro che il processo di ottimizzazione produca un sistema ottimo. Il sistema ottimizzato sarà tipicamente ottimo solamente in un senso. Uno può ridurre il tempo di esecuzione di un programma, ma al prezzo di consumare più memoria; oppure un programma può occupare meno memoria ma al prezzo della velocità di esecuzione. Non esiste una soluzione che "metta d'accordo tutti", cosicché il programmatore dovrà sapere quale strada perseguire. In più, il tentativo atto a rendere ottimo una parte del software è di solito più dispendioso rispetto ai benefici che si può ottenere. In questo modo il processo di ottimizzazione può essere saltato prima di trovare una soluzione completamente ottimale. Fortunatamente i più grandi miglioramenti arrivano sempre prima di questo processo.

---

Android è, per definizione, il contrario dell'ottimizzazione.
Le applicazioni girano sotto svariati livelli che le isolano dall'hardware, e già questo rende impossibile ottimizzare.
Più ti allontani, a livello applicativo, da quello che è il modo pensato di programmare, nel tentativo di ottimizzare, e più rendi il tuo codice schifoso e lento nell'immediato, e meno soggetto a migliorarsi con gli SDK successivi.
La buona programmazione, in Android, NON consiste nell'ottimizzare, consiste nel seguire la documentazione per utilizzare i metodi del sistema senza farsi le cose a mano ;).

Uscendo dal livello applicativo, Android è un sistema anarchico, in cui i processi vivono in concorrenza spietata.
È chiaro che ci sarà sempre una possibilità che qualcuno ti occupi il dispositivo di storage mentre devi leggere o scrivere, causando lag, ed è altrettanto chiaro che in un framework "chiuso" come quello Apple questo non possa succedere.

I produttori non fanno niente per ottimizzare il sistema, né esiste qualcosa che possono fare.
Esistono dei parametri da settare, quali lo scaling della CPU o le soglie di RAM in cui far intervenire il garbage collector, ma non si parla di ottmizzazione, si tratta di scegliere dei compromessi tra velocità / batteria / numero di applicazioni aperte in background.
Inoltre, alla base di tutta la piramide ci sono i driver, i quali possono avere si un certo grado di ottimizzazione o meno, ma il problema non è che non sono ottimizzati - è che spesso i driver sono proprio scritti male, non vanno a sfruttare funzionalità hardware che permetterebbero di risparmiare cicli di clock, hanno pezzi di codice che generano errori e che il processore deve perdere tempo a gestire etc. .

Tutto questo è comunque necessario: il budget per lo sviluppo software è risicato, le deadline sono stringenti sia per l'hardware che per il software, e il mercato se non sforni cose che sulla carta e dal nome fanno impallidire quelle della generazione precedente non ti compra il prodotto.
Basti guardare l'insuccesso del Nexus S, all'uscita considerato al pari perché il suo predecessore aveva processore con stessa frequenza mentre c'erano già in giro i dual core (LG Optimus Dual).

Il discorso iOs è completamente diverso, perché l'architettura è molto più "smooth" da gestire e i device sono pochi (e quindi il compilatore, e non i programmatori, ha maggior libertà di azione per applicare ottimizzazioni).
Con questo il costo di sviluppo di iOs è più alto di quello di Android, il sistema fa fatica a evolversi ora che deve affrontare la sfida di girare su un numero maggiore di dispositivi e le novità sono sempre "poche".
Non è un caso che si sia passati dal far gestire la memoria a mano dai programmatori (che si avvicina al concetto di ottimizzazione, in un certo senso) al farla gestire al sistema operativo, operazione costosa in termini di risorse e che può causare lag: bisogna abbassare i costi di sviluppo, rendere la vita facile agli sviluppatori di app e di dispositivi e intasare il mercato, altrimenti i competitor ti sbranano.

Sei un prof universitario o un programmatore? :)
Mi sembrava di essere a lezione quando il mio prof all'uni (che insegna C) ci parlava di garbate collector e anche tu l hai fatto :)


Bè comunque, forse ho sbagaliato, però per intenderci una casa produttrice, tipo la Samsung che mette nel mercato un device, dovrà scrivere i driver? Quindi nel scrivere i driver decentemente si può far ciclare meno la CPU come hai detto, quindi avendo performance nettamente migliori senza costo, quindi in questo casi si và a lavorare nel kernel Linux, a gestire le librerie del kernel che fanno interagire l hardware con il software e adattare il kernel per i consumi e performance. La settimana scorsa ho modificato il kernel Linux, l'ultima versione stabile per capirci per i pc, e l ho adattata al mio hardware per far si di avere qualcosa dal mio notebook sia in termini di performance che di risparmio energetico e poi ho compilato tutti i sorgenti.
Forse l'unica ottimizzazione che possono fare gli ingengeri è quella oltre a gestire i vari parametri di scaling, soglie per il garbage collector, schedulatori i/o. Un qualcosa, secondo me i programmatori la devono fare per migliorare le performance.

Quote:

---

Originariamente inviato da xenord

Sei un prof universitario o un programmatore? :)

---

Per ora sono uno studente, anche se sono in dirittura di arrivo (laurea magistrale in ing. informatica, se va bene laurea il 23 di questo mese, se va male a ottobre).
Ho comunque fatto un paio di tesi scrivendo applicazioni Android, programmato in Java in generale, fatto qualcosa per un azienda con l'SDK Titanium e faccio anche qualcosina per iOs.
Ah, e fatto tutore di C per qualche annetto :P.

Quote:

---

Originariamente inviato da xenord

Bè comunque, forse ho sbagaliato, però per intenderci una casa produttrice, tipo la Samsung che mette nel mercato un device, dovrà scrivere i driver? Quindi nel scrivere i driver decentemente si può far ciclare meno la CPU come hai detto, quindi avendo performance nettamente migliori senza costo, quindi in questo casi si và a lavorare nel kernel Linux, a gestire le librerie del kernel che fanno interagire l hardware con il software e adattare il kernel per i consumi e performance. La settimana scorsa ho modificato il kernel Linux, l'ultima versione stabile per capirci per i pc, e l ho adattata al mio hardware per far si di avere qualcosa dal mio notebook sia in termini di performance che di risparmio energetico e poi ho compilato tutti i sorgenti.

---

I driver li scrive principalmente chi produce componenti e SoC, quindi i vari produttori dei processori, chippini, schede video etc.
Samsung fa(ceva) anche SoC, e quindi si faceva in casa hardware e driver, con ottimi risultati.
Si, il mettere le mani sul kernel Linux è probabilmente simile a quanto fa chi sviluppa una ROM ;).

Quote:

---

Forse l'unica ottimizzazione che possono fare gli ingengeri è quella oltre a gestire i vari parametri di scaling, soglie per il garbage collector, schedulatori i/o. Un qualcosa, secondo me i programmatori la devono fare per migliorare le performance.

---

Queste cose sono settaggi più che ottimizzazione; per "ottimizzare" si intende proprio mettere le mani sul codice e riscrivere dei pezzi per migliorare un aspetto a scapito di un altro :p.
Aumentare performance != ottimizzare! ;)

Io sono al secondo anno di Ing. Informatica :)

Ma sei sicuro che se tipo ho la CPU qualcomm, è la qualcomm a scrivere i driver?
Per esempio il mio cellulare, ha Androd 2.3.6 Stock e non è stato aggiornato a Jelly Bean, ma molti sviluppatori hanno creato CyanoGenmod basate su jelly bean e kit kat, con fotocamera che funziona parzialmente, cioè funziona solo la camera e non il camcorder e il flash, e loro danno colpa alla Samsung che non ha creato il driver per quella versione di Android.

Quote:

---

Originariamente inviato da xenord

Io sono al secondo anno di Ing. Informatica :)

---

Bella ;)

Quote:

---

Originariamente inviato da xenord

Ma sei sicuro che se tipo ho la CPU qualcomm, è la qualcomm a scrivere i driver?
Per esempio il mio cellulare, ha Androd 2.3.6 Stock e non è stato aggiornato a Jelly Bean, ma molti sviluppatori hanno creato CyanoGenmod basate su jelly bean e kit kat, con fotocamera che funziona parzialmente, cioè funziona solo la camera e non il camcorder e il flash, e loro danno colpa alla Samsung che non ha creato il driver per quella versione di Android.

---

Non ho messo le mani direttamente nello sviluppo delle ROM, ma di solito chi ti vende un componente per dispositivi embedded include dei driver, che possono essere completi o meno.
Per componente intendo anche la fotocamera eh, poi sta al produttore mettere insieme e far funzionare il tutto se ci sono problemi.
Io ho "giocato" con delle schedine di un grosso produttore, e componenti come accelerometri e giroscopi MEMS; i driver dei componenti me li ha forniti il produttore, ma c'erano parti da sistemare, delle inizializzazioni mancanti e, nel caso dei driver del giroscopio, delle funzioni importanti con il commento //TODO ;).

Tieni presente che i driver dei componenti embedded non sono come i driver per PC, ci sono diverse dipendenze tra un file e l'altro, dato che alla fine è il SoC che gestisce più o meno direttamente quasi tutte le componenti.
Se è come immagino, a Samsung arrivano, assieme ai componenti scelti, dei driver, sotto forma di codici sorgenti o di oggetti già compilati; Samsung li integra in una versione del kernel Linux, risolve i conflitti, fa funzionare il tutto possibilmente sfruttando al meglio le funzionalità del SoC presenti, e alla fine, quando arriva ad avere un kernel che funziona, fa finalmente partire Android, con tutto l'ambaradam di bloatware proprietario.
Di ottimizzabile in tutto questo non c'è niente, ma è chiaro che se lavori male in questa fase tutto quello che c'è sopra andrà male.

Tutto questo è più o meno la rappresentazione mentale che ho riguardo al creare una ROM, ma se c'è qualcuno che ci ha messo le mani direttamente ben venga essere smontato ;).

Quote:

---

Originariamente inviato da Ma5t3r

La mia opinione?
Che si parla tanto di ottimizzazione, quando l'ottimizzazione c'entra poco o nulla ;).
Senza andare su materiale complicato, basta leggere Wikipedia: Ottimizzazione (informatica) - Wikipedia



Android è, per definizione, il contrario dell'ottimizzazione.
Le applicazioni girano sotto svariati livelli che le isolano dall'hardware, e già questo rende impossibile ottimizzare.
Più ti allontani, a livello applicativo, da quello che è il modo pensato di programmare, nel tentativo di ottimizzare, e più rendi il tuo codice schifoso e lento nell'immediato, e meno soggetto a migliorarsi con gli SDK successivi.
La buona programmazione, in Android, NON consiste nell'ottimizzare, consiste nel seguire la documentazione per utilizzare i metodi del sistema senza farsi le cose a mano ;).

Uscendo dal livello applicativo, Android è un sistema anarchico, in cui i processi vivono in concorrenza spietata.
È chiaro che ci sarà sempre una possibilità che qualcuno ti occupi il dispositivo di storage mentre devi leggere o scrivere, causando lag, ed è altrettanto chiaro che in un framework "chiuso" come quello Apple questo non possa succedere.

I produttori non fanno niente per ottimizzare il sistema, né esiste qualcosa che possono fare.
Esistono dei parametri da settare, quali lo scaling della CPU o le soglie di RAM in cui far intervenire il garbage collector, ma non si parla di ottmizzazione, si tratta di scegliere dei compromessi tra velocità / batteria / numero di applicazioni aperte in background.
Inoltre, alla base di tutta la piramide ci sono i driver, i quali possono avere si un certo grado di ottimizzazione o meno, ma il problema non è che non sono ottimizzati - è che spesso i driver sono proprio scritti male, non vanno a sfruttare funzionalità hardware che permetterebbero di risparmiare cicli di clock, hanno pezzi di codice che generano errori e che il processore deve perdere tempo a gestire etc. .

Tutto questo è comunque necessario: il budget per lo sviluppo software è risicato, le deadline sono stringenti sia per l'hardware che per il software, e il mercato se non sforni cose che sulla carta e dal nome fanno impallidire quelle della generazione precedente non ti compra il prodotto.
Basti guardare l'insuccesso del Nexus S, all'uscita considerato al pari perché il suo predecessore aveva processore con stessa frequenza mentre c'erano già in giro i dual core (LG Optimus Dual).

Il discorso iOs è completamente diverso, perché l'architettura è molto più "smooth" da gestire e i device sono pochi (e quindi il compilatore, e non i programmatori, ha maggior libertà di azione per applicare ottimizzazioni).
Con questo il costo di sviluppo di iOs è più alto di quello di Android, il sistema fa fatica a evolversi ora che deve affrontare la sfida di girare su un numero maggiore di dispositivi e le novità sono sempre "poche".
Non è un caso che si sia passati dal far gestire la memoria a mano dai programmatori (che si avvicina al concetto di ottimizzazione, in un certo senso) al farla gestire al sistema operativo, operazione costosa in termini di risorse e che può causare lag: bisogna abbassare i costi di sviluppo, rendere la vita facile agli sviluppatori di app e di dispositivi e intasare il mercato, altrimenti i competitor ti sbranano.

---

sbaglio o con art, che a quanto pare dovrebbe rendere più stabile il sistema android e avvicinarsi sempre più ad iOS, da qui a breve anche apple dovrà ravvedersi?

Quote:

---

Originariamente inviato da lelemcmxc

sbaglio o con art, che a quanto pare dovrebbe rendere più stabile il sistema android e avvicinarsi sempre più ad iOS, da qui a breve anche apple dovrà ravvedersi?

---

ART compila pezzi di bytecode in codice nativo, aumentando un po' le prestazioni rispetto all'interpretazione pura della Dalvik o alla compilazione in tempo reale di JIT.
Benvenga, ma non porta Android ad avvicinarsi ad iOs: rimangono due filosofie completamente diverse ;).

Quote:

---

Originariamente inviato da Ma5t3r

ART compila pezzi di bytecode in codice nativo, aumentando un po' le prestazioni rispetto all'interpretazione pura della Dalvik o alla compilazione in tempo reale di JIT.
Benvenga, ma non porta Android ad avvicinarsi ad iOs: rimangono due filosofie completamente diverse ;).

---

filosofie diverse perchè il codice di iOS viene compilato in maniera più diretta dalla macchina? potresti spiegarmi quale sarebbe la differenza? io sapevo che android è meno immediato nell'eseguire i processi in quanto utilizza dalvik (macchina virtuale) per eseguire e compilare parte del codice. su IOS come avviene il tutto?

Quote:

---

Originariamente inviato da lelemcmxc

filosofie diverse perchè il codice di iOS viene compilato in maniera più diretta dalla macchina? potresti spiegarmi quale sarebbe la differenza? io sapevo che android è meno immediato nell'eseguire i processi in quanto utilizza dalvik (macchina virtuale) per compilare ed eseguire parte del codice. su IOS come avviene il tutto?

---

A livello Android, più o meno, funziona(rà?) così:
-parte del codice viene interpretato direttamente dalla Dalvik;
-parte del codice viene compilato durante l'esecuzione (JIT compiler), e eseguito;
-parte del codice verrà compilato durante l'installazione dell'applicazione da ART.
In base a quanto è stato detto finora di ART, o quantomeno a quanto ho sentito, non verrà compilata l'intera applicazione, ma dei "pezzi" di codice.
Anche se si tratta di codice nativo, verrà comunque eseguito in qualche tipo di sandbox, probabilmente sarà lontano dall'efficienza di iOs.
In pratica, su Android rimani comunque ad un livello di astrazione più elevato, anche con ART.

A questo devi aggiungere che il compilatore per iOs ha più risorse (potenza e energia), e che lavora sul codice sorgente, mentre ART lavora con risorse limitate e con codice già compilato (bytecode).

Naturalmente ci sono delle speculazioni in questo, con il rilascio di L vedremo qualcosa di più ;)

Quote:

---

Originariamente inviato da Ma5t3r

A livello Android, più o meno, funziona(rà?) così:
-parte del codice viene interpretato direttamente dalla Dalvik;
-parte del codice viene compilato durante l'esecuzione (JIT compiler), e eseguito;
-parte del codice verrà compilato durante l'installazione dell'applicazione da ART.
In base a quanto è stato detto finora di ART, o quantomeno a quanto ho sentito, non verrà compilata l'intera applicazione, ma dei "pezzi" di codice.
Anche se si tratta di codice nativo, verrà comunque eseguito in qualche tipo di sandbox, probabilmente sarà lontano dall'efficienza di iOs.
In pratica, su Android rimani comunque ad un livello di astrazione più elevato, anche con ART.

A questo devi aggiungere che il compilatore per iOs ha più risorse (potenza e energia), e che lavora sul codice sorgente, mentre ART lavora con risorse limitate e con codice già compilato (bytecode).

Naturalmente ci sono delle speculazioni in questo, con il rilascio di L vedremo qualcosa di più ;)

---

capito, grazie!