Sentir parlare di 32 e 64 bit mi porta alla mente i miei primi esperimenti con l'informatica "seria" ad 8 bit.......
In realtà il discorso 32/64 bit è parecchio complesso e arriva dopo anni di continue estensioni rispetto ai primissimi processori x86 (e limiti impostati per mantenere la compatibilità binaria).
Ad esempio il limite di utilizzo dei 4GB di Windows è solo teorico ed è un limite fissato da Microsoft: con il sistema PAE, quindi una funzionalità del processore, si riescono ad indirizzare fino a 64GB totali anche su sistemi a 32 bit (Windows, Linux, ecc):
http://it.wikipedia.org/wiki/Physical_Address_Extension
Questo limite assomiglia parecchio a quello di non dotare i sistemi XP di un gestore raid, che però guardacaso si abilita cambiando due soli byte di un paio di file .sys che si trovano in system32... quindi credo proprio che sia un comportamento voluto per evitare di usare XP su ambienti server o con risorse più potenti (idem per i limiti dei core/cpu nell'hardware smp).
Poi ci sono un sacco di altri limiti (sotto Windows) come i 2GB max per il kernel e i 2GB max per le applicazioni, quindi anche se ho 64GB di memoria il mio processo non potrà mai indirizzare più di 2GB, e la memoria condivisa del kernel ad ogni modo non potrà oltrepassare i primi 2GB. E c'è pure quello dei 3.2GB max totali assoluti, quindi ben al di sotto dei 4GB.
Ci sono diversi modi per ottimizzare la gestione della memoria ma qui entriamo in un argomento complesso e sconfinato... io al tempo avevo fatto qualcosina poi però non ho potuto più dedicarci risorse. Passando ai 64 bit con Linux i limiti sono quasi del tutto scomparsi, con Windows alcuni ne sono rimasti ma comunque direi del tutto accettabili per un desktop.
I sistemi 64 bit "maneggiano" dei dati che sono grandi il doppio, quindi potrebbero impiegare di più a processare la coda delle istruzioni e per salvare i registri (e non potrà salvarne mezzo alla volta, anzi dovrà usare qualche multiplo legato al bus che ci sta attorno).
Poi alcuni processori avevano un sistema di ottimizzazione fantastico per cui potevano eseguire contemporaneamente due set di istruzioni 32-bit (o per meglio dire, potevano evitare di andare a recuperare i dati perchè li avevano già a disposizione) ma ovviamente qui entrano in gioco anche problemi di sincronizzazione e multitasking (non dei programmi, ma delle singole istruzioni macchina processate). Con il multicore la complicazione è aumentata drasticamente, tanto che iniziavano a comparire i primi algoritmi di predizione del codice, che quindi eseguivano in parallelo alcuni pezzi di codice successivi perchè probabilmente li avrebbe incontrati alla fine di quell'esecuzione, cosa che poteva anche non capitare ovviamente facendo sprecare un sacco di risorse
Scrivendo programmi in maniera particolare potevi quindi ottimizzare parecchio il caricamento dei dati e riuscivi ad avere un guadagno in termini di prestazioni molto alto.
Dato però che Windows va sul dual core/i3/i5 di Intel o Amd, in genere i kernel hanno cercato di non ottimizzare troppo ed usato le istruzioni comuni un po' a tutti (i requisiti minimi servono anche per capire quali istruzioni avanzate si potevano usare). Anche con Linux è così, ma basta ricompilare ed ottimizzare il kernel per avere un pochino più di prestazioni.
Ovviamente il kernel è solo uno dei tanti programmi in esecuzione, poi ci sono i mille programmi/servizi accessori che lo rendono funzionante ed interattivo (sistema operativo, driver grafici, driver di rete, processi in background, risoluzione nomi, ecc) e poi il programma utente. Tutto gestito da interrupt (che interrompono appunto la normale elaborazione) o schedulatori.
Io sinceramente non ho notato miglioramenti apprezzabili fra 32 e 64 bit, magari parliamo di 1 secondo su 20 e il disco fisso potrebbe invalidare qualsiasi ottimizzazione perchè ogni volta che si sale in complessità e dimensioni i tempi cambiano di un ordine di grandezza (cpu -> cache primo livello -> cache secondo livello -> ram -> controller -> dischi).
I miglioramenti in genere arrivano se il programmatore ha previsto l'utilizzo dell'architettura a 64 bit e agito di conseguenza, ma non si ottengono magicamente ricompilando (anzi, spesso alcuni programmi non si ricompilano nemmeno per via di limiti strutturali... ma qui la cosa meriterebbe un discorso più ampio).
Tutto questo per dire che bisogna semplicemente provarlo, ovvero se il sistema funziona bene a 32 non aspettiamoci un incremento significativo a 64 bit, anzi in alcune condizioni potrebbe essere peggio (troppe variabili in gioco).
Viceversa, se l'utilizzo dei 32 bit non è molto diffuso ed il programmatore cercherà di avvantaggiarsi della nuova architettura ottimizzando all'estremo il programma e sfruttando istruzioni disponibili solo per quel tipo di processore, allora vedrai le prestazioni aumentare sensibilmente. Ad esempio le istruzioni MMX che erano disponibili nei primi Pentium a 166Mhz (se ricordo bene) hanno prodotto incrementi davvero notevoli per l'epoca. A quelle sono state aggiunte nel tempo nuove istruzioni sempre più complesse, in genere ad ogni cpu nuova corrispondeva un set esteso specifico. Ovviamente se usi quelle istruzioni nuove il programma non girerà mai sui vecchi processori. L'estensione exe è un po' fuorviante perchè il programma è legato all'architettura e quindi sarebbe il caso di parlare di exe32, exe64, ecc.
La cache del processore invece è molto importante, ma è un componente costosissimo e porta ad avere cpu gigantesche, con problemi di riscaldamento e tutto il resto.
E' per quello che ne mettono sempre pochissimo/nessuna nelle cpu meno performanti (ad es. i Celeron erano Pentium con pochissima cache). Mi riferisco alla cache di primo, secondo e terzo livello (in ordine di importanza), mentre la ram viene considerata di quarto livello. La L3 a volte non era presente e nei nuovi processori tipo l'i7 ormai esiste una cache unica più "intelligente", ma credo che alla fine ci sia la stessa differenza di una scheda grafica con ram dedicata super veloce ed una che utilizza quella di sistema (lentissima... almeno per la cpu
)
Sul discorso dei monitor arcade invece è sempre più difficile trovare schede video in grado di supportarli perchè semplicemente è un settore nel quale non si investe più.
Ora ci sono risoluzioni 4-5K con gli 8K all'orizzonte, o magari 2-4 monitor, quindi servono veri e proprio mostri anche solo per disegnare il desktop.
La risoluzione di 320x200 pixel è praticamente scomparsa e quella 640x480 rimane per compatibilità... purtroppo
Mamma mia quanto ho scritto... argomento interessantissimo quello dei processori.... ma qui siamo in un forum arcade...
Spero non ci siano troppi errori e di aver confuso ancor di più le idee
) ...
) hai altra presenza a video?
