Non posso, per la vita di me, ricordare cosa ha detto esattamente il nostro insegnante quel giorno e spero che probabilmente lo sapresti.
Il modulo è "Data Structures and Algorithms" e ci ha detto qualcosa sulla falsariga di:
L'
ifaffermazione è il [qualcosa] più costoso. [qualcosa] registra [qualcosa].
Sì, ho una memoria orribile e mi dispiace davvero molto, ma ho cercato su Google per ore e non è uscito nulla. Qualche idea?
Risposte:
Al livello più basso (nell'hardware), sì, se sono costosi. Per capire perché, devi capire come funzionano le pipeline .
L'istruzione corrente da eseguire è memorizzata in qualcosa di solito chiamato puntatore dell'istruzione (IP) o contatore di programma (PC); questi termini sono sinonimi, ma termini diversi vengono utilizzati con architetture diverse. Per la maggior parte delle istruzioni, il PC dell'istruzione successiva è solo il PC corrente più la lunghezza dell'istruzione corrente. Per la maggior parte delle architetture RISC, le istruzioni sono tutte di lunghezza costante, quindi il PC può essere incrementato di una quantità costante. Per le architetture CISC come x86, le istruzioni possono essere di lunghezza variabile, quindi la logica che decodifica l'istruzione deve calcolare quanto tempo è l'istruzione corrente per trovare la posizione dell'istruzione successiva.
Per le istruzioni di ramo , tuttavia, l'istruzione successiva da eseguire non è la posizione successiva dopo l'istruzione corrente. I rami sono gotos: dicono al processore dove si trova l'istruzione successiva. I rami possono essere condizionali o incondizionati e la posizione di destinazione può essere fissa o calcolata.
Condizionale vs. incondizionato è facile da capire: un ramo condizionale viene preso solo se una certa condizione è valida (ad esempio se un numero è uguale a un altro); se il ramo non viene preso, il controllo procede all'istruzione successiva dopo il ramo come di consueto. Per i rami incondizionati, il ramo viene sempre preso. I rami condizionali vengono visualizzati nelle ifistruzioni e nei test di controllo di fore whilecicli. I rami incondizionati si presentano in cicli infiniti, chiamate di funzioni, ritorni di funzioni breake continueistruzioni, la famigerata gotoistruzione e molti altri (questi elenchi sono tutt'altro che esaustivi).
Il target del ramo è un'altra questione importante. La maggior parte delle filiali ha una destinazione di diramazione fissa: vanno in una posizione specifica nel codice che viene fissata in fase di compilazione. Ciò include ifistruzioni, cicli di tutti i tipi, chiamate di funzioni regolari e molti altri. I rami calcolati calcolano la destinazione del ramo in fase di esecuzione. Ciò include switchistruzioni (a volte), ritorno da una funzione, chiamate di funzioni virtuali e chiamate di puntatori a funzione.
Quindi cosa significa tutto questo per le prestazioni? Quando il processore vede apparire un'istruzione di branch nella sua pipeline, deve capire come continuare a riempire la sua pipeline. Per capire quali istruzioni vengono dopo il ramo nel flusso del programma, è necessario sapere due cose: (1) se il ramo verrà preso e (2) l'obiettivo del ramo. Capirlo è chiamato previsione del ramo ed è un problema impegnativo. Se il processore indovina correttamente, il programma continua a piena velocità. Se invece il processore indovina in modo errato , ha semplicemente passato un po 'di tempo a calcolare la cosa sbagliata. Ora deve svuotare la sua pipeline e ricaricarla con le istruzioni dal percorso di esecuzione corretto. Conclusione: un grande successo in termini di prestazioni.
Pertanto, il motivo per cui le dichiarazioni if sono costose è dovuto a previsioni errate di filiale . Questo è solo al livello più basso. Se stai scrivendo codice di alto livello, non devi preoccuparti affatto di questi dettagli. Dovresti preoccuparti di questo solo se stai scrivendo codice estremamente critico per le prestazioni in C o in assembly. In questo caso, scrivere codice senza rami può essere spesso superiore al codice che si dirama, anche se sono necessarie molte altre istruzioni. Ci sono alcuni trucchetti bit-giocherellando che potete fare per calcolare cose come abs(), min()e max()senza di ramificazione.
"Costoso" è un termine molto relativo, soprattutto in relazione a un'istruzione " if" poiché devi anche tenere in considerazione il costo della condizione. Ciò potrebbe variare da poche brevi istruzioni della CPU al test del risultato di una funzione che richiama un database remoto.
Non me ne preoccuperei. A meno che tu non stia facendo la programmazione incorporata, probabilmente non dovresti preoccuparti del costo di " if". Per la maggior parte dei programmatori, semplicemente non sarà mai il fattore trainante per le prestazioni della tua app.
I rami, in particolare sui microprocessori con architettura RISC, sono alcune delle istruzioni più costose. Questo perché su molte architetture, il compilatore predice quale percorso di esecuzione verrà preso più probabilmente e inserisce quelle istruzioni successivamente nell'eseguibile, quindi saranno già nella cache della CPU quando si verifica il ramo. Se il ramo va nella direzione opposta, deve tornare alla memoria principale e recuperare le nuove istruzioni: è abbastanza costoso. Su molte architetture RISC, tutte le istruzioni sono un ciclo eccetto branch (che spesso è di 2 cicli). Non stiamo parlando di un costo importante qui, quindi non preoccuparti. Inoltre, il compilatore ottimizzerà meglio di te il 99% delle volte: ) Una delle cose davvero fantastiche dell'architettura EPIC (Itanium è un esempio) è che memorizza nella cache (e inizia l'elaborazione) le istruzioni da entrambi i lati del ramo, quindi scarta il set di cui non ha bisogno una volta che il risultato del ramo è conosciuto. Ciò consente di risparmiare l'accesso alla memoria extra di un'architettura tipica nel caso in cui si diramasse lungo il percorso imprevisto.
Consulta l'articolo Prestazioni migliori grazie all'eliminazione dei rami sulle prestazioni delle celle. Un altro divertente è questo post sulle selezioni senza diramazioni sul blog sul rilevamento delle collisioni in tempo reale.
Oltre alle ottime risposte già pubblicate in risposta a questa domanda, vorrei ricordare che sebbene le istruzioni "if" siano considerate costose operazioni di basso livello, cercando di utilizzare tecniche di programmazione senza rami in un ambiente di livello superiore , come un linguaggio di scripting o un livello di logica aziendale (indipendentemente dalla lingua), potrebbero essere ridicolmente inappropriati.
La stragrande maggioranza delle volte, i programmi dovrebbero essere scritti prima per chiarezza e poi ottimizzati per le prestazioni. Esistono numerosi domini problematici in cui le prestazioni sono fondamentali, ma il semplice fatto è che la maggior parte degli sviluppatori non sta scrivendo moduli da utilizzare in profondità nel nucleo di un motore di rendering o una simulazione di dinamica dei fluidi ad alte prestazioni che viene eseguita per settimane e settimane. Quando la massima priorità è che la tua soluzione "funzioni e basta", l'ultima cosa a cui pensare dovrebbe essere se puoi o meno risparmiare sull'overhead di un'istruzione condizionale nel tuo codice.
ifdi per sé non è lento. La lentezza è sempre relativa, scommetto per la mia vita che non hai mai sentito il "sovraccarico" di un'affermazione if. Se hai intenzione di creare un codice ad alte prestazioni, potresti comunque voler evitare i rami. Ciò che rende iflento è che il processore sta precaricando il codice da dopo ifbasato su alcune euristiche e quant'altro. Impedirà inoltre alle pipeline di eseguire il codice direttamente dopo l' ifistruzione branch nel codice macchina, poiché il processore non sa ancora quale percorso verrà preso (in un processore pipeline, più istruzioni vengono intercalate ed eseguite). Il codice eseguito potrebbe dover essere eseguito al contrario (se l'altro ramo è stato preso. Si chiama branch misprediction), oppure deve noopessere compilato in quei punti in modo che ciò non avvenga.
Se ifè male, allora switchè il male troppo, e &&, ||anche. Non ti preoccupare.
Al livello più basso possibile if(dopo aver calcolato tutti i prerequisiti specifici dell'app per particolare if):
Costi associati a ciò:
Risuona perché i salti sono costosi:
Quindi per riassumere:
I processori moderni hanno pipeline di esecuzione lunghe, il che significa che diverse istruzioni vengono eseguite in varie fasi contemporaneamente. Potrebbero non sempre conoscere il risultato di un'istruzione quando inizia a essere eseguita quella successiva. Quando si imbattono in un salto condizionale (se) a volte devono aspettare che la pipeline sia vuota prima di poter sapere in che direzione deve andare il puntatore dell'istruzione.
Lo considero un lungo treno merci. Può trasportare molto carico velocemente in linea retta, ma curva male.
Il Pentium 4 (Prescott) aveva una pipeline notoriamente lunga di 31 stadi.
Più su Wikipedia
Forse il branching uccide il precaricamento delle istruzioni della CPU?
Si noti inoltre che all'interno di un ciclo non lo è necessariamente molto costoso.
La CPU moderna assume alla prima visita di un'istruzione if, che "if-body" debba essere preso (o detto in un altro modo: assume anche un loop-body da prendere più volte) (*). Alla seconda e successiva visita, (la CPU) può forse esaminare la tabella della cronologia del ramo e vedere com'era la condizione l'ultima volta (era vero? Era falso?). Se l'ultima volta era falso, l'esecuzione speculativa procederà all '"altro" dell'if o oltre il ciclo.
(*) La regola è in realtà " ramo in avanti non preso, ramo indietro preso ". In un'istruzione if, c'è solo un salto [in avanti] (al punto dopo il corpo if) se la condizione è falsa (ricorda: la CPU comunque assume di non prendere un salto / salto), ma in un ciclo , c'è forse un ramo in avanti alla posizione dopo il ciclo (da non prendere) e un ramo all'indietro dopo la ripetizione (da prendere).
Questo è anche uno dei motivi per cui una chiamata a una funzione virtuale o una chiamata a un puntatore a funzione non è così peggiore come molti pensano ( http://phresnel.org/blog/ )
Come sottolineato da molti, i rami condizionali possono essere molto lenti su un computer moderno.
Detto questo, ci sono un sacco di rami condizionali che non vivono nelle istruzioni if, non puoi sempre dire cosa verrà in mente il compilatore e preoccuparsi di quanto tempo impiegheranno le istruzioni di base è praticamente sempre la cosa sbagliata fare. (Se puoi dire cosa genererà il compilatore in modo affidabile, potresti non avere un buon compilatore ottimizzato.)
L'unica cosa a cui posso immaginare questo potrebbe riferirsi è il fatto che ifun'affermazione generalmente può risultare in un ramo. A seconda delle specifiche dell'architettura del processore, i rami possono causare blocchi della pipeline o altre situazioni non ottimali.
Tuttavia, questo è estremamente specifico per la situazione: la maggior parte dei processori moderni dispone di funzionalità di previsione dei rami che tentano di ridurre al minimo gli effetti negativi della ramificazione. Un altro esempio potrebbe essere il modo in cui l'architettura ARM (e probabilmente altre) può gestire la logica condizionale - ARM ha un'esecuzione condizionale a livello di istruzione, quindi la logica condizionale semplice non produce ramificazioni - le istruzioni vengono eseguite semplicemente come NOP se le condizioni non sono soddisfatte.
Detto questo, ottieni la tua logica corretta prima di preoccuparti di queste cose. Il codice errato non è ottimizzato come puoi ottenere.
Le CPU sono profondamente pipeline. Qualsiasi istruzione branch (if / for / while / switch / etc) significa che la CPU non sa veramente quale istruzione caricare ed eseguire successivamente.
La CPU si blocca in attesa di sapere cosa fare o la CPU fa un'ipotesi. Nel caso di una CPU più vecchia, o se l'ipotesi è sbagliata, dovrai subire uno stallo della pipeline mentre va a caricare l'istruzione corretta. A seconda della CPU, questo può arrivare fino a 10-20 istruzioni di stallo.
Le CPU moderne cercano di evitarlo eseguendo una buona previsione dei rami ed eseguendo più percorsi contemporaneamente e mantenendo solo quello effettivo. Questo aiuta molto, ma può solo andare così lontano.
Buona fortuna in classe.
Inoltre, se devi preoccuparti di questo nella vita reale, probabilmente stai progettando il sistema operativo, la grafica in tempo reale, il calcolo scientifico o qualcosa di simile alla CPU. Profilo prima di preoccuparsi.
Scrivi i tuoi programmi nel modo più chiaro, semplice e pulito che non sia ovviamente inefficiente. Questo fa il miglior uso della risorsa più costosa, tu. Che si tratti di scrivere o di eseguire il debug successivo (richiede comprensione) del programma. Se le prestazioni non sono sufficienti, misuradove si trovano i colli di bottiglia e vedere come mitigarli. Solo in occasioni estremamente rare dovrai preoccuparti delle istruzioni individuali (fonte) quando lo fai. Le prestazioni riguardano la selezione degli algoritmi e delle strutture dati giusti nella prima riga, un'attenta programmazione, l'ottenimento di una macchina abbastanza veloce. Usa un buon compilatore, rimarrai sorpreso nel vedere il tipo di codice che ristruttura un compilatore moderno. La ristrutturazione del codice per le prestazioni è una sorta di ultima risorsa, il codice diventa più complesso (quindi più buggier), più difficile da modificare e quindi più costoso.
Alcune CPU (come X86) forniscono la previsione del ramo a livello di programmazione per evitare tale latenza di previsione del ramo.
Alcuni compilatori li espongono (come GCC) come un'estensione a linguaggi di programmazione di livello superiore (come C / C ++).
Fare riferimento alle macro probabili () / improbabili () nel kernel Linux: come funzionano? Qual è il loro vantaggio? .
Una volta ho avuto questa discussione con un mio amico. Stava usando un algoritmo del cerchio molto ingenuo, ma sosteneva che fosse più veloce del mio (il tipo che calcola solo 1/8 del cerchio) perché il mio usava if. Alla fine, l'istruzione if è stata sostituita con sqrt e in qualche modo è stato più veloce. Forse perché la FPU ha sqrt integrato?
Il più costoso in termini di utilizzo di ALU? Utilizza i registri della CPU per memorizzare i valori da confrontare e impiega tempo per recuperare e confrontare i valori ogni volta che viene eseguita l'istruzione if.
Pertanto, un'ottimizzazione di questo è fare un confronto e memorizzare il risultato come una variabile prima che il ciclo venga eseguito.
Sto solo cercando di interpretare le tue parole mancanti.