Microsoft Windows XP 64 bit: ormai manca poco!

Esatto. Comunque hai azzeccato proprio tutto...

Esatto. Anche considerando il caso migliore per il codice a 32 bit (tutte le istruzioni e i dati che sono perfettamente allineate alla dimensione della linea di cache) e quello peggiore per il codice a 64 bit (istruzioni disallineate e letture/scritture dei valori a 64 bit disallineati), calcolatrice alla mano, non si scappa.

Perfettamente.
Il 2) "obbliga" la pagina dello stack in cui verranno scritti tutti gli argomenti a trovarsi in memoria.
Il 3) è un vincolo più rilassato, perché una volta che il codice è sta nella cache e la pagina dei dati (stack) è caricata, il processore non potrà mai generare un'eccezione dovuta a un page fault.

Esatto. Anche nel caso peggiore per l'Athlon64.

Infatti. Questo era il vincolo rimasto per l'altro esempio.

Per la "formalità" basta conteggiare il numero di cicli di clock considerando il caso migliore per il codice a 32 bit e quello peggiore per quello a 64 bit, e il gioco è fatto...

Complimenti!

x repne scasb: come vedi, per come sono poste le condizioni, eccezioni di fatto non ce ne possono essere. Il codice verrà sempre eseguito senza alcuna interruzione.

Si può anche essere in buona fede, ma avere dimenticato un dettaglio, anche se importante.

Il problema, come ti dicevo anche nel mio messaggio precedente, è quello di stabile le condizioni reali: se non lo si fa, anche il codice di repne scasb risulta validissimo.
Proprio per questo motivo ho buttato la pietra della "dimostrazione formale".

D'accordo, ma vedi messaggio precedente (che t'ho scritto): mancavano le condizioni relative alla definizione di "normalità".

D'accordo, ma permettimi di farti le seguenti osservazioni:

1) la logica di prefetch per quanto riguarda il caricamento del codice nell'apposita sezione della cache L1 "normalmente" fa un ottimo lavoro: i cache miss dovuti all'esecuzione di codice non presente nella cache DI NORMA sono dovuti a salti condizionati di cui si è sbagliata la predizione; questo rispecchia il punto "1" della mia dimostrazione;

2) i dati di cui si parla negli esempi trattati sono gli argomenti "pushati" (che brutto termine); il tuo discorso lo si può applicare quando il processore deve andare a "pescare" dalla memoria quei dati, ma certamente non lo puoi applicare quando poi te li ritrovi nello stack: per sua stessa natura lo stack conserva dei dati "recenti", le pagine dello stack fanno parte normalmente del working set (se non fosse così il decadimento prestazionale dovuto alla chiamata di una funzione, specie con diversi argomenti, sarebbe notevole), e che normalmente il processore si ritrova nella cache L1.
Questo mi sembra proprio il caso nostro: quando il processore ha eseguito il push, ha posto i dati/argomenti nella cache L1 (per poi essere scritti nella cache L2 e quindi in memoria, ma di questo se ne occupa la sezione di load/store) e di conseguenza quando nella funzione si torna a leggerli, sono già lì, a portata di mano; questo rispecchia il punto "3" della mia dimostrazione;

3) se, come dici, "di solito" quel codice è "memory bound", mi sembra razionale supporre che lo sia tanto per quello a 32 bit quanto per quello a 64 bit.

Fermo restando che è chiaro, come hai detto, che i benefici derivanti dal fatto che quel codice a 64 bit verrà eseguito, sì, eseguito in meno tempo, ma che in mezzo a un codice (e non un inner loop) non farebbe la differenza (il profiling non lo so si fa certo per velocizzare l'esecuzione di una routine "isolata" e "poco usata", spero che le argomentazioni che ho portato qui sopra servano a "distendere" un po' la discussione...

x ripsk Non hai sparato delle "fregnacce": sono delle giuste considerazioni.

Però c'è da dire che il codice generato per lo stesso programma, ma per architetture diverse, tende ad avere lo stesso "comportamento", tanto più quanto le architetture "si assomigliano".
E' difficile, quindi, pensare che la routine a 32 bit esegua la metà di accessi in lettura di quella a 64 bit. Può benissimo succedere, per carità, e il motivo (per quanto riguarda il confronto x86 VS x86-64) è già stato detto: i puntatori occupano il doppio di spazio.

Ma dai risultati che abbiamo potuto vedere si assiste, a mio avviso, a un quadro abbastanza chiaro: mediamente lo stesso programma compilato ed eseguito per x86-64 offre un miglioramento delle prestazioni. Questo anche se non fa uso di dati interi a 64 bit (POV-Ray, nuovamente): i benefici derivano dalla nuova architettura.

Consiglio un po' più di calma

Quoto: non lasciamo degenerare un thread bello come questo.

x repne scasb: neppure io sono madrelingua italiano.

Per fortuna... Temevo di aver frainteso il significato di "interruzione"


Questo è il thread delle rivelazioni

Non faccio fatica a crederti.

Un dettaglio tipo eseguire il profiling di un inner loop?



Quel codice non e' validissimo, perche' come avevo ripetuto una decina di volte era eseguito in una condizione ideale e irreale (l'inner loop) che era gia' stata indicata da me come il caso perfetto in cui il codice a 64 bit risulta nettamente piu' veloce. Sostanzialmente ha dimostrato l'ovvio su un caso particolare per poi cercare di estenderlo per induzione a tutti i casi. Un tentativo un po' goffo.



1) assolutamente si'

2) i dati sono anche i due operandi, non per altro nella versione C li ho passati di proposito come puntatori a interi lunghi, per risaltare il fatto che quei dati provenivano dalla memoria, potenzialmente in due pagine totalmente separate, e ancora potenzialmente non in cache

3) assolutamente si', infatti la mia conclusione voleva essere che i due pezzi di codice di solito saranno probabilmente (e non sicuramente) prestazionalmente equivalenti perche' di solito si troveranno in ambienti memory bound dove il collo di bottiglia e' l'accesso alla memoria e non il numero di istruzioni eseguite



Tu aiuti sicuramente a distendere la discussione
Ma la discussione non si sarebbe neppure scaldata se la nostra amica ammettesse ogni tanto qualche suo errore, soprattutto quando sono cosi' goffi, invece di limitarsi ad arrampicarsi sugli specchi e insultare l'interlocutore che glieli fa notare.

non si può neanche scherzare?

X Helstar:
scusa se ho fatto scendere il livello della discussione con le mie buffonate....
non mi pare di aver offeso nessuno con il mio scherzoso commento (al contrario di te), e del resto non sei costretto a partecipare a questa discussione se non la reputi alla tua altezza.