Curiosità sulla RAM e processori!

[DadeJoker88]

Puntualizzazione obbligatoria: Al momento tutti i processori dei terminali Android sono ARM, quindi appartenenti alla famiglia RISC (Reduced Instruction Set Computer).
Cosa vuol dire? Vuol dire, in parole povere, che un processore da 1.7 gigaHz per pc non ha niente a che vedere - in termini di quello che riesce a fare un processore RISC da 1.7 gigaHz.
Quella che in termini impropri è indicata come "la velocità della cpu" è soltanto la frequenza di un certo segnale che serve a sincronizzare e a dare una cadenza alle operazioni che la CPU svolge, ma non si hanno reali informazioni da questo valore su "quanto" calcolo svolga una singola operazione, né su quanti colpi di clock servano per una singola operazione.

Un esempio terra terra, per spiegare il concetto: devi eseguire la moltiplicazione 30*60 su una CPU architettura x86 e una ARM, poniamo il caso abbiano la stessa frequenza di clock.
Supponiamo (per assurdo, è solo un esempio) che la CPU x86 conosca l'operazione "moltiplicazione", e sia in grado di svolgerla in 2 cicli di clock.
La CPU ARM, invece, non è in grado di eseguire moltiplicazioni, ma conosce l'istruzione "somma", per cui ripete sessanta volte la somma di 30, e supponiamo che ogni somma richieda un ciclo di clock per essere eseguita.
Per eseguire lo stesso calcolo, quindi, saranno necessari 60 cicli di clock.
In questo esempio, quindi, pur avendo la stessa frequenza di clock la CPU "desktop" è 60/2=30 volte più veloce della CPU, a pari frequenza, mobile.

E' un esempio campato per aria, dato che entrambi i processori conoscono un'operazione semplice come la moltiplicazione, però quello che realmente accade è questo - che i processori ARM conoscono pochissime istruzioni, e sanno fare in fretta quelle, ma per svolgere compiti "complessi" devono mettere insieme - come dei mattoncini - singole operazioni, arrivando a richiedere parecchio più tempo a parità di frequenza di clock rispetto alle CPU "per computer".
Spero di aver reso l'idea.

Detto questo, e capito quindi che in realtà le CPU che vediamo non sono poi così tanto sovradimensionate, bisogna anche tener presente che Android è un sistema operativo che definire anarchico è dir poco.
Ogni processo, ogni task, ogni activity si sveglia e fa "qualcosa" quando gli piace, andando a finire che, inevitabilmente, si va a creare un bottleneck da qualche parte, rendendo "lento", anche solo per pochi istanti il sistema.
Questo bottleneck, a partire dalle CPU dual core, è di solito da cercare più nella memoria "fisica" (la flash in cui è contenuto il sistema) che nella potenza di calcolo in sé, tuttavia, dato che "non fa figo", cose come la latenza della flash e la velocità di lettura e scrittura, oltre che la capacità del micro-controller di gestire accessi concorrenti, sono abbastanza trascurate.
E ci ritroviamo con smartphone del calibro dell'S3 che inevitabilmente laggano alla terza applicazione installata che cerca di sincronizzarsi.

Discorso a parte merita la RAM.
Android è vorace in termini di memoria, tende a espandersi finché può mettendo applicazioni e qualsiasi altra cosa gli capiti a tiro in memoria, per riuscire ad abbassare i tempi di risposta evitando di passare dalla - di solito lenta - memoria flash.
Dato che il motore sotto è Java, le applicazioni Android hanno la sgradevole tendenza di occupare più memoria di quanta ci si aspetterebbe - non è raro vedere applicazioni banali occupare memoria nell'ordine dei megabyte.
Avere tanta memoria quindi risulta effettivamente un buon modo per migliorare l'esperienza utente, come peraltro dimostrato dall'evoluzione degli smartphone negli ultimi anni - la gestione della RAM sui terminali come il Magic o il Dream era disastrosa nelle ultime versioni del sistema operativo del robottino verde, perché, fisicamente, non ci stava tutto il sistema - e dalla 2.3 in poi con meno di mezzo giga di ram si fa davvero fatica a far girare qualche applicazione.
Ricordo anche però di aver letto, ai tempi del Dual, un articolo su XDA in cui si dimostrava che aumentare la RAM portava Android a più frequenti accessi in memoria per cercare qualcosa da cachare, e in generale finiva per rallentare le operazioni per una gestione più macchinosa del sistema.
A spanne, direi che già con 1giga di RAM, oggi, siamo arrivati a una situazione in cui "basta". Ci stanno un po' di applicazioni cachate, c'è spazio per il sistema e basta lo spazio da dedicare all'activity aperta dall'utente.
Vedremo nel prossimo futuro, e in particolare con la 5.0, se verranno introdotte novità nella gestione della RAM, tali da giustificare ulteriori aumenti.

