Microsoft Windows XP 64 bit: ormai manca poco!

Per quanto mi riguarda sto confrontando le differenze architetturali nell'esecuzione di codice fra x86 e x86-64: quindi non semplicemente fra codice a 32 e 64 bit, se non intendendo con ciò x86-32 e x86-64 rispettivamente, nel loro complesso.

E' chiaro che i 64 bit di per sé non posso influire da soli nei risultati: è l'intera architettura che, essendo diversa, comporta delle differenze in termini prestazionali. Con ciò si spiega il guadagno di POV-Ray, che fa massiccio uso di calcoli in floating point, come giustamente sottolinei, e penso nessun uso di variabili intere a 64 bit. Evidentemente il maggior numero di registri GPR/SSE, ecc. ha portato a questo risultato.

Rimane il fatto che nel disassemblato che hai fornito non è presente neppure un'istruzione di moltiplicazione, che è assolutamente necessaria (ce ne vogliono almeno tre, come giustamente ha riportato repne scasb) per calcolare in maniera corretta la funzione che hai riportato.
Infatti i due sorgenti che hai postato, in C e assembly, non calcolano la stessa funzione, ed è questo (penso) che voleva farti notare repne scasb.

Questo è pacifico: le condizioni al momento dell'esecuzione posso chiaramente influenzare anche pesantemente l'esecuzione del codice, ma se dovessimo considerare tutte le variabili che possono incidere, che senso avrebbe effettuare il profiling di un codice? Nessuno, perché non si sa mai in quali condizioni verrà eseguito: quali pagine del codice, dei dati e dello stack sono caricati in memoria, quali parti stanno nella cache L1, in quella L2 (eventualmente nella L3), quali pagine sono mappate nei tag del TLB, ecc. ecc. ecc.

Penso che sia ragionevole, invece, spostare l'attenzione sul punto di vista di un compilatore, che di tutte queste variabili non è assolutamente a conoscenza e comunque, sorgente "alla mano", deve pur tirare fuori un codice eseguibile.
Da questo punto di vista, analizzando indifferentemente le prime o le seconde versioni a 32 e 64 bit della funzione di cui sopra, mi sembra più che evidente che il codice che POTENZIALMENTE girerà più velocemente e quello per x86-64: è molto più compatto (quindi occupa meno spazio nella cache), utilizza meno istruzioni, meno accessi alla memoria, esegue una sola moltiplicazione, utilizza meno registri e quindi può anche fare a meno di spostare avanti e indietro registro nello stack/cache/memoria.

D'altra parte ti sarai reso conto che POV-Ray ha evidenziato un notevole miglioramento, pur non usando registri (interi) a 64 bit: eppure i puntatori "pesano" il doppio, le strutture quindi occupano più spazio -> più accessi alla memoria -> più accessi alla cache & meno spazio disponibile per gli altri dati/codice, il codice x86-64 occupa il 20% circa in più di spazio, ecc. ecc.


D'accordo, ma vedi sopra: possiamo andare avanti per centinaia di messaggi, ed è chiaro che fare il profiling di due codici completamente diversi, quali sono quelli a 32 e 64 bit di cui sopra, non porterà a niente. Com'è anche più che evidente che gli incrementi prestazionali dell'architettura x86-64 esistono, e spesso sorprendono anche te...

Si', mi trovi d'accordo, anch'io direi che la maggior parte dei miglioramenti che hai riportato sono dovuti all'architettura piu' efficiente.



Mi fai sorgere il dubbio di aver sbagliato il copy&paste dal debugger.



Esatto, non ha senso fare il profiling di una funzione separata dal contesto. E' proprio il punto al quale volevo arrivare.
E' un esercizio che non porta a nessuna informazione e che lascio volentieri agli accademici

A me interessano i discorsi pragmatici e valutare mediamente quale impatto prestazionale possa avere il codice a 64 bit rispetto a quello a 32 bit in media. Alla luce della discussione direi molto basso se non in casi molto specifici. Qui sto parlando di codice a 64 bit non di codice per l'architettura x86-64, dal quale credo sia nata la confusione.



Di nuovo no, questa conclusione e' errata, perche' quel codice puo' potenzialmente essere piu' lento, piu' veloce oppure uguale. Una volta messo nel suo ambiente si puo' dare una risposta e questa risposta dipende da svariati fattori.

Accedere una tabella trigonometrica ha meno istruzioni (solo una), usa meno registri (solo uno), ha meno accessi alla memoria (solo uno), potenzialmente girera' molto piu' velocemente rispetto a fare i calcoli. Toh, va piu' piano



I risultati dell'architettura non mi sorprendono affatto, mi sorprenderebbe se passare da 32 bit a 64 bit (non da architettura ad architettura) portasse ad incrementi medi del 30% come qualche utente ho sostenuto, ed e' cio' che contesto.

Domanda forse capziosa: se i miglioramenti architetturali (piu' registri, etc) fossero stati implementati senza i registri a 64bit secondo te avremmo ottenuto incrementi prestazionali simili, superiori o inferiori? Direi simili.

Scusate ma si può scaricare oppure no?

Ovviamente il discorso di cdimauro è nel campo delle supposizioni.
Dal momento che puntatori a 64 bit occupano più spazio ti aspetti un maggior numero di cache miss, e quindi prestazioni peggiori a parità di altri fattori.
Dal momento che il codice della funzione che hai postato compilato a 64 bit è molto più compatto, ti aspetti che porti a meno cache miss e prestazioni migliori in alcuni casi (anche se stiamo parlando di cache del codice, non è la stessa cosa ).


Credo che questo risponda adeguatamente:
http://www.anandtech.com/guides/viewfaq.html?i=112

Di fatto solo lo spazio di indirizzamento maggiore richiede necessariamente 64 bit. I miglioramenti nel calcolo di interi sono marginali.
AMD è stata molto astuta nell'aggiungere molti miglioramenti architetturali negli Athlon64, in modo da rendere più vantaggioso il passaggio alla nuova piattaforma, anche in assenza di codice in grado di sfruttarne le caratteristiche.
Nessuno si aspetta prestazioni maggiori dai G4 perchè a 64 bit...

Piu' che adeguatamente

Appunto. Per risponderti leggi uno dei miei primi post in questo thread:



che cosa ho detto di diverso rispetto a quello ke tu stai dicendo nel pezzo ke ho quotato???

e cmq il raytracer è solo un campo, ma anke l'encoding video, l'encoding audio, la compressione, i database sono altri campi....
qdi permettimi di dire ke non sono poi così poche le applicazioni che beneficieranno di WIN XP 64.

"Sicuramente piu' veloce". Evidentemente non hai letto nulla di quello che ho scritto io e neppure hai letto l'articolo. Mi sembra offensivo nei confronti di chi legge dover ripetere daccapo il concetto.

Pazienza, hai sprecato una buona occasione.