Microsoft Windows XP 64 bit: ormai manca poco!

[v600]

io ho un Athlon64 3200+ ma l' aggiornamento nn me lo fa fare:d

[^TiGeRShArK^]

non è un aggiornamento, lo devi installare in un'altra partizione, anke perkè non ti conviene sovrascrivere win xp 32, ma ti conviene usarli entrambi.

[capitan_crasy]

speriamo che creative esca con dei driver per win x64, altrimenti niente audigy 2...

[DioBrando]

Originariamente inviato da capitan_crasy
speriamo che creative esca con dei driver per win x64, altrimenti niente audigy 2...

sai che perdit...

[capitan_crasy]

Originariamente inviato da DioBrando
sai che perdit...

non ci dormo la notte...

[Vifani]

Creative ha già rilasciato driver per le schede Audigy 2 compatibili con Windows XP a 64 bit. Sono in versione beta.

http://preview.creativelabs.com

[fek]

Originariamente inviato da ^TiGeRShArK^

questo passaggio onestamente mi sfugge....
"Giusto l'altro ieri ci siamo domandati se un pezzo di codice piuttosto complicato che necessitava di calcoli a 64bit su una cpu a 32 bit sarebbe stato piu' veloce se implementato a 32 bit"

Qui c'e' una considerazione importante: fare speculazioni sui tempi di esecuzione del codice e' divertente, ma raramente ci si azzecca.
L'unica soluzione e' provare e prendere i tempi di esecuzioni e poi speculare sui risultati cercando di spiegarli.
Detto questo, ci siamo domandati se quell'algoritmo che averebbe necessitato di calcoli a 64 bit sarebbe stato meno veloce se implementato a 32 bit e abbiamo scoperto che i tempi di esecuzione non cambiavano.
Questo e' un dato di fatto, e' il risultato dell'esperimento.
Poi abbiamo provato a cercare di capire il perche' di questo risultato.

Un codice a 64 bit x girare su una CPU a 32 bit DEVE essere necessariamente implementato a 32 bit... non puoi eseguire calcoli a 64 bit in una sola passata, ma si devono spezzare in due parti da 32 bit....
partendo dal fattto ke ovviamente ne sei consapevole, o hai sbagliato a scrivere qualcosa, o sono io ke non riesco proprio a capire quello ke vuoi dire

La spiegazione e' semplice: un codice che richiede calcoli a 64 bit, implementato a 32 bit necessita di piu' istruzioni, ma spesso e volentieri il motore di esecuzione out of order, che ricordo si occupa di spostare le istruzioni di modo da ottimizzarne l'esecuzione, riesce a muovere queste istruzioni in piu' in colpi di clock che sarebbero altrimenti persi ad attendere che i dati arrivino dalla memoria.
Questa e' la norma in un'applicazione, che nella stragrande maggioranza dei casi e' memory bound. Chiaramente e' possibile immaginare particolari situazioni nelle quali inner loop molto corti che lavorano su dati molto coerenti verrebbero avvantaggiati dal poter fare calcoli nativi a 64 bit, ma questa e' un'eccezione rara.

Per questo e' molto raro notare questi fantomatici incrementi e nella maggior parte delle situazioni le CPU a 32 bit sono perfettamente in grado di eseguire codice a 64 bit senza perdita di prestazioni.

cmq x il fatto ke un codice a 64 bit sia più prestante, ormai credo non ci siano più dubbi, dato ke diversi siti online hanno riportato le prestazioni sia di programmi commerciali ricompilati a 64 bit ke di programmini scritti appositamente.....

E' proprio questo il punto, i dubbi ci sono e sono molto forti e all'atto pratico esistono molti casi in cui codice a 64 bit possa risultare anche piu' lento di codice a 32 bit.

Ecco uno di questi casi, tratto da un articolo di Herb Sutter che ho postato tempo fa:

(Aside: Here’s an anecdote to demonstrate “space is speed” that recently hit my compiler team. The compiler uses the same source base for the 32-bit and 64-bit compilers; the code is just compiled as either a 32-bit process or a 64-bit one. The 64-bit compiler gained a great deal of baseline performance by running on a 64-bit CPU, principally because the 64-bit CPU had many more registers to work with and had other code performance features. All well and good. But what about data? Going to 64 bits didn’t change the size of most of the data in memory, except that of course pointers in particular were now twice the size they were before. As it happens, our compiler uses pointers much more heavily in its internal data structures than most other kinds of applications ever would. Because pointers were now 8 bytes instead of 4 bytes, a pure data size increase, we saw a significant increase in the 64-bit compiler’s working set. That bigger working set caused a performance penalty that almost exactly offset the code execution performance increase we’d gained from going to the faster processor with more registers. As of this writing, the 64-bit compiler runs at the same speed as the 32-bit compiler, even though the source base is the same for both and the 64-bit processor offers better raw processing throughput. Space is speed.)

http://www.gotw.ca/publications/concurrency-ddj.htm

È ovvio ke questi incrementi non ci sono in TUTTE le applicazioni, anzi in alcune abbiamo pure un decremento a causa dei motivi che giustamente hai riportato, però la MAGGIOR PARTE di esse presentava degli incrementi sostanziali, superiori ai decrementi ke si avevano in quelle poke applicazioni.

IMHO i 64 bit, sono un passo importante ke ci regaleranno un buon incremento prestazionale. Dopotutto in ambito di encoding video si parla di incrementi del 15% SOLAMENTE utilizzando winxp 64 con un encoder a 32 bit.... onestamente mi para un pò difficile ke utilizzando encoders a 64 bit le prestazioni peggiorino....

E' l'esatto contrario, solo in situazioni particolarmente di nicchia si possano notare questi incrementi prestazionali, ma nella maggior parte dei casi no. Posso immaginare che alcuni encoder possano avere inner loop che beneficino di istruzioni a 64 bit.

Originariamente inviato da ^TiGeRShArK^
tieni conto ke se ti metti a scrivere da un portatile disteso sul letto non ti viene motlo comodo usare la tastiera, qdi tenti di ridurre AL MASSIMO i tasti da premere.... e una volta ke mi ritrovo sul computer fisso mi resta l'abitudine.... un pò come qdo si è abituati a scrivere "e', perche', cioe'" dato ke in molte applicazioni su internet vengono visualizzati male (MUD, TELNET....)

Stai speculando, ma i dati che ho visto dipingono scenari diversi.
Risolvere la questione e' molto semplice: scrivi un pezzo di codice, compilalo a 32 e 64 bit e guarda le differenze di prestazioni

Noi lo abbiamo fatto, Sutter lo ha fatto, nessuno dei due ha trovato differenze.

Per favore scrivi senza k, si fa molta fatica a leggerti ed e' un segno di rispetto verso chi ti legge non affaticarlo inutilmente.

[cdimauro]

Originariamente inviato da GiovanniGTS
e per le vecchie applicazioni 16 bit non c'e' proprio nessuna speranza o saranno eseguibili tramite l'opzione di compatibilita' ?

Non credo: dovrebbero essere del tutto abbandonate.

Comunque se dopo vent'anni dall'introduzione dei 386 hai ancora l'esigenza di far girare software a 16 bit, puoi sempre affidarti agli emulatori: anche se in emulazione, i processori attuali permettono di far girare molto velocemente le applicazioni a 16 bit.

[fek]

Per arricchire la discussione vorrei portare un esempio pratico, ma e' un po' tecnico.

Ho preso una funzione molto semplice che calcola la seguente espressione con interi a 64 bit:

risultato = (x + y) * (x - y)

Questa e' la funzione:

void __fastcall func_64(
	__int64* res,
	__int64 arg1,
	__int64 arg2)
{
	__int64 res1 = *arg1 + *arg2;
	__int64 res2 = *arg1 - *arg2;

	*res = res1 * res2;
}