Nel mentre, riassumendo, spero in SoC che non alzino semplicemente la velocità di clock della CPU o la quantità di ram per ragioni di marketing, ma risultino equilibrate nei componenti evitando bottleneck più nascosti, e rimango in attesa di novità in ambito "gestione di tutto questo casino hardware" da parte di Google.

Ma5t3r, ti ringrazio sentitamente per questa spiegazione..mi è stata molto utile!! :-)

[diego63]

Puntualizzazione obbligatoria: Al momento tutti i processori dei terminali Android sono ARM, quindi appartenenti alla famiglia RISC (Reduced Instruction Set Computer).
Cosa vuol dire? Vuol dire, in parole povere, che un processore da 1.7 gigaHz per pc non ha niente a che vedere - in termini di quello che riesce a fare un processore RISC da 1.7 gigaHz.
Quella che in termini impropri è indicata come "la velocità della cpu" è soltanto la frequenza di un certo segnale che serve a sincronizzare e a dare una cadenza alle operazioni che la CPU svolge, ma non si hanno reali informazioni da questo valore su "quanto" calcolo svolga una singola operazione, né su quanti colpi di clock servano per una singola operazione.

Un esempio terra terra, per spiegare il concetto: devi eseguire la moltiplicazione 30*60 su una CPU architettura x86 e una ARM, poniamo il caso abbiano la stessa frequenza di clock.
Supponiamo (per assurdo, è solo un esempio) che la CPU x86 conosca l'operazione "moltiplicazione", e sia in grado di svolgerla in 2 cicli di clock.
La CPU ARM, invece, non è in grado di eseguire moltiplicazioni, ma conosce l'istruzione "somma", per cui ripete sessanta volte la somma di 30, e supponiamo che ogni somma richieda un ciclo di clock per essere eseguita.
Per eseguire lo stesso calcolo, quindi, saranno necessari 60 cicli di clock.
In questo esempio, quindi, pur avendo la stessa frequenza di clock la CPU "desktop" è 60/2=30 volte più veloce della CPU, a pari frequenza, mobile.

E' un esempio campato per aria, dato che entrambi i processori conoscono un'operazione semplice come la moltiplicazione, però quello che realmente accade è questo - che i processori ARM conoscono pochissime istruzioni, e sanno fare in fretta quelle, ma per svolgere compiti "complessi" devono mettere insieme - come dei mattoncini - singole operazioni, arrivando a richiedere parecchio più tempo a parità di frequenza di clock rispetto alle CPU "per computer".
Spero di aver reso l'idea.

Detto questo, e capito quindi che in realtà le CPU che vediamo non sono poi così tanto sovradimensionate, bisogna anche tener presente che Android è un sistema operativo che definire anarchico è dir poco.
Ogni processo, ogni task, ogni activity si sveglia e fa "qualcosa" quando gli piace, andando a finire che, inevitabilmente, si va a creare un bottleneck da qualche parte, rendendo "lento", anche solo per pochi istanti il sistema.
Questo bottleneck, a partire dalle CPU dual core, è di solito da cercare più nella memoria "fisica" (la flash in cui è contenuto il sistema) che nella potenza di calcolo in sé, tuttavia, dato che "non fa figo", cose come la latenza della flash e la velocità di lettura e scrittura, oltre che la capacità del micro-controller di gestire accessi concorrenti, sono abbastanza trascurate.
E ci ritroviamo con smartphone del calibro dell'S3 che inevitabilmente laggano alla terza applicazione installata che cerca di sincronizzarsi.

