Con riferimento a http://blogs.ugidotnet.org/RobyMes/archive/2005/11/25/30516.aspx riporto (ed aggiorno) un post dell'altro mio blog.
Scrivevo in Agosto:
Complice un weekend di ferragosto veramente orrendo ho fatto qualche esperimento a 64 bit. Alcune cose che ho scoperto:
1) Installare ed usare Windows Xp 64 bit è veramente come Xp normale. E' un po un problema trovare i driver ma quelli fondamentali li ha beccati al primo colpo (almeno nel mio caso di macchina Compaq come la mia) e i due che non ha trovato (scheda video e scheda audio) li ho trovati molto facilmente sui siti dei produttori. Mi mancano quelli del Tuner TV ma ammetto che sono abbastanza poco fondamentali. Anche l'utilizzo è assolutamente trasparente, dentro l'XP 64 esiste il WOW64 (Windows on Windows 64) che consente di far girare in automatico tutto il codice a 32 bit senza problemi e (almeno per AMD) senza nessun peggioramento di performance. Vedremo poi ai punti 2 e 3 che, molto probabilmente, installare il sistema operativo a 64 bit è un po da fanatici visto che non ci sono miglioramenti di sostanza.
2) Fatto questo la scoperta migliore (o peggiore) è che con Visual Studio 2005 non si sviluppa a 64 bit, almeno per quello che riguarda me (sviluppo C#). In sostanza la cosa funziona così:
- I nuovi assembly di .Net versione 2.0 sono firmati in un nuovo modo (chiamato PE+, bella fantasia) in cui è possibile specificare a livello di attributo se l'assembly sia "agnostico", solo 32 bit oppure specifico a 64 bit per una delle due architetture (x64, che è quella che usa AMD oppure Itanium di Intel, tecnologia che probabilmente morirà in fretta a causa della sua inferiorità rispetto a quella AMD)
- Un assembly agnostico è un assembly che dovrebbe funzionare senza problemi a 32 o 64 bit, in sostanza qualunque codice che sia solo managed non ha problemi, nel momento in cui invece il codice utilizzi delle chiamate con PInvoke o con interoperability verso oggetti COM la compatibilità non è garantita e deve essere testata (o si può dire che il codice deve essere eseguito a 32 bit forzando la firma dell'assembly a 32 bit only)
- Visual Studio o i compilatori continuano a funzionare regolarmente a 32 bit e l'unica cosa che fanno è produrre Assembly con le opportune firme a seconda delle opzioni di compilazione scelte
- Il runtime, quando esegue l'Assembly, incrocia le informazioni che ci sono sul PE+ e l'architettura disponibile sul sistema e lancia l'assembly nel modo opportuno, quindi un assembly agnostico verrè lanciato a 32 o 64 bit a seconda della piattaforma su cui sta girando, se invece è marcato obbligatoriamente a 64 bit in caso di lancio su un sistema a 32 bit (come processore o come sistema operativo) verrà generato un errore
- E' comunque necessario installare su XP 64 la versione a 64 bit del Framework, che viene distribuito a parte probabilmente per motivi di dimensioni (dato che al suo interno contiene sia il framework a 32 che quello a 64), visto che è oltre 40 Mb di download
- Non esiste la possibilità di debuggare in modo nativo ed in locale con Visual Studio 2005 su ambiente a 64 bit, l'unica modalità di debug supportata è quella di lavorare su un PC desktop a 32 bit e debuggare l'applicazione 64 bit in remoto
3) Detto questo cosa si ottiene usando un ambiente a 64 bit? Sostanzialmente più memoria a disposizione complessiva, ma comunque il limite per i singoli oggetti rimane a 2 Gb. Quindi non si può fare un array da 16 Gbyte ma si possono fare 8 array da 2 Gb. Questo genera sicuramente delle grandi migliorie per tutte le applicazioni in cui ci siano anche molti oggetti perchè fino ad ora, a 32 bit era la memoria complessiva ad essere limitata a 2 Gb (ed in realtà erano di meno perchè comunque, per via delle varie attività di housekeeping fatte da .Net, in scenari reali anche con macchine con svariati Gb di ram il singolo processo .Net inizia comunque a dare degli Out Of Memory quando si passa la barriera dei 1300 Mb per via del fatto che non si trova più memoria contigua libera, ma questo è un altro discorso). Dal punto di vista delle performance un'applicazione managed eseguita a 64 bit, in alcune situazioni, potrebbe anche essere leggermente più lenta dato che la gestione dei puntatori a 64 bit è più costosa rispetto a quella 32
Aggiorno ora:
Se ho avuto un weekend di brutto tempo in Agosto domani si preannuncia neve e quindi quello che farò, molto probabilmente, sarà disinstallare XP64 per mettere su un XP normale. Questo perchè ho fatto una verifica e praticamente tutti i miei programmi sono a 32 bit ed installare su ambienti a 64 bit WinFX o altre componenti beta è veramente una tragedia.
Quindi nella sostanza non cambia quasi nulla: i 64 bit servono il giusto su un desktop, però l'implementazione di AMD è fatta talmente bene che vale la pena prendere un AMD64 a prescindere...
posted @ venerdì 25 novembre 2005 22:57