L'espressione calcolata potrebbe essere piu' complicata, ma questo non cambierebbe di molto la situazione (a meno che non ci sia un inner loop totalmente non memory bound, ma e' una situazione piuttosto rara come abbiamo detto).

Questa funzione viene compilata nel seguente codice asm su architettura X86:

00677ED8  push        ebp  
00677ED9  mov         ebp,esp 
00677EDB  mov         eax,dword ptr [ebp+8] 
00677EDE  push        esi  
00677EDF  push        edi  
00677EE0  mov         esi,ecx 
00677EE2  mov         ecx,dword ptr [ebp+0Ch] 
00677EE5  mov         edx,eax 
00677EE7  sub         edx,dword ptr [arg2] 
00677EEA  mov         edi,ecx 
00677EEC  sbb         edi,dword ptr [ebp+14h]   ; (*)
00677EEF  add         eax,dword ptr [arg2] 
00677EF2  adc         ecx,dword ptr [ebp+14h]   ; (*)
00677EFE  pop         edi  
00677EFF  mov         dword ptr [esi],eax 
00677F01  mov         dword ptr [esi+4],edx 
00677F04  pop         esi  
00677F05  pop         ebp  
00677F06  ret         10h

Ho marcato con (*) le istruzioni in piu' che sono necessarie per effettuare un calcolo a 64 bit su una CPU a 32 bit. E' da notare che tutte le volte che vedere "dword ptr [qualcosa]" la CPU sta facendo un accesso alla memoria che puo' essere in cache ma puo' anche non esserlo. Ogni accesso alla memoria puo' lasciare teoricamente la CPU in attesa a far nulla per qualche ciclo di clock o anche per migliaia di cicli di clock (a seconda che il dato sia in cache oppure no). Tutte le CPU moderne cercano di trovare qualcosa da fare alla CPU durante queste attese, implementano pipeline lunghe con molti stadi, riordinano le istruzioni, eseguono addirittura altri processi in quei cicli di clock altrimenti persi (HyperThreading). Molto probabilmente le istruzioni che ho marcato con (*) verranno schedulate per essere eseguite molto vicine ad uno degli accessi alla memoria per tenere occupata la CPU che altrimenti non avrebbe avuto nulla da fare. Quelle istruzioni in piu' che servono per fare calcoli a 64 bit molto probabilmente saranno gratuite in questo esempio.

Ovviamente in caso di calcoli piu' complessi, funzioni piu' lunghe, cicli piu' stretti, usare meno registri permetterebbe di ridurre gli accessi alla memoria, come e' possibile che che il working set piu' ampio peggiori le prestazioni della cache; si possono dipingere molti scenari.

La sintesi di questo discorso e' che non e' affatto detto che ricompilare un programma a 64 bit dia un incremento prestazionale enorme, in generale non cambiera' molto probabilmente nulla.

Spero di essere stato chiaro perche' il post e' un po' tecnico e noioso.

[cdimauro]

x fek: indubbiamente non tutte le applicazioni beneficeranno dei vantaggi offerti dall'architettura x86-64, ma mediamente dovremmo assistere a un aumento delle prestazioni nell'ordine del 15-20% (questi dati li fornì AMD, penso circa 3 anni fa, dai risultati delle simulazioni che fece).

Ad esempio, se prendiamo i test effettuati lo scorso anno con la beta di XP/64, notiamo che la compressione di un video con XviD è migliorata del 15% (in meno del tempo di esecuzione), pur essendo programma e codec a 32 bit.

Le prove con i giochi hanno fatto vedere che, a causa dei driver immaturi, le prestazioni fino a 1024x768 erano nettamente inferiori all'esecuzione degli stessi con XP (a 32 bit), ma andavano via via migliorando e addirittura a 1280x1024 erano migliori: quindi il layer WOW64 è stato capace di sopperire, e addirittura di migliorare, ai problemi dei driver.

Le prove fatte con Linux hanno evidenziato che POVRay e MySQL compilati a 64 bit e fatti girare sul s.o. a 64 bit hanno avuto incrementi prestazionali anche superiori al 40% sulla stessa macchina, ma con le medesime versioni a 32 bit.

E' chiaro che, come giustamente sottolinei, nell'usare i puntatori a 64 bit siamo in presenza di una perdita di prestazioni, ma è anche evidente che il maggior numero di registri general purpose disponibili (anche per le SSE), unito all'ortogonalità dei registri (che aiuta i compilatori) e alla presenza di una modalità d'indirizzamento relativa al PC, hanno contribuito, e non poco, a sanare questa perdita e mediamente ad ottenere dei risultati migliori.

E' anche chiaro che non interessa a nessuno sapere che la GUI delle applicazioni, che fanno ampio uso di oggetti e quindi di puntatori, avranno generalmente un decadimento prestazionale, ma è anche vero che gli incrementi che interessanno e che fanno veramente la differenza le vediamo non con le GUI, ma con l'esecuzione di applicazioni che effettuano dei calcoli intensivi, e queste normalmente beneficeranno del nuovo ambiente, come appare appunto dagli esempi che ho citato.

Io non conosco il contesto delle prove che avete fatto, per cui non mi posso esprimere in merito: avete sicuramente trovato un esempio in cui non c'è differenza fra l'esecuzione di codice a 32 e a 64 bit.
Ma ti posso anche dire che, se devo effettuare una conversione dallo spazio RGB allo YUV (o YCbCr o altro) o viceversa, trovo decisamente molto comodo e molto più efficiente / veloce poter utilizzare una moltiplicazione 32x32 -> 64 bit e usare poi le istruzioni a 64 bit per manipolare queste quantità, anziché ricorrere ai long long "emulati" con istruzioni a 32 bit. Questo per fare un altro esempio.
Dipende tutto dal tipo di algoritmo che si deve implementare.

EDIT: ho appena visto l'altro messaggio che hai postato, e sono d'accordo.

[fek]

Originariamente inviato da cdimauro
Dipende tutto dal tipo di algoritmo che si deve implementare.

Esatto dipende troppo dalla situazione, non si puo' assolutamente dire che mediamente si vedra' un aumento del 15/20%, anzi; dai, nessuno crede ai risultati forniti dalle simulazioni dei reparti di marketing, vero?

MySQL mi sembra sospetto, hai un link a questa prova? Sono curioso. PovRay e XVid sicuramente possono beneficiare.

[capitan_crasy]

Originariamente inviato da Vifani
Creative ha già rilasciato driver per le schede Audigy 2 compatibili con Windows XP a 64 bit. Sono in versione beta.

http://preview.creativelabs.com

grazie...

[repne scasb]

[RaouL_BennetH]

Originariamente inviato da fek

......

La sintesi di questo discorso e' che non e' affatto detto che ricompilare un programma a 64 bit dia un incremento prestazionale enorme, in generale non cambiera' molto probabilmente nulla.

Spero di essere stato chiaro perche' il post e' un po' tecnico e noioso.

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?

[cdimauro]

Originariamente inviato da fek
Esatto dipende troppo dalla situazione, non si puo' assolutamente dire che mediamente si vedra' un aumento del 15/20%, anzi; dai, nessuno crede ai risultati forniti dalle simulazioni dei reparti di marketing, vero?

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

MySQL mi sembra sospetto, hai un link a questa prova? Sono curioso. PovRay e XVid sicuramente possono beneficiare.

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/c.../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/c.../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?

[cdimauro]

Originariamente inviato da repne scasb
Se interessa posso produrre il codice di alto livello postato da fek sia in assembly x86_32 che in assembly x86_64, cosi da poterne apprezzae le differenze.

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).

[cdimauro]

Originariamente inviato da RaouL_BennetH
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, per ricompilare s'intende prendere i sorgenti già esistenti per un'applicazione, e generare l'eseguibile per una specifica architettura.

[^TiGeRShArK^]

Originariamente inviato da fek
Esatto dipende troppo dalla situazione, non si puo' assolutamente dire che mediamente si vedra' un aumento del 15/20%, anzi; dai, nessuno crede ai risultati forniti dalle simulazioni dei reparti di marketing, vero?

MySQL mi sembra sospetto, hai un link a questa prova? Sono curioso. PovRay e XVid sicuramente possono beneficiare.

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]

[fek]

Originariamente inviato da repne scasb
1) Il codice: [...]

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

6) Un ultimo appunto sul compilatore che stai utilizzando: sta leggendo in memoria arg2_(64-bbit) due volte, sei sicuro di aver attivato tutte le ottimizzazioni possibili?

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

Se interessa posso produrre il codice di alto livello postato da fek sia in assembly x86_32 che in assembly x86_64, cosi da poterne apprezzae le differenze.

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.

[fek]

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

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...