Si tratta di un confronto valido tra CPU CPU e CPU desktop (Android G1 vs vecchio desktop Pentium 4)?

Sì, il tuo desktop P4 sarà molto più veloce di un telefono cellulare.

Ero abituato a lavorare su un sistema operativo per telefoni cellulari. Questo era qualche anno fa, e stavamo usando CPU XScale e OMAP ARM, e avevamo anche un simulatore desktop che eseguiva lo stesso codice compilato per x86. Non l'ho mai misurato, ma 27x è certamente plausibile.

Ci sono un sacco di fattori coinvolti oltre alla velocità di clock della CPU, principalmente legata all'hardware. Le periferiche, la memoria, la velocità e l'architettura del bus sono biggies. Un altro è come viene costruito il silicio della CPU; Le CPU ARM sono in genere più semplici e non hanno caratteristiche di miglioramento delle prestazioni che si trovano nei chip x86 che aumentano i requisiti di potenza e le dimensioni dei chip.

In definitiva, devi fare misurazioni. E sì, questo tipo di lavoro incorporato spesso comporta "dolorose ottimizzazioni al codice per rendere le cose vivibili" per gli utenti finali. Questa è una grande ragione per cui gli sviluppatori ARM con esperienza sono molto richiesti nella Silicon Valley in questo momento - se hai già quelle capacità di ottimizzazione specializzate, molte persone ne hanno bisogno.

Aggiungerò un commento su "ottimizzazione prematura" del codice dello smartphone.

Quando stai facendo funzionare qualsiasi tipo di sistema embedded, devi scrivere il tuo codice con l'ottimizzazione nella parte posteriore della tua mente. Non è che tutto il codice che scrivi debba essere ottimizzato immediatamente, ma devi avere una buona idea di dove potresti avere problemi, e non dipingerti in un angolo dal punto di vista del design.

Generalmente si eseguono gli eseguibili incorporati su un desktop e li si trasferisce sul dispositivo, quindi il ciclo di build / test è di almeno un ordine di grandezza maggiore rispetto a un desktop, in quanto i risultati del più piccolo cambiamento di codice possono richiedere alcuni minuti. Inoltre, gli strumenti di profiling del codice sui dispositivi incorporati fanno davvero schifo se addirittura esistono.

Quindi non vuoi lasciare il tuning delle prestazioni fino all'ultimo sui dispositivi embedded. Se lo fai, e hai una scadenza, sei per un sacco di all-nighters, e forse completare il fallimento del progetto. Nei dispositivi embedded, il test delle prestazioni è analogo al test delle unità: deve passare la prima volta e devi continuare a testarlo in modo che le prestazioni non regrediscano.

Ci sono molte più prestazioni rispetto alla potenza di calcolo del numero di CPU, anche sugli algoritmi legati alla CPU. L'efficienza del compilatore (e dell'implementazione JVM se stai lavorando con Java, che probabilmente stai facendo su un telefono Android), la quantità di memoria disponibile e le dimensioni del bus, la dimensione delle cache del processore, ecc tutti i fattori in esso.

Se vuoi veramente sapere quanto veloce sarà il codice, prova a testarlo con il codice reale. Scrivere un algoritmo dispendioso in termini di tempo (l'ordinamento di bolle su un grande set di dati funziona bene) e compilare lo stesso codice su entrambe le piattaforme, quindi testare il tempo di esecuzione. Per un'immagine più completa, prova diversi algoritmi che eserciteranno diversi set di funzionalità.