Microsoft Windows XP 64 bit: ormai manca poco!

quoto

Prendendo queste due routine che hai scritto (e che ho riportato sotto), fissando tre semplici condizioni posso azzardare una dimostrazione formale che l'esecuzione del codice a 32 bit è SEMPRE più lento di quello a 64 bit.

Le condizioni sono:
- che il codice (dal push degli argomenti alla fine della routine) stia interamente nella cache L1;
- che non si verifichi nessuna interruzione (nemmeno un page fault o eccezione) dal codice che esegue il push dei parametri fino alla prima istruzione (esclusa) della routine;
- che non si verifichi nessuna interruzione ESTERNA (i page fault e le eccezioni generate dal processore sono ammessi) dalla prima istruzione delle routine all'ultima.

Mi sembrano condizioni "ragionevoli" e che, IMHO, stanno ampiamente "nella media".

[CODE]
; Mode: PM_32
; Ottimizzazione: Nessuna

; Codice per salvattaggio dei registri

mov eax,[arg1_low]
mov edx,[arg1_hi]
mov ebx,[arg2_low]
mov ecx,[arg2_hi]
mov esi,eax
mov edi,edx
sub esi,ebx
sbb edi,ecx
add ebx,eax
adc ecx,edx
mul ecx
mov eax,ecx
mov eax,edi
mul ebx
add ecx,eax
mov eax,esi
mul ebx
add edx,ecx
mov [result_low],eax
mov [result_hi],edx

; Codice di ripristino dei registri

-----------------------------------------

; Mode: PM_64
; Ottimizzazione: Nessuna

; Codice per salvattaggio dei registri

mov rax,[arg1]
mov rbx,[arg2]
lea rcx,[rax+rbx]
sub rax,rbx
mul rcx
mov [result],rax

; Codice di ripristino dei registri
[/CODE]

Per adesso tralascio la dimostrazione: se qualcuno volesse cimentarsi, è libero di farlo.

Per quanto riguarda l'altro esempio (quello con i pushad e la chiamata a routine), posso fornire un'altra dimostrazione simile, aggiungendo un'altra condizione abbastanza "ragionevole" e "nella media".

Proprio sulla possibilità del punto 2) e 3) si basava il discorso di fek

I punti 1), 2) e 3) garantiscono che la somma dei tempi di esecuzione delle singole istruzioni corrisponde al tempo di esecuzione della routine.
Incidenza degli accessi in memoria:i punti 2), 3) garantiscono che i dati si trovano in cache.
Assunzione (sicuramente verificata nell'Athlon64): due accessi a 32 bit sono più lenti di un singolo accesso a 64 bit, dalla cache.
Resta solo da valutare, calcolatrice alla mano , l'incidenza del salvataggio dei registri (a 64 bit sono in numero maggiore e più grandi).

Non è una dimostrazione formale ma una traccia di come affronterei il problema

quante risorse vuole?

Speriamo che non ci vogliano un mouse con quattro palle, un processore da 1000000 Mhz, 100000000 Mb di RAM DDR1000 per farlo "girare" decentemente....
ed un hd a 200000 rpm per caricarlo senza doversi addormentare sulla tastiera per l'attesa...

Gabido: ti serve 'solo' un Athlon64 (o uno Xeon con le estensioni a 64bit). Per favore le buffonate altrove, che gia' in questo thread se ne sono visti troppi di clown ... e visto l'eccelso livello di discussione (*inchin* *inchin* *nsd* *nsd*) cerchiamo di non rovinare questo fantastico thread !

E' questo il mio punto, e non si tratta di parlare lingue diverse, ma di sapere di che cosa si sta parlando oppure no, oppure di essere in malafede

Puoi riuscire a dimostrare che quel particolare pezzo di codice a 64 bit e' sempre piu' veloce a livello teorico, ma poi lo metti in condizioni reali, ne misuri le prestazioni e ti accorgi che nella realta' pratica difficilmente riuscirai a notare differenze prestazionali.

E' ovvio, che se qualcuno e' in malafede, puo' semplicemente buttare il codice in un inner loop e cercare di dimostrare anche che gli asini volano, ma il mio discorso e' sempre stato il seguente:
in condizioni di esecuzione normale, e' difficile che si possano apprezzare differenze perche' di solito quel codice e' memory bound.

In altre parole, se l'ambiente in cui quelle istruzioni sono eseguite contiene molte altre istruzioni e molti altri accessi ai dati, e' molto probabile che i dati per quelle istruzioni non saranno in cache e la CPU si trovera' ad attendere l'arrivo dei dati su cui operare per la maggior parte del suo tempo, rendendo del tutto vano il risparmo di istruzioni. Questa e' la situazione tipica, un inner loop non e' la situazione tipica.

Spero di essere stato piu' chiaro ora, e a chi pensa di parlare una lingua diversa dalla mia, consiglio di imparare prima l'italiano

Il mio discorso si basa sulla singola esecuzione di quella funziona in un contesto nel quale i dati su cui opera non sono in cache.

In questo contesto, che e' il piu' probabile, le due versioni saranno molto probabilmente perfettamente equivalenti, e non certo una sicuramente piu' veloce dell'altra.

Ho poi aggiunto che in generale (e non solo nel caso particolare) non ha senso parlare di funzioni sicuramente piu' veloci di altre perche' va prima analizzato l'ambiente nel quale vengono eseguite.

Molto interessante questa discussione!
Prima di leggerla ero convinto che passare a 64bit comportava solo vantaggi

Dopo aver letto tutta la discussione sono pienamente daccordo con fek, i vantaggi migliori si avrebbero su calcoli ripettivi su pacchetti di dati e/o variabili di dimensioni abbastanza ridotti da poter essere contenuti nella cache evitando accessi alla memoria esterna, condizione che credo sia abbastanza rara per la maggior parte dei programmi.

Faccio un esempio (mooolto a spanne (ergo: con numeri inventati ) e senza considerare miglioramenti di architettura in generale ) di quello che penso potrebbe accadere in una applicazione "pippo" che non è stata pensata per girare meglio su 64 bit :

Se per eseguire 100 routine diverse con codice a 64bit impiego in media 20nS a routine ma devo accedere 100 volte alla memoria esterna per recuperare delle variabili che non ci stanno in cache per un tempo di 50nS ad accesso ottengo un totale di 7uSecondi.
Se le eseguo in codice 32bit magari impiego 40nS a routine ma accedo solo 50volte alla memoria esterna ottengo 6,5uS.

PS. vi lascio liberi di caziarmi se ho sparato qualche fregnaccia soprattutto per i tempi di accesso in memoria