Prestazioni ARM vs Thumb su iPhone 3GS, codice non a virgola mobile

Question

Mi chiedevo se qualcuno avesse qualche numero concreto sulle prestazioni del codice ARM vs Thumb su iPhone 3GS.Specificamente per il codice non in virgola mobile (VFP o NEON): sono a conoscenza dei problemi con le prestazioni in virgola mobile in modalità Thumb.

C'è un punto in cui la dimensione aggiuntiva del codice delle istruzioni ARM più grandi diventa un pericolo per le prestazioni?In altre parole, se il mio codice eseguibile è relativamente piccolo rispetto alla memoria disponibile, ce n'è misurato differenza di prestazioni rispetto all'attivazione della modalità pollice?

Il motivo per cui lo chiedo è che mentre posso abilitare ARM per i file sorgente specifici di NEON in Xcode utilizzando l'opzione "-marm", questo interrompe la build del simulatore perché GCC sta costruendo x86.Mi stavo chiedendo se dovrei semplicemente disattivare "compila come pollice" e farla finita.

Answer 1

Non so circa l'iPhone, ma una dichiarazione generale che il pollice è più lento di ARM non è corretto a tutti. Data 32 bit wide attesa nullo memoria stati, pollice sarà un po 'più lento, numeri come 5% o 10%. Ora, se è thumb2 che è una storia diversa, si dice che thumb2 può correre più veloce, non so quello che l'iPhone ha la mia ipotesi è che non è thumb2.
Se non si è a corto di memoria a 32 bit di zero-wait-state poi i risultati possono variare. Una grande cosa è la memoria a 32 bit di larghezza. Se si esegue su un bus ampio 16 bit come la famiglia GameBoy Advance, e ci sono alcuni stati di attesa su quella memoria o ROM, quindi pollice può facilmente fuori eseguire ARM per le prestazioni, anche se ci vuole più istruzioni pollice per eseguire lo stesso compito.

Prova il tuo codice! Non è difficile inventare un test che fornisce i risultati a cui è interessato o no. È facile mostrare braccio soffia via pollice come è pollice soffia via braccio. Chi se ne importa ciò che i dhrystones sono, è quanto velocemente ci si eseguire il codice OGGI che conta.

Quello che ho trovato nel corso degli anni in termini di prestazioni di codice di prova per ARM è che il codice e il compilatore sono il fattore importante. Quindi pollice è una piccola percentuale più lenta, in teoria, perché utilizza una piccola percentuale più istruzioni per peform lo stesso compito. Ma lo sapevate che il compilatore preferito potrebbe essere orribile e semplicemente passare compilatori è possibile eseguire diverse volte più veloce (gcc rientra in quella categoria)? O utilizzando lo stesso compilatore e mescolando le opzioni di ottimizzazione. In entrambi i casi è possibile ombra la differenza braccio / pollice da essere intelligente su come utilizzare gli strumenti. Probabilmente sapete questo, ma si sarebbe sorpreso di sapere quante persone pensano che l'unico modo che conoscono come compilare il codice è l'unico modo e l'unico modo per ottenere una migliore performance è gettare più memoria o altro hardware il problema.

Se si è su iPhone che sento queste persone stanno utilizzando LLVM? Mi piace il concetto LLVM in molti modi e sono ansioso di usarlo come il mio conducente quotidiano quando è matura, ma l'ho trovato per produrre codice che è stato il 10-20% (o più) più lento per il particolare compito che stavo facendo. Ero in modalità braccio, Non ho provato la modalità del pollice, e ho avuto una cache L1 e L2 on. Se avessi provato, senza le cache per confrontare veramente pollice per armare avrei probabilmente vedere il pollice una piccola percentuale più lenta, ma se si pensa di esso (che non ero interessato a al momento) è possibile memorizzare nella cache il codice pollice due volte tanto rispetto al codice braccio che potrebbe implicare che anche se c'è una piccola percentuale più codice complesso per l'attività, mettendo in cache in modo significativo più di esso e riducendo la media prendere pollice tempo può essere notevolmente più veloce. Forse dovrò andare provare questo.

