Microsoft Windows XP 64 bit: ormai manca poco!

grazie...

Correggimi se sbaglio ma, se non ho inteso male, con "ricompilare" intendi modificare e adattare un codice a 32bit per "trasformarlo" in 64bit, oppure il discorso si applica anche se si "pensa e si scrive" nativamente a 64bit?

No, ma analizzando le differenze architetturali fra un Athlon e un Athlon64 in modalità x86-64, direi che sono abbastanza plausibili...

Ho trovato un po' di materiale. In particolare, per MySQL qui http://anandtech.com/linux/showdoc.aspx?i=2127&p=5 trovi che nei test relativi alla SELECT la versione a 32 bit impiega il 35% circa in più rispetto a quella a 64 bit, mentre nell'INSERT impiega l'11% circa in più.

Nelle altre pagine ci sono altri test relativi ad altre tipologie. Riporto i più significativi miglioramenti ottenuti: LAME a 32 bit impiega il 46% in più di quello a 64 bit, POVRay/32 il 25% in più, Wolfestein Enemy Territory/64 genera il 13% di frame in più.

Effettivamente ricordavo male: oltre il 40% era il risultato del LAME, e non di POV-Ray e MySQL, ma in ogni caso il 25% e il 35% mi sembrano comunque degli ottimi valori, considerato che è stata necessaria solamente la ricompilazione.

Altri test interessanti li troviamo in una recentissima recensione di x86-secrets qui http://www.x86-secret.com/articles/...4/32vs64-3.htm. E' riservata ai processori server (Opteron e Nocona), ma sono fornite le prestazione sia a 32 bit che a 64 bit. In particolare sono presenti una serie di test con Windows x64 RC1 qui http://www.x86-secret.com/articles/...4/32vs64-5.htm. Riporto i più significativi miglioramenti:

MiniGZip (compressione) è passato da 20,81 secondi della versione a 32 bit ai, 9,28 di quella a 64 bit.
Blobbly Dancer (demo tecnologico) da 26,67 fps a 30,21 fps.
POV-Ray (landscape.pov) da 60,31 secondi a 43,89.

Quelli di MiniGZip (specialmente) e POV-Ray sono semplicemente impressionanti, non credi?

A me interessano.

Comunque sarebbe interessante vedere gli equivalenti a 32 e 64 bit generati da qualche compilatore, che sono gli strumenti più usati (sono poche le applicazioni che hanno ancora sezioni scritte in assembly).

No, per ricompilare s'intende prendere i sorgenti già esistenti per un'applicazione, e generare l'eseguibile per una specifica architettura.

Ecco il link:
http://www.anandtech.com/linux/showdoc.aspx?i=2127

Come vedi le mie non sono speculazioni...
mi sono basato sulle prove effettuate su diversi software reali, in cui si vedono chiaramente i benefici dei 64 bit in quasi tutti i campi.

È possibilissimo ke il tuo codice non abbia beneficiato x niente dei 64 bit, ma non puoi generalizzare solamente dalle prove che hai effettuato.....

può essere che hai beccato uno degli algoritmi ke non traggono assolutamente vantaggio dai 64 bit.
Ma questo non vuole dire ke nessun altro algoritmo può essere avvantaggiato.

Infine *credo*, da quello ke ricordo della struttura dei database, ke essi utilizzino molto dati interi a 64 bit x l'indirizzamento dei dati all'interno del database.....

P.S. c'è repne ke mi fa sempre + paura

[EDIT]Qdo ho iniziato a scrivere ancora non c'era il commento di cdimauro! [/EDIT]

1) 2) 3) 4) 5) Non ho scritto quel codice a mano, e' il risultato del compilatore e delle sue ottimizzazioni.



Si', tutte le ottimizzazioni attivata, VS2005 (la BETA2), dopo l'Intel Compiler e' decisamente il piu' ottimizzante su piattaforma X86.



Se pensi sia utile, si'. Possiamo vedere il codice prodotto da altri compilatori su piattaforma X86 e confrontarli, ma non credo che cambi molto il succo del discorso:
1) servono alcune istruzioni per implementare i calcoli a 64 bit
2) queste istruzioni vengono presumibilmente nascoste dalla latenza degli accessi alla memoria.

Si', sono decisamente il caso di calcoli intensivi su inner loop molto stretti (il raytracing ad esempio). Ma quelli sono calcoli in floating point...
Mi stona molto il risultato di MySQL... ma siamo sicuri che qui stiamo analizzando le ottimizzazioni architetturali oppure la differenza fra codice a 32 bit e 64 bit?
Perche' non vedo davvero dove la seconda possa entrare in calcoli floating point effettuati da un raytracer...

E' quello che cerco di spiegarti, in un raytracer non apprezzi i benefici dei 64 bit, apprezzi i benefici di un'architettura piu' performante ed e' un discorso molto diverso. Ed un raytracer non e' "in quasi tutti i campi", e' un solo campo.

Quello che ti sto contestando e' che il passaggio da 32 a 64 bit possa portare benefici prestazionali in tutti i campi, no, non e' vero. I miglioramenti dell'architettura si', i 64 bit no.



Io non ho generalizzato, tu stai generalizzando "in tutti i campi". Io ho portato esempio di codice che necessita di calcoli a 64 bit, che immagino possa beneficiare di un'architettura a 64bit
Lo immagino, perche' a conti fatti non ne beneficia.



Non ho mai detto che nessun altro algoritmo possa esserene avvantaggiato.

PS. Per favore, puoi scrivere senza k? E' sempre piu' faticoso seguirti.