Selezionare una CPU o un microcontrollore necessari per una determinata applicazione software?

"Big O notation" non ha senso per questo scopo. Se si conosce n , è possibile stimare il numero di operazioni, ma alcune operazioni sono economiche (ad esempio 1 ciclo) e alcune operazioni non lo sono (ad esempio, mancata cache che costa migliaia di cicli); e la migliore stima che puoi raggiungere usando questo metodo sarà sminuita da "errore di stima". Nota: la "notazione Big O" è principalmente utile solo per confronti teorici di algoritmi che fanno la stessa cosa sulla stessa macchina reale o ipotetica.

In pratica; vuoi confrontare il codice reale su una vera CPU con dati realistici. Sulla base di questo si applicano i "modificatori ponderati" per adattare la stima ad altre CPU; che tengono conto di cose come le differenze nella gerarchia di memoria (latenza, dimensioni della cache), differenze nelle CPU (è più veloce / più lento dell'altra per SIMD, virgola mobile, operazioni in interi), le differenze sono compilatori (si ottimizza molto meglio / peggio di un altro), ecc. (dove i "pesi" provengono da quanto pensi che ogni cosa influenzi le prestazioni).

È facile dire " L'ho confrontato su una CPU a 3 GHz e ci sono voluti 10 secondi per un carico realistico, quindi suppongo che ci vorranno circa 45 secondi su una CPU da 1 GHz con RAM più lento e leggermente peggiore virgola mobile. "

Sono necessari alcuni benchmark affidabili per la CPU in questione e per CPU comparabili, di cui almeno una è disponibile. Quindi sviluppi l'algoritmo, lo misuri sulle CPU che hai e, prendendo i dati del benchmark, indovina quanto tempo impiegheranno le altre CPU.

Quindi decidi quali CPU potrebbero essere in grado di gestire il tuo algoritmo e seleziona quelle più economiche pur essendo in grado di eseguire l'operazione. E poi implementa il tuo algoritmo e verifica che sia effettivamente abbastanza veloce.

C'è sempre la possibilità che alcune CPU siano più ottimizzate per ottenere buoni risultati rispetto ad altre che sono più ottimizzate per prestazioni reali, quindi le conclusioni di misurazioni e benchmark potrebbero essere errate una volta misurata su una particolare CPU.

La complessità di un algoritmo sarà la stessa, sia che sia implementata in hardware o software. Potresti ottenere una "k" molto più bassa se è interamente implementata nella CPU, ma è ancora O (n log n).

In termini generali, supponendo che il lavoro sia vincolato dalla CPU e si stia all'interno di una serie di CPU in cui le differenze tra i numeri di modello sono principalmente la velocità di clock, allora la differenza tra CPU diversamente sincronizzata ma altrimenti identica sarà approssimativamente proporzionale alla differenza in velocità di clock.

Il cambio tra diverse revisioni della stessa famiglia di CPU può modificare significativamente il comportamento. Sebbene le istruzioni di assemblatore sottostanti elaborate possano essere in gran parte identiche, l'ottimizzazione dell'hardware può essere significativamente diversa in un modo che influisce sul tuo particolare compito. Potrebbero esserci meno opportunità per l'esecuzione parallela, la pipeline di comando e la previsione dei rami potrebbero essere meno favorevoli, oppure alcune delle istruzioni assembler potrebbero essere implementate come microcodice (un mini programma software all'interno della CPU) e richiedere molti più cicli di CPU per completare. / p>

Il passaggio tra le architetture della CPU, come il passaggio da x86 a ARM o XScale, rende più probabile tutto quanto sopra.

C'è anche un altro aspetto in questo. Il costo è anche più del semplice costo di acquisto della CPU. Vi è un chipset più ampio che è necessario sulla scheda del processore, e quindi, a seconda dell'ambiente operativo, il costo dell'elettricità di far funzionare il processore (e alimentato a batteria, il differenziale di costo per batterie più grandi / più piccole), e anche il costo di sostituzione per CPU guaste. Le CPU in esecuzione più calde non durano a lungo.