Se si sta utilizzando LLVM, avete l'altro problema di più posti di eseguire ottimizzazioni. Andando da C in bytecode è possibile ottimizzare, quindi è possibile ottimizzare il bytecode stesso, è possibile quindi unire tutti i tuoi bytecode e ottimizzare che nel suo insieme, poi quando si va dal codice byte assembler è possibile ottimizzare. Se tu avessi solo 3 file di origine, e assunse c'erano solo due livelli di ottimizzazione per opportunità, quelli che sono Dont ottimizzare o non ottimizzare, con gcc si dovrebbe 8 combinazioni per testare, con LLVM il numero di esperimenti è quasi un ordine di grandezza superiore . Più che si può davvero funzionare, centinaia di migliaia. Per la prova di quello che stavo correndo, NON opimizing sulla C a passo bytecode, quindi NON ottimizzando il bytecode mentre separato, ma ottimizzando dopo la fusione i file bytecode in un unico grande (ger) uno. Il dover ottimizzare llc sulla strada per braccio prodotto i migliori risultati.

In basso la linea ... test, test, test.

EDIT:

Sono stato con la parola bytecode, penso che il termine corretto è codice binario che nel mondo LLVM. Il codice nei file .BC è quello che voglio dire ...

Se avete intenzione da C a ARM utilizzando LLVM, non c'è codice binario che (bc) nel mezzo. Ci sono opzioni da linea di comando per l'ottimizzazione sul C a bc step. Una volta bc è possibile ottimizzare per file, bc a bc. Se si sceglie è possibile unire due o più file bc bc in file più grandi, o semplicemente girare tutti i file in un unico grande file bc. Poi ognuno di questi file combinata può anche essere ottimizzato.

La mia teoria, che ha solo un paio di casi di test alle spalle fino ad ora, è che se non si fa alcuna ottimizzazione fino ad avere l'intero programma / progetto in un unico grande file bc, l'ottimizzatore ha il massimo se le informazioni con cui fare il suo lavoro. In modo che i mezzi andare da C a bc senza ottimizzazione. Quindi unire tutti i file bc in un unico grande file bc. Una volta che avete il tutto come un unico grande file bc poi lasciare che l'ottimizzatore di svolgere la sua fase di ottimizzazione, massimizzando le informazioni e, auspicabilmente, la qualità della ottimizzazione. Poi vai dal file bc ottimizzato per ARM assembler. L'impostazione predefinita per llc è con ottimizzazione on, si vuole permettere che l'ottimizzazione in quanto è l'unico passo che sa come ottimizzare per la destinazione. Il bc alle ottimizzazioni BC sono generici e non target specifico (per quanto ne so).

Hai ancora alla prova, prova, prova. Andare avanti e sperimentare con le ottimizzazioni tra i passaggi, vedere se fa funzionare il tuo programma più veloce o più lento.

Answer 2

Consulta questo PDF di ARM/Thumb per i compromessi tra prestazioni/dimensioni del codice/consumo energetico.

Profilo Selezione guidata di istruzioni per il braccio e il pollice
- Dipartimento di Informatica, Università dell'Arizona di Rajiv Gupta

Answer 3

Codice Thumb sarà essenzialmente sempre più lento di ARM equivalente. L'unico caso in cui il codice del pollice può essere una grande vittoria performance è se fa la differenza tra il vostro codice di montaggio in memoria on-chip o cache.

E 'difficile dare numeri esatti sulle differenze di prestazioni, perché è del tutto dipende da ciò che il codice fa in realtà.

È possibile impostare per-architettura flag di compilazione in XCode, che evitare di rompere la formazione simulatore. Vedere la documentazione impostazione accumulo XCode.