Microsoft Windows XP 64 bit: ormai manca poco!

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

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

sai che perdit...

non ci dormo la notte...

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

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.



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.





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:



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



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.



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.

Re: Re: Non facciamo confusione...

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.

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:

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

*res = res1 * res2;
}
[/code]

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:

[code]
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
[/code]

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.

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.

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.