Microsoft Windows XP 64 bit: ormai manca poco!

percio adesso chi ha un sistema a 64 bit usa ancora windows xp 32 bit???

Nel tuo codice hai omesso tutta una serie di istruzioni di ripristino dei registri che presuppongono accessi alla memoria (lo stack), istruzioni che io ho inserito.

Voglio credere che questa sia solo una ingenua dimenticanza, perche' quando inserisci anche quelle istruzioni nel codice dimostri quello che ho detto: una serie di istruzioni matematiche, immerse in una serie di accessi alla memoria che rendono le istruzioni risparmiate nel codice a 64 bit sostanzialmente gratuite.



Non hai letto correttamente o in maniera integrale la mia risposta alla tua risposta: ho fatto copy&paste del codice prodotto dal compilatore (a meno di una chiamata al codice di controllo dei buffer overrun che non ci interessa).



Voglio credere anche qui che hai dimenticato in buona fede di riportare le condizioni del tuo profiling, che sono il nodo centrale del discorso.
Come hai preso questi tempi?
Hai inserito la chiamata a funzione "in mezzo a del codice" oppure l'hai messa in mezzo ad un loop con solo la chiamata?

Ovvero:

codice;
codice;
codice;
chiamata a funzione;
codice;
codice

Oppure:
loop 1.000.000
chiamata a funzione

Perche' se hai fatto il secondo esperimento, hai dimostrato quello che ho detto fino ad ora: in caso di inner loop molto stretti (con tutto il working set in cache) e' ovvio che la seconda versione e' piu' veloce.

Ma questo non e' un esperimento realistico, e' una condizione limite, mi sembra un errore troppo ingenuo l'aver riportato quei dati in quella maniera con una conclusione cosi' perentoria che... e' falsa.

Ripeti l'esperimento buttando la chiamata a funzione in mezzo a dell'altro codice, in una situazione piu' realistica, e vediamo se noti la stessa differenza.

Ehehe... repn, in quanti cicli di clock viene eseguita da un P4 (scegli tu quale), questa istruzione:

mov eax, [mem]

Minimo e massimo

(ti faccio questa domanda perche' dalla tua ultima risposta mi viene il sospetto che tu non sappia come si faccia il profiling del codice)

Qui nessuno sta manipolando nulla. Oddio qualcuno ci sta provando, ma con scarsi risultati.

Ripeto la mia domanda, che e' assolutamente seria e precisa; quanti cicli di clock minimo e massimo sono necessari per eseguire la seguente istruzione:

mov eax, [mem]



Se il profiling fosse solo chiamare RDTS sarebbe un mondo piu' bello e piu' semplice. Purtroppo la realta' e un po' piu' complessa e la seguente affermazione "tale funzione e piu' veloce di tal altra del 318.953235%" e' perfettamente priva di significato nel mondo reale.

Come provare a fregarci con un inner loop per dimostrare che il codice a 64 bit e piu' veloce di quello a 32 bit.
Nice try

Rispondi alla mia domanda per cortesia? Per te che ci fai sempre tale sfoggio, non dovrebbe essere una risposta troppo complicata. Grazie.

Ok, rispondo io alla domanda.

Quell'istruzione puo' impiegare ad essere eseguita da un minimo di zero cicli, se la cella di memoria e' nella cache di primo livello e la latenza viene coperta da altre istruzioni di accesso alla memoria, ad un massimo di milioni di clicli di clock, se la pagina della quale fa parte e' stata magari paginata su hard disk e quell'accesso causa un page fault, la CPU e' costretta ad una transizione in ring 0, caricare la pagina di memoria dall'hard disk alla memoria centrale, tornare in ring 3 e riprendere l'esecuzione.

In sintesi, le prestazioni di un frammento di codice dipendono fortemente dalle condizioni al contorno nel quale il codice stesso e' eseguito.
Per questo affermare che la versione di quella funzione a 64 bit e' due volte piu' veloce della versione a 32 bit significa non sapere di che cosa si sta parlando. Quella versione e' due volte piu' veloce nelle condizioni dell'esperimento, ovvero nelle condizioni ideali d'esecuzione, in un inner loop, con tutto il working set in cache, codice in cache, salti tutti predetti correttamente. Purtroppo sono condizioni di esecuzioni irrealistiche

In condizioni di esecuzione piu' realistiche, dove la stessa chiamata a funzione e' effettuata all'interno di un algoritmo piu' complesso, con il suo working set che magari non e' sempre in cache, con determinati pattern d'accesso alla memoria, la versione a 64 bit potrebbe anche risultare piu' lenta di quella a 32 bit, o di qualche punto percentuale piu' veloce, oppure esattamente equivalente. Dipende fortemente dalle condizioni di esecuzione.

Per questo mi e' venuto il dubbio che repne non sappia di che cosa sta parlando, o, molto piu' probabilmente, sa di che parla ma ha provato a fare orecchie da mercante ed ha solo cercato di manipolarsela a suo favore per chissa' quale motivo di autocelebrazione.

Un altro esempio per chiarire, la famosa tecnica di ottimizzazione per calcolare il valore del coseno di un angolo: invece di fare i calcoli della funzione (o di una sua approssimazione) si memorizzano i risultati in una tabella dove per ogni angolo e' memorizzato il valore del suo coseno. Dato l'angolo, con una semplice lettura dalla memoria si ha il risultato, apparentemente molto piu' veloce che farsi i calcoli.
Funzionava a meraviglia dieci anni fa; magari chiamando questa funzione del coseno un milione di volte anche oggi si trova che e' dieci volte piu' veloce della versione che calcola il valore senza la tabella, poi si chiama la stessa funzione dall'algoritmo che si sta cercando di ottimizzare e si scopre che... va piu' lento. La tabella di coseni occupa spazio nella cache di primo livello che causa un aumento del working set dell'algoritmo rallentandolo. Mi e' successo l'anno scorso.

Morale della favola, fare profiling non significa chiamare RDTSC, significa capire le condizioni di esecuzione di un frammento di codice e da li' capirne il profilo prestazionale interpretando i dati del profiler.