2011-12-23 8 views
7

Ho un Android application che utilizza NDK per eseguire una grande quantità di matematica in virgola mobile.Prestazioni matematiche in virgola mobile Android

Ho appena acquistato un nuovo Galaxy Nexus. Con mia sorpresa, la mia app esegue MOLTO più lentamente del dovuto. Sospetto che ciò avvenga perché la maggior parte dei dispositivi utilizza l'accelerazione hardware e il Galaxy Nexus no. Se eseguo un'operazione che non richiede la matematica in virgola mobile, il Galaxy Nexus esegue come mi aspetterei.

Qui ci sono le specifiche CPU/GPU e le temporizzazioni dei campioni per diversi dispositivi. Ho normalizzato le statistiche di prendere in considerazione la risoluzione del display:

Droid 
CPU: TI OMAP 3430 (ARM Cortex-A8 600 MHz underclocked to 550 MHz) 
GPU: PowerVR SGX530 
Instruction Set: ARMv7 
Test Run: 1,980 pixels per second 

Galaxy Nexus 
CPU: TI OMAP 4460 (ARM Cortex-A9 dual-core 1.2 GHz) 
GPU: PowerVR SGX540 
Instruction Set: ARMv7 
Test Run: 2,253 pixels per second 

Droid Incredible 
CPU: QSD8650 (Qualcomm Snapdragon 1 GHz) 
GPU: Adreno 200 
Instruction Set: ARMv7 
Test Run: 4,571 pixels per second 

Ho questa configurazione nel mio Application.mk di file:

APP_ABI := armeabi armeabi-v7a 

non ho ri-compilato la mia codice con NDK-R7, ma Non capisco perché questo farebbe una differenza così drammatica. Qualche idea su cosa sia sbagliato?

+0

potresti quantificare "MOLTO più lento"? – WarrenFaith

+0

@WarrenFaith Ho aggiornato la domanda con i numeri reali. – dbyrne

risposta

5

Si potrebbe provare a utilizzare APP_ABI := armeabi-v7a per forzare l'uso solo delle istruzioni v7a.
Potrei immaginare che la nuova CPU non venga rilevata come supporto delle istruzioni v7a e che quindi il codice no-FPU sia utilizzato in runtime come fallback.

+0

Questo ha funzionato. Tuttavia, questo è piuttosto deprimente, perché ora non ho modo di mettere sul mercato un'app supportata da tutti i telefoni. Odio postare due diverse applicazioni solo per questo. – dbyrne

+0

Personalmente ho esaminato la direzione del rendering per la compatibilità. E non solo per supportare diversi tipi di CPU, ma anche per il supporto multiprocessore facile da implementare e l'utilizzo possibile della GPU. – harism

+1

È possibile includere diverse versioni di una libreria nativa all'interno della stessa app; ricorda che le librerie sono caricate _at runtime_ attraverso il tuo codice Java. Forse è possibile eseguire il rilevamento FPU all'interno della tua app, ad es. come [descritto qui] (http://stackoverflow.com/questions/8161184/detecting-fpu-presence-on-android), quindi caricare la lib nativa corrispondente. – JimmyB

0

Penso che il problema è che ci sono 2 core nel processore. Quindi, hai 600 Mhz per un core. Quindi se il tuo metodo matematico usa solo un thread, questa può essere una risposta. Anche se, non capisco perché è 2 volte più lento (il tempo comparabile può essere spiegato).

+0

Ho visto un telefono commercializzato come "2 GHz" quando in realtà era un telefono dual-core da 1 GHz, ma vi assicuro che il Galaxy Nexus ha due processori da 1.2 GHz. – dbyrne

+0

Hai ragione: Galaxy Nexus ha 1.2 GHz proc. – Yury

+0

Hai sollevato un buon punto che dovrei multithread il mio codice di calcolo. Soprattutto perché sarebbe banale parallelizzarlo. – dbyrne

7

Questa domanda StackOverflow può essere la causa delle scarse prestazioni sul Galaxy Nexus: Galaxy Nexus - wrong CPU ABI being selected during install time.

Sembra un bug. L'ho testato anche creando un piccolo progetto usando il codice nativo e in effetti Galaxy Nexus sceglie la libreria sbagliata (armeabi invece di armeabi-v7a).

Ho segnalato questo errore allo http://code.google.com/p/android/issues/detail?id=25321, con il progetto di esempio allegato al bug. Per favore recitali per attirare l'attenzione degli ingegneri Android.

+0

Sì, questo è esattamente il problema. Ha recitato. – dbyrne