Microsoft Windows XP 64 bit: ormai manca poco!

E a chi scrive compilatori...

Il problema è stabilire quel "in media" di cui parli: se non specifichi chiaramente quali sono le condizioni "nella media", sia per il codice per x86 sia per quello x86-64, non ne usciamo più.
D'altra parte tu fai profiling (e ci mancherebbe ) per cui per valutare se un codice è "più veloce di un altro" (occhio alle virgolette, eh! ) devi per forza di cosa fissare i parametri relativi al profiling.
Fissati questi, IMHO, si può pensare di fare un confronto fra l'esecuzione di codice x86 e x86-64 sulla stessa macchina per lo stesso programma.

Lo credo anch'io. Comunque l'importante è che si sia fatta luce sul significato di 32 e 64 bit in seno alla discussione.

OK, e sono d'accordo (infatti ho evidenziato che quello è il punto di vista del compilatore): vedi sopra comunque. Cerchiamo di fornire un contesto preciso e vediamo cosa succede.

"Il precalcolo è alla base del real-time" era una massima in voga fino a poco tempo fa...

E su cui sono AMPIAMENTE d'accordo: ho sempre rimarcato, da tre anni a questa parte, che non è la sola estensione dei registri a 64 bit che comporterà un aumento di velocità per l'architettura x86.

Io direi superiori. Rimanendo a 32 bit, i puntatori occuperebbero meno spazio, con tutte le conseguenze di cui abbiamo discusso finora. Questo tenendo sempre presente che comunque il codice che utilizza i nuovi registri (alla fine sarebbe soltanto questa la differenza a livello di ISA fra x86-64 e la medesima "castrata" del supporto ai 64 bit) occupa dello spazio in più.

Anzi, preciso che prima ho detto che il codice per x86-64 occupa mediamente un 20% in più: ciò non è esatto (la fretta è cattiva consigliera purtroppo ), perché non è relativo a tutto il codice, ma quanto scritto si verifica quando si utilizzano i nuovi registri e/o se ne forza l'uso a 64 bit.

Questo, però, è controbilanciato dal fatto che si usano molti meno accessi alla memoria e il codice, in fin dei conti, risulta molto più compatto (com'è evidente anche dai sorgenti della tua funzione per x86 e x86-64), e quindi occupa meno spazio (coi vantaggi che ciò può comportare).

EDIT: correzione grammaticale...

Sicuramente, ma questo vale per tutti i processori che presentano qualche miglioramento architetturale. E comunque credo che un compilatore ottimizzato per il particolare processore riesca a ridurre di molto la differenza.

Il rischio è un altro. Un'applicazione può contenere del codice pensato specificatamente per i 32 bit, ad esempio, tratta i puntatori come interi a 32 bit. Si tratta di tecniche di programmazione che è meglio evitare se si vuole codice pulito e facilmente leggibile, ma può capitare.
In quel caso è possibile che l'applicazione non funzioni, o non funzioni nel modo corretto.
Visual Studio 2003 ha l'opzione "controlla compatibilità 64 bit" proprio con l'intenzione di favorire codice portabile a 64 bit senza modifiche.

Hai centrato il senso del mio messaggio. Poi è chiaro che il contesto può cambiare tutto, come giustamente afferma fek.

Infatti non è un caso il fatto che di default le operazioni siano a 32 bit, e che per usare i 64 bit bisogna forzare gli opcode con l'apposito prefisso.

Esattamente. Questo è anche il motivo per cui Apple per Tiger ha preferito una soluzione "ibrida" per il suo nuovo s.o.: le applicazioni dotate di GUI rimangono sempre a 32 bit, e per usare i 64 bit si deve scrivere un'altra applicazione che s'interfaccia con la prima tramite messaggi.
In pratica i 64 bit vengono assolutamente sconsigliati, se non per i casi in cui i programmatori ritengono ci possano essere degli effettivi vantaggi (consistenti manipolazioni di dati a 64 bit e/o indirizzamento a 64 bit della memoria): i puntatori a 64 bit occupano troppo spazio, e il context switch di un task che usa registri a 64 bit è chiaramente più lento.

D'altra parte, a differenza degli AMD64, i G5 comportano esclusivamente un'estensione a 64 bit dei registri (e quindi dei puntatori): non esistono altre novità architetturali che possano permettere incrementi prestazionali, e quindi bilanciare ed eventualmente superare il decadimento prestazionale di cui sopra (puntatori a 64 bit in primis).

Avevo capito bene allora...

Più tutte le somme (che generano anche dipendenza nei risultati), e l'ampio uso di registri, tanto da richiedere degli accessi ripetuti alle stesse locazioni di memoria (si sarebbero potuti evitare salvando il registro EBP nello stack al momento opportuno e usando, come pure l'uso del registro EBX: ma sono "finezze" che generalmente sfuggono a un compilatore... ).

