Beh dipende da molte cose, un'architettura può avere delle istruzioni più performanti che però nella fase di instruction selection della compilazione non vengono scelte. Questo può dipendere da carenze di informazioni nella rappresentazione intermedia o dal costrutto utilizzato dal programmatore che confonde il compilatore, oppure infine dal fatto che si vuole compilare mantenendo la retrocompatibilità con macchina della stessa architettura ma di generazioni precedenti.<br>
<br>Un esempio possono essere le istruzioni MMX, SSE etc etc che possono esser utilizzate oppure no.<br><br>Un altro fattore limitante non sta proprio nelle istruzioni ma nel design strutturale del processore: dimensioni e velocità della cache, profondità della pipeline, capacità di prefetch migliori/branch prediction e infine unità aritmetico/logiche a disposizione in parallelo.<br>
Anche in questi casi molto dipende dal compilatore ma anche dal programmatore.<br><br>Ad esempio, se si deve calcolare la somma elemento per elemento di due vettori, e salvarla in un altro vettore, ma i due vettori di partenza sono in realtà i campi di una struttura, la quale è in forma di vettore, per il compilatore diventa un bel casino capire come iterare sui vettori di partenza.<br>
Succede infatti che i dati che effettivamente possono entrare nella cache sono pochi, il prefetch fallisce e o il processore aspetta che il fetch vada a buon fine, oppure deve proprio svuotare la pipeline e ricominciare.<br>
<br>A seconda del compilatore, ed a seconda della architetuttura questo può aver un impatto maggiore o minore.<br>Alcuni processori infatti hanno cache più grosse, magari unità di prefetching/branch prediction più complesse ed efficienti o pipeline più lunghe/corte.<br>
<br>Il fatto della pipeline luna o corta può esser sia un bene che un male: su dati lunghi organizzati in modo sequenziale, su cui si deve fare la stessa operazione, la pipeline lunga ha prestazioni maggiori... ma se per caso c'è un branch non predetto, svuotarla richiede più tempo della pipeline corta.<br>
<br>Ho forse dimenticato qualcosa?<br>Beh si, anche tutto il contorno esterno! non dimentichiamoci il bus verso la memoria!! :) e anche il resto..<br><br>Dici che è troppo lunga?<br>In ogni caso, se te lo sei perso, ti ricordo il Linux Compiler Deathmatch: <a href="http://www.phoronix.com/scan.php?page=article&item=linux_compiler_deathmatch&num=1">http://www.phoronix.com/scan.php?page=article&item=linux_compiler_deathmatch&num=1</a><br>
Questo si che è interessante!! :)<br><br>Ciao!<br><br><div class="gmail_quote">Il giorno 03 febbraio 2011 14:50, ADB <span dir="ltr"><<a href="mailto:albeluci@gmail.com">albeluci@gmail.com</a>></span> ha scritto:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">....quindi vuol dire che un dual Opteron a 2 Ghz e un ARM Cortex A9<br>
dual alla stessa frequenza, potrebbero avere la stessa potenza di<br>
calcolo, se il codice fosse ben ottimizzato per la relativa<br>
architettura?<br>
<br>
O l'architettura e le istruzioni specifiche per le 2 CPU non c'entrano<br>
nulla? :-)<br></blockquote></div>