Discorso a parte merita la RAM.
Android è vorace in termini di memoria, tende a espandersi finché può mettendo applicazioni e qualsiasi altra cosa gli capiti a tiro in memoria, per riuscire ad abbassare i tempi di risposta evitando di passare dalla - di solito lenta - memoria flash.
Dato che il motore sotto è Java, le applicazioni Android hanno la sgradevole tendenza di occupare più memoria di quanta ci si aspetterebbe - non è raro vedere applicazioni banali occupare memoria nell'ordine dei megabyte.
Avere tanta memoria quindi risulta effettivamente un buon modo per migliorare l'esperienza utente, come peraltro dimostrato dall'evoluzione degli smartphone negli ultimi anni - la gestione della RAM sui terminali come il Magic o il Dream era disastrosa nelle ultime versioni del sistema operativo del robottino verde, perché, fisicamente, non ci stava tutto il sistema - e dalla 2.3 in poi con meno di mezzo giga di ram si fa davvero fatica a far girare qualche applicazione.
Ricordo anche però di aver letto, ai tempi del Dual, un articolo su XDA in cui si dimostrava che aumentare la RAM portava Android a più frequenti accessi in memoria per cercare qualcosa da cachare, e in generale finiva per rallentare le operazioni per una gestione più macchinosa del sistema.
A spanne, direi che già con 1giga di RAM, oggi, siamo arrivati a una situazione in cui "basta". Ci stanno un po' di applicazioni cachate, c'è spazio per il sistema e basta lo spazio da dedicare all'activity aperta dall'utente.
Vedremo nel prossimo futuro, e in particolare con la 5.0, se verranno introdotte novità nella gestione della RAM, tali da giustificare ulteriori aumenti.

Nel mentre, riassumendo, spero in SoC che non alzino semplicemente la velocità di clock della CPU o la quantità di ram per ragioni di marketing, ma risultino equilibrate nei componenti evitando bottleneck più nascosti, e rimango in attesa di novità in ambito "gestione di tutto questo casino hardware" da parte di Google.

Ottimo discorso condotto in modo molto comprensibile

[DadeJoker88]

Questo bottleneck, a partire dalle CPU dual core, è di solito da cercare più nella memoria "fisica" (la flash in cui è contenuto il sistema) che nella potenza di calcolo in sé, tuttavia, dato che "non fa figo", cose come la latenza della flash e la velocità di lettura e scrittura, oltre che la capacità del micro-controller di gestire accessi concorrenti, sono abbastanza trascurate.
E ci ritroviamo con smartphone del calibro dell'S3 che inevitabilmente laggano alla terza applicazione installata che cerca di sincronizzarsi.

Qualcuno potrebbe spiegarmi meglio questo passaggio? scusate l'ignoranza/inesperienza

[-DM-]

Puntualizzazione obbligatoria: Al momento tutti i processori dei terminali Android sono ARM, quindi appartenenti alla famiglia RISC (Reduced Instruction Set Computer).
Cosa vuol dire? Vuol dire, in parole povere, che un processore da 1.7 gigaHz per pc non ha niente a che vedere - in termini di quello che riesce a fare un processore RISC da 1.7 gigaHz.
Quella che in termini impropri è indicata come "la velocità della cpu" è soltanto la frequenza di un certo segnale che serve a sincronizzare e a dare una cadenza alle operazioni che la CPU svolge, ma non si hanno reali informazioni da questo valore su "quanto" calcolo svolga una singola operazione, né su quanti colpi di clock servano per una singola operazione.

Un esempio terra terra, per spiegare il concetto: devi eseguire la moltiplicazione 30*60 su una CPU architettura x86 e una ARM, poniamo il caso abbiano la stessa frequenza di clock.
Supponiamo (per assurdo, è solo un esempio) che la CPU x86 conosca l'operazione "moltiplicazione", e sia in grado di svolgerla in 2 cicli di clock.
La CPU ARM, invece, non è in grado di eseguire moltiplicazioni, ma conosce l'istruzione "somma", per cui ripete sessanta volte la somma di 30, e supponiamo che ogni somma richieda un ciclo di clock per essere eseguita.
Per eseguire lo stesso calcolo, quindi, saranno necessari 60 cicli di clock.
In questo esempio, quindi, pur avendo la stessa frequenza di clock la CPU "desktop" è 60/2=30 volte più veloce della CPU, a pari frequenza, mobile.

E' un esempio campato per aria, dato che entrambi i processori conoscono un'operazione semplice come la moltiplicazione, però quello che realmente accade è questo - che i processori ARM conoscono pochissime istruzioni, e sanno fare in fretta quelle, ma per svolgere compiti "complessi" devono mettere insieme - come dei mattoncini - singole operazioni, arrivando a richiedere parecchio più tempo a parità di frequenza di clock rispetto alle CPU "per computer".
Spero di aver reso l'idea.

Detto questo, e capito quindi che in realtà le CPU che vediamo non sono poi così tanto sovradimensionate, bisogna anche tener presente che Android è un sistema operativo che definire anarchico è dir poco.
Ogni processo, ogni task, ogni activity si sveglia e fa "qualcosa" quando gli piace, andando a finire che, inevitabilmente, si va a creare un bottleneck da qualche parte, rendendo "lento", anche solo per pochi istanti il sistema.
Questo bottleneck, a partire dalle CPU dual core, è di solito da cercare più nella memoria "fisica" (la flash in cui è contenuto il sistema) che nella potenza di calcolo in sé, tuttavia, dato che "non fa figo", cose come la latenza della flash e la velocità di lettura e scrittura, oltre che la capacità del micro-controller di gestire accessi concorrenti, sono abbastanza trascurate.
E ci ritroviamo con smartphone del calibro dell'S3 che inevitabilmente laggano alla terza applicazione installata che cerca di sincronizzarsi.

Discorso a parte merita la RAM.
Android è vorace in termini di memoria, tende a espandersi finché può mettendo applicazioni e qualsiasi altra cosa gli capiti a tiro in memoria, per riuscire ad abbassare i tempi di risposta evitando di passare dalla - di solito lenta - memoria flash.
Dato che il motore sotto è Java, le applicazioni Android hanno la sgradevole tendenza di occupare più memoria di quanta ci si aspetterebbe - non è raro vedere applicazioni banali occupare memoria nell'ordine dei megabyte.
Avere tanta memoria quindi risulta effettivamente un buon modo per migliorare l'esperienza utente, come peraltro dimostrato dall'evoluzione degli smartphone negli ultimi anni - la gestione della RAM sui terminali come il Magic o il Dream era disastrosa nelle ultime versioni del sistema operativo del robottino verde, perché, fisicamente, non ci stava tutto il sistema - e dalla 2.3 in poi con meno di mezzo giga di ram si fa davvero fatica a far girare qualche applicazione.
Ricordo anche però di aver letto, ai tempi del Dual, un articolo su XDA in cui si dimostrava che aumentare la RAM portava Android a più frequenti accessi in memoria per cercare qualcosa da cachare, e in generale finiva per rallentare le operazioni per una gestione più macchinosa del sistema.
A spanne, direi che già con 1giga di RAM, oggi, siamo arrivati a una situazione in cui "basta". Ci stanno un po' di applicazioni cachate, c'è spazio per il sistema e basta lo spazio da dedicare all'activity aperta dall'utente.
Vedremo nel prossimo futuro, e in particolare con la 5.0, se verranno introdotte novità nella gestione della RAM, tali da giustificare ulteriori aumenti.

Nel mentre, riassumendo, spero in SoC che non alzino semplicemente la velocità di clock della CPU o la quantità di ram per ragioni di marketing, ma risultino equilibrate nei componenti evitando bottleneck più nascosti, e rimango in attesa di novità in ambito "gestione di tutto questo casino hardware" da parte di Google.

Quello che dici è vero ma in realtà oggi gli x86 non sono più CISC, mantengono il set di istruzioni x86 per compatibilità ma hanno della logica di riconducimento alle istruzioni reali delle nuove cpu
È poi vero che cmq i processori x86 per tanti motivi sono comunque molto più veloci dei ARM (superacalari con pipeline out of order quando gli arm stanno andando in quella direzione solo dai cortex a9 per certi versi)

Per la potenza hai ragione e si chiama IPC, andava di moda anche su pc anni fa trollare gli acquirenti
Su smartphone va ancora meglio, l'utente medio non capisce niente e si vede dai commenti di alcuni che non si capacitano di come un dual core a15 bastoni un quad a9

[-DM-]

Qualcuno potrebbe spiegarmi meglio questo passaggio? scusate l'ignoranza/inesperienza

Vuol semplicemente dire che pompano sul numero di core ma non sulle prestazioni della memoria del telefono
Il collo di bottiglia é in termini IT il punto critico di un sistema HW che di fatto determina le prestazioni massime

Tu pensa ad una cosa, supponi un ufficio, ci sono gli scaffali con dei documenti da elaborare

Hai tante persone che elaborano i testi e li firmano, ma hai solo 1 tonto che li mette a posto sugli scafali (o li prende)
La lentezza con cui prende i fogli e va ai ripiani e lo fa possiamo dire che è la latenza della memoria interna (del controllore in realtà), il tempo che li posa è la velocità

La cosa rende male ma il senso è quello, su pc con gli ssd macchine lente possono sembrare più reattive di pc pompati ma con hdd proprio per quel motivo