Credo che questo sia uno dei pochi esempi in cui, tralasciando tutto il discorso del contesto a cui è legato il codice, i vantaggi dell'uso di registri e operazioni a 64 bit siano notevoli (sempre sulla carta).

Avevo già letto quel tuo post (e i seguenti) molto interessante, e devo dire che sono rimasto sorpreso da queste scelte. Comunque penso che sia necessario un maggior approfondimento e altre prove per verificare con assoluta certezza se effettivamente l'esecuzione del codice in modalità x86 (32) sia stata "castrata" a favore dell'esecuzione in x86-64.

Questa è una cosa che non mi è ancora chiara: ho visto da alcune fonti (Arstechnica, Anandtech) che si paga un 10% in spazio per il codice a 64 bit dell'Athlon64, ma non mi è chiaro se è riferito a tutto il codice o a solo alle parti specifiche a 64 bit. Arstechnica parla di un byte di overhead (su 4 del codice a 32 bit) per le istruzioni a 64.
D'altra parte con meno accessi alla memoria mi aspetterei meno istruzioni, che quindi controbilancerebbero l'overhead. Quindi il 10% è ottenuto dal confronto fra codici compilati (= test), o è una stima basata sulla ricorrenza media di un certo tipo di istruzione?

Però ragazzi il prodotto non è ancora uscito è già fate tutto questo gran casino, oppure dovrei usare un termine politicaly correct come rumors...
Salvataggio registri, ripristino registri, profiling dei codici, routine di clock medi, confronti paralleli fra architettura a 32 bit e a 64 bit... tutto questo sulla versione beta?
Magari la versione beta è un ibrido (modello formula 1) e la versione definitiva sarà totalmente diversa, senza contare gli aggiornamenti iniziali...

Conosco il Grinch, ma non ho mai sentito parlare del "winch"...

Vedo che hai capito molto di tutto quello che abbiamo detto finora...

OK, come sopra: ma non era meglio se non lo scrivevi questo messaggio?

Rispondo io a questa tua domanda, visto che ho accumulato abbastanza esperienza nel campo dei database.

L'engine di un database può avvantaggiarsi dei 64 bit (dicendo ciò limito la discussione solamente all'uso di quantità a 64 bit e alle operazioni su di esse) nei seguenti casi:

- tipo di dati intero a 64 bit (usato spesso per generare l' "ID" di un ben preciso record);
- tipo di dati "currency", che a tutti gli effetti utilizza un intero a 64 bit.

A ciò, nella mia esperienza con l'engine SQL InterBase / FireBird, aggiungo anche un ID "interno" che il sistema transazionale utilizza per identificare in maniera univoca un ben determinato record all'INTERNO DI UNA DETERMINATA TRANSAZIONE, e che fa uso di un intero a 64 bit (se non ricordo male deriva dalla combinazione del numero di pagina all'interno del file in cui si trova il record, più l'offset all'interno del record, più un valore legato alla transazione in oggetto).

In particolare quest'ultimo punto può portare notevoli vantaggi, dato l'elevato numero di record che può interessare una transazione (InterBase / FireBird utilizza un sistema transazionale di tipo "ottimistico", per cui ogni transazione "vede" una SUA copia dei record con cui interagisce, in lettura e/o scrittura).

Non solo: aggiungo che questo particolare engine SQL permette, tramite un'estensione proprietaria del suo "linguaggio SQL", di accedere a questo "ID interno" direttamente, per cui se usato SAPIENTEMENTE (si tratta di un'informazione MOLTO delicata, com'è facile intuire) permette di scrivere delle query che posso essere eseguite anche MOLTO, ma MOLTO velocemente rispetto alla medesima, ma scritto in modo "pulito" (beh, anche questo è un modo "pulito", perché concesso dall'engine SQL ).
N.B. Anche Oracle mi sembra che abbia un meccanismo similare.

OK, tornando a noi e ai 64 bit (e tralasciando l'esempio di InterBase / FireBird: non tutti gli engine SQL funzionano così ), è evidente che l'incremento prestazionale si ottiene perché gli ID a 64 bit sono molto usati di per sé, come pure nelle applicazioni che hanno a che fare con i soldi il currency è il tipo di dati usato per eccellenza.

Detto ciò, i vantaggi mostrati da MySQL derivano anche dal resto dell'architettura x86-64: ad esempio l'SQL è un linguaggio molto complesso, e un parser che ha disposizione numerosi registri "ci va a nozze" per quest'operazione...

Spero di aver soddisfatto la tua curiosità / i tuoi dubbi...

Considera che il sorgente di un programma normalmente non viene espressamente pensato / scritto per una determinata architettura. Questo può anche verificarsi (ad esempio, se so che l'architettura utilizzata è VLIW o è fortemente penalizzata dai salti, cercherò di scrivere il codice limitandoli il più possibile, per quel che si può fare), ma appunto non è la norma.

Per il resto, ti ha già risposto Banus...