Apple e Intel, ancora indiscrezioni

[quartz]

Originariamente inviato da cdimauro

Perché il G5 in modalità a 64 bit non offre nient'altro che registri dati a 64 bit e indirizzi a 64 bit. Questo vuol dire che:

1) il context switch passando da un processo/thread a un altro richiede più tempo (i dati da salvare/caricare sono di più, visto che quasi tutti i registri occupano il doppio dello spazio);

2) i puntatori occupano il doppio dello spazio; questo vuol dire che è richiesto più tempo per il loro caricamento/salvataggio richiede più tempo; inoltre occupando più spazio viene ridotto il numero di dati da caricare nelle cache dati, e quindi è più facile che si verifichino dei cache miss; poiché i puntatori sono molto utilizzati, puoi immaginare quanto questo possa inficiare le prestazioni (infatti è IL fattore che determina in buona sostanza il loro calo in questo caso).

I G5 però, a quanto ho letto, hanno la caratteristica di avere una branch prediction estremamente efficiente.
In più gli ultimi modelli hanno una cache di 1MB, quindi in parte recuperano .
Cmq sappi che neanche io sono un particolare estimatore dei G5. Secondo me hanno fatto un passo indietro, specie dal punto di vista dell'efficienza, rispetto ai G4. Hanno tolto, infatti, quella che era la caratteristica migliore dei G4, cioè la pipeline estremamente corta (7 stadi, contro 16 dei G5), e questo solo nella speranza di salire velocemente in frequenza (s'è visto infatti)

In ogni caso IMHO i 64 bit sono una pura mossa commerciale da parte dei produttori di CPU (AMD in primis). A livello domestino non erano così necessari. In campo scientifico e/o server, magari sì.

[jo.li.]

Originariamente inviato da cdimauro

Vuol dire avere s.o. e applicazioni che usano registri a 64 bit per dati e indirizzi.

Oltre a ciò è anche un problema di processore, visto che i PowerPC non sono più competitivi da tempo (parlando in generale ovviamente: poi ci sono casi specifici in cui sono la soluzione migliore).

Mi sa che stai generalizando un pò troppo, è chiaro che in alcuni casi riscrivere il codice a 64bit può avere dei vantaggi anche dal punto di vista prestazionale e forse dei svantaggi in altre situazioni ma se la Apple non ha riscritto il suo OS interamente a 64bit è perché ancora vende cpu che sono a 32bit e poi perché evidentemente le risorse da impiegare sarebbero state troppe in relazione ai vantaggi ottenuti.

Anche per i PowerPc mi sà che stai esagerando e generalizzando un pò troppo sembra quasi che tu stia parlando dei 68000. In prospettiva forse non sarerebbero più stati competitivi, ma adesso lo sono abbastanza.

[jo.li.]

Originariamente inviato da cdimauro

E io cosa avrei detto di diverso?

Questo:

"Se l'applicazione gestisce l'indirizzamento a 64 bit si possono anche avere dei benefici accedendo a più di 4GB di memoria (dipende dal tipo di codice, ovviamente)."

Addirittura me l'hai anche quotato!

E' chiaro che se un'applicazione che gestisce i 64bit eccede i 4GB di memoria, ma poi tu avevi continuato dicendo che per il s.o. e i driver e le applicazioni "normali" il limite era di 4GB totali, e che tutto quello che eccedeva tale limite veniva utilizzato come cache dal sistema operativo, io ti ho fatto notare che nel MacOs X questo non è vero.

[Criceto]

Originariamente inviato da cdimauro

Cosa non è ti chiaro di questo:

?

Sei sempre il solito fanboy.

Oltre a sbagliare, sei perseverante nell'errore.
Ti è già stato spiegato 1000 volte come funzionano i 64bit di Tiger.
Non è come dici tu.

[Criceto]

Originariamente inviato da cdimauro

Perché il G5 in modalità a 64 bit non offre nient'altro che registri dati a 64 bit e indirizzi a 64 bit. Questo vuol dire che:

E perchè. cos'altro dovrebbero includere questi fantomatici 64 bit?
Qual'è la definizione di processore a 64bit? E di applicazione a 64 bit?
Illuminaci...

[xeal]

Originariamente inviato da Criceto

E perchè. cos'altro dovrebbero includere questi fantomatici 64 bit?

I 64 bit, di per sé, NIENTE.

La modalità a 64 bit (ovvero una implementazione dei 64 bit), poichè aggiunge comunque degli opcode, ovvero delle istruzioni nuove, potrebbe aggiungere anche delle funzionalità non disponibili in modalità a 32 bit, come nuove funzioni di calcolo (faccio un esempio banale e generico, senza riferimenti ad alcuna architettura: si potrebbe destinare uno dei nuovi opcode a un'istruzione che esegua la radice quadrata di un numero e aggiungere al processore la logica per calcolarla rapidamente, invece di usare più istruzioni e fare più calcoli - usando anche più registri), oppure anche nuove caratteristiche "interne", come l'aggiunta di nuovi registri.

L'architettura x86-64 (come l'equivalente EM64T di Intel) fa esattamente questo, fermo restando il "problema" di avere puntatori alla memoria più "grossi" per quelle applicazioni che non necessitano di molta memoria (e per le quali gli eventuali cache miss causati da molti puntatori a 64 bit potrebbero essere rilevanti).

Di conseguenza, un'implementazione dei 64 bit che "approfitta" dell'occasione per aggiungere qualosa di utile, come fa x86-64, presentera un comportamento (faccio una schematizzazione MOLTO generica) di questo tipo:

- in alcuni casi il problema "puntatori dopati" produrrà un calo prestazionale;

- in alcuni casi le caratteristiche "interne" e le nuove funzionalità aggiunte insieme alle nuove istruzioni compensano e annullano lo svantaggio precedente (se proprio non riescono a ribaltare la situazione);

- in alcuni casi (ad esempio, semplificando, applicazioni che elaborano dati a 32 bit, ma hanno bisogno di molta memoria, oppure eseguono molte operazioni e pochi accessi alla memoria e, avendo a disposizione più registri, possono ridurre ulteriormente gli accessi alla memoria) si hanno dei vantaggi prestazionali - piccoli, medi o grandi che siano;

- in alcuni casi (applicazioni che manipolano dati a 64 bit e hanno bisogno di molta memoria e/o di più registri) si hanno dei vantaggi prestazionali - piccoli, medi o grandi che siano.

Ne segue che (diciamo) mediamente o si hanno dei vantaggi, o non si hanno degli svantaggi, e cioè si hanno ancora dei vantaggi, perchè, nel caso in cui avere puntatori più "grossi" non comporta, complessivamente, uno svantaggio, il poter disporre di più memoria ram limita lo swap su hd, aumentando potenzialmente (la memoria "in più" chiaramente bisogna averla) le prestazioni con molti processi in esecuzione (questo potrebbe avvenire anche con le applicazioni per le quali i puntatori "dopati" cosituiscano un problema, poichè all'aumento di cache miss corrisponderebbe potenzialmente una diminuizione di page fault e accessi al disco; in ogni caso, sempre potenzialmente, sono di più i casi possibili in cui i vantaggi superano gli svantaggi).

Se invece si implementano i 64 bit in maniera "basilare", senza alcuna aggiunta/miglioria a contorno, è evidente che si possono avere vantaggi praticamente solo con applicazioni che elaborano massicciamente dati a 64 bit e/o necessitano di grandi quantità di memoria; in tutti gli altri casi, con gli applicativi già ben ottimizzati per l'architettura "di base" a 32 bit, alla quale sono stati semplicemente aggiunti 32 bit di dati in ciascun registro (senza aumentare il numero complessivo di registri - cosa che non è detto sia necessaria, comunque) e agli indirizzi di memoria, senza migliorare niente (che non si manifesti già in modalità a 32 bit), si rischia di avere dei cali prestazionali anche notevoli (e questo è tanto più vero, quanto più piccola è la quantità di ram richiesta dalle applicazioni e quanto minore è il numero di processi in esecuzione contemporanea).

E se il G5 applica il concetto dei 64 bit "nudo e crudo" ricade inevitabilmente in questa categoria. Se non vado errato è proprio per questo motivo che i programmi a 64 bit per OS X hanno un'interfaccia a riga di comando (o comunque non grafica).

Chiaramente tutto questo non ha nulla a che vedere con la definizione di processore a 64 bit; semplicemente ciò che sta a "contorno" e integra l'implementazione dei 64 bit può estenderne o limitarne l'utilità/i vantaggi, ovviamente parlando solo di ciò che si rende disponibile con le nuove istruzioni non disponibili se non "attivando" i 64 bit: in questo contesto non contano le migliorie che, ad esempio, possono essere state introdotte nei G5 rispetto ai G4 e sono disponibili anche per i programmi a 32 bit, così come non conta, per gli Athlon64, la maggiore velocità sulle moltiplicazioni intere a 32 bit (che è la stessa in tutte le modalità).

[Criceto]

Originariamente inviato da xeal

I 64 bit, di per sé, NIENTE.

La modalità a 64 bit (ovvero una implementazione dei 64 bit), poichè aggiunge comunque degli opcode, ovvero delle istruzioni nuove, potrebbe aggiungere anche delle funzionalità non disponibili in modalità a 32 bit, come nuove funzioni di calcolo (faccio un esempio banale e generico, senza riferimenti ad alcuna architettura: si potrebbe destinare uno dei nuovi opcode a un'istruzione che esegua la radice quadrata di un numero e aggiungere al processore la logica per calcolarla rapidamente, invece di usare più istruzioni e fare più calcoli - usando anche più registri), oppure anche nuove caratteristiche "interne", come l'aggiunta di nuovi registri.

L'architettura x86-64 (come l'equivalente EM64T di Intel) fa esattamente questo, fermo restando il "problema" di avere puntatori alla memoria più "grossi" per quelle applicazioni che non necessitano di molta memoria (e per le quali gli eventuali cache miss causati da molti puntatori a 64 bit potrebbero essere rilevanti).

Di conseguenza, un'implementazione dei 64 bit che "approfitta" dell'occasione per aggiungere qualosa di utile, come fa x86-64, presentera un comportamento (faccio una schematizzazione MOLTO generica) di questo tipo:

- in alcuni casi il problema "puntatori dopati" produrrà un calo prestazionale;

- in alcuni casi le caratteristiche "interne" e le nuove funzionalità aggiunte insieme alle nuove istruzioni compensano e annullano lo svantaggio precedente (se proprio non riescono a ribaltare la situazione);

- in alcuni casi (ad esempio, semplificando, applicazioni che elaborano dati a 32 bit, ma hanno bisogno di molta memoria, oppure eseguono molte operazioni e pochi accessi alla memoria e, avendo a disposizione più registri, possono ridurre ulteriormente gli accessi alla memoria) si hanno dei vantaggi prestazionali - piccoli, medi o grandi che siano;

- in alcuni casi (applicazioni che manipolano dati a 64 bit e hanno bisogno di molta memoria e/o di più registri) si hanno dei vantaggi prestazionali - piccoli, medi o grandi che siano.

Ne segue che (diciamo) mediamente o si hanno dei vantaggi, o non si hanno degli svantaggi, e cioè si hanno ancora dei vantaggi, perchè, nel caso in cui avere puntatori più "grossi" non comporta, complessivamente, uno svantaggio, il poter disporre di più memoria ram limita lo swap su hd, aumentando potenzialmente (la memoria "in più" chiaramente bisogna averla) le prestazioni con molti processi in esecuzione (questo potrebbe avvenire anche con le applicazioni per le quali i puntatori "dopati" cosituiscano un problema, poichè all'aumento di cache miss corrisponderebbe potenzialmente una diminuizione di page fault e accessi al disco; in ogni caso, sempre potenzialmente, sono di più i casi possibili in cui i vantaggi superano gli svantaggi).

Se invece si implementano i 64 bit in maniera "basilare", senza alcuna aggiunta/miglioria a contorno, è evidente che si possono avere vantaggi praticamente solo con applicazioni che elaborano massicciamente dati a 64 bit e/o necessitano di grandi quantità di memoria; in tutti gli altri casi, con gli applicativi già ben ottimizzati per l'architettura "di base" a 32 bit, alla quale sono stati semplicemente aggiunti 32 bit di dati in ciascun registro (senza aumentare il numero complessivo di registri - cosa che non è detto sia necessaria, comunque) e agli indirizzi di memoria, senza migliorare niente (che non si manifesti già in modalità a 32 bit), si rischia di avere dei cali prestazionali anche notevoli (e questo è tanto più vero, quanto più piccola è la quantità di ram richiesta dalle applicazioni e quanto minore è il numero di processi in esecuzione contemporanea).

E se il G5 applica il concetto dei 64 bit "nudo e crudo" ricade inevitabilmente in questa categoria. Se non vado errato è proprio per questo motivo che i programmi a 64 bit per OS X hanno un'interfaccia a riga di comando (o comunque non grafica).

Chiaramente tutto questo non ha nulla a che vedere con la definizione di processore a 64 bit; semplicemente ciò che sta a "contorno" e integra l'implementazione dei 64 bit può estenderne o limitarne l'utilità/i vantaggi, ovviamente parlando solo di ciò che si rende disponibile con le nuove istruzioni non disponibili se non "attivando" i 64 bit: in questo contesto non contano le migliorie che, ad esempio, possono essere state introdotte nei G5 rispetto ai G4 e sono disponibili anche per i programmi a 32 bit, così come non conta, per gli Athlon64, la maggiore velocità sulle moltiplicazioni intere a 32 bit (che è la stessa in tutte le modalità).

Tutto ciò è bellissimo ma va al di là del fatto che il G5 e Tiger siano a 64bit o meno. Lo sono. Il G5 in toto, Tiger solo quando ha senso (per i motivi che anche tu hai esposto) a discrezione dello sviluppatore. Direi con una soluzione ottimale allo stato delle cose, visto che un OS puro a 64 bit al momento attuale sarebbe controproducente.

Se poi Intel e AMD hanno approfittato del passaggio a 64 bit anche per dare una "svecchiata" alla loro architettura e renderla più efficiente prescinde la constestazione (come sempre pretestuosa, pedante, errata, noiosa, ecc) di Cdimauro riguardo ai G5 e OS X.

Sarà interessante, a questo punto, vedere come Apple si comporterà con il passaggio ad Intel. Anche perchè non ho capito se questi vantaggi architetturali degli Intel 64bit siano utilizzabili SOLO in modalità 64 bit o meno e se nel caso sono presenti (ad esempio) nel Yonah che è un processore a 32bit.

[bjt2]

I vantaggi architetturali, ossia il numero di registri in più, sono presenti SOLO in modalità a 64 bit. Non mi pare che siano state introdotte nuove istruzioni, usabili anche in modalità 32 bit, ma potrei sbagliarmi.

[bjt2]

AMD ha approfittato del fatto di cambiare architettura per supportare 40 bit per la memoria fisica, anzichè 36, ma questo poteva essere fatto indipendentemente dai 64 bit (per intenderci avrebbe potuto farlo anche sugli Atlon XP, ma avrebbe, forse, dovuto cambiare il bus), perchè il numero dei bit di indirizzamento della memoria è memorizzato in un MSR e si deve attivare il PAE (comunque non vi preoccupate: le versioni consumer di Windows supportano solo 32 bit, ossia 4GB di RAM fisica, quindi nessun PAE. Solo le versioni server di windows e Linux, se il kernel è stato appositamente compilato, lo supportano). Non ricordo se la memoria indirizzabile dei P4 rimane a 36 bit, ma poichè l'FSB dovrebbe, forse, essere cambiato (più pin per gli indirizzi), credo che sia rimasto a 36 bit.

[cdimauro]

Originariamente inviato da quartz

I G5 però, a quanto ho letto, hanno la caratteristica di avere una branch prediction estremamente efficiente.

Ma anche 9 stadi di pipeline più, per cui soffrono molto di più i casi di misprediction.

In più gli ultimi modelli hanno una cache di 1MB, quindi in parte recuperano .

Soltanto il problema dell'occupazione di cache: in memoria lo spazio sarà sempre quello e comunque la richiesta di banda (e anche la latenza) verso il chipset e la memoria sarà comunque aumentata.

Cmq sappi che neanche io sono un particolare estimatore dei G5. Secondo me hanno fatto un passo indietro, specie dal punto di vista dell'efficienza, rispetto ai G4. Hanno tolto, infatti, quella che era la caratteristica migliore dei G4, cioè la pipeline estremamente corta (7 stadi, contro 16 dei G5), e questo solo nella speranza di salire velocemente in frequenza (s'è visto infatti)

Beh, in frequenza è salito, c'è poco da recriminare: un G4 a 2,7Ghz te lo puoi soltanto sognare.

E' chiaro che il G5 è frutto di compromessi, in base agli obiettivi che IBM s'era posto (con la sua famiglia POWER, di cui il G5 è una "castrazione").

In ogni caso IMHO i 64 bit sono una pura mossa commerciale da parte dei produttori di CPU (AMD in primis). A livello domestino non erano così necessari. In campo scientifico e/o server, magari sì.

I 64 bit di per sé magari sì, come ha anche sottolineato xeal nel suo messaggio. Ma nel contesto dell'architettura x86-64 il discorso è molto diverso, come è stato detto (ci sono diverse migliorie all'architettura e all'ISA).

[cdimauro]

Originariamente inviato da jo.li.

Mi sa che stai generalizando un pò troppo, è chiaro che in alcuni casi riscrivere il codice a 64bit può avere dei vantaggi anche dal punto di vista prestazionale e forse dei svantaggi in altre situazioni ma se la Apple non ha riscritto il suo OS interamente a 64bit è perché ancora vende cpu che sono a 32bit e poi perché evidentemente le risorse da impiegare sarebbero state troppe in relazione ai vantaggi ottenuti.

Non sto generalizzando e la scelta di Apple è dovuta alle considerazioni che ho già evidenziato.

Comunque puoi sempre leggerti i documenti che ha pubblicato in merito all'uso di codice a 64 bit e verificare tu stesso, leggendo i pro e i contro, se è come dico io o no.

Anche per i PowerPc mi sà che stai esagerando e generalizzando un pò troppo sembra quasi che tu stia parlando dei 68000. In prospettiva forse non sarerebbero più stati competitivi, ma adesso lo sono abbastanza.

Nessuna generalizzazione: è la pura e semplice realtà, ed è il motivo per cui Steve ha deciso per il passaggio agli odiati (prima) x86.

Poi ho detto chiaramente, e lo ripeto, che esistono dei contesti in cui i PPC si dimostrano migliori dal punto di vista computazionale. Ma mediamente la situazione è a vantaggio degli x86. Fatevene una ragione.

[cdimauro]

Originariamente inviato da jo.li.

E' chiaro che se un'applicazione che gestisce i 64bit eccede i 4GB di memoria, ma poi tu avevi continuato dicendo che per il s.o. e i driver e le applicazioni "normali" il limite era di 4GB totali, e che tutto quello che eccedeva tale limite veniva utilizzato come cache dal sistema operativo, io ti ho fatto notare che nel MacOs X questo non è vero.

E' così invece. Se non c'è nessuna applicazione a 64 bit che fa uso di memoria oltre i 4GB, quella memoria rimane utilizza dal s.o. soltanto come cache.

Questo non vuol dire che se c'è un'applicazione a 64 bit il s.o. non continuerà a fare lo stesso: è chiaro che dipende tutto dalla quantità di memoria richiesta dall'applicazione.

[cdimauro]

Originariamente inviato da Criceto

Oltre a sbagliare, sei perseverante nell'errore.
Ti è già stato spiegato 1000 volte come funzionano i 64bit di Tiger.
Non è come dici tu.

E io ti ho già spiegato altrettante 1000 volte che ti sbagli.

Spiegami secondo te come funziona Tiger e vediamo di chiudere la questione una volta per tutte.

[cdimauro]

Originariamente inviato da Criceto

Se poi Intel e AMD hanno approfittato del passaggio a 64 bit anche per dare una "svecchiata" alla loro architettura e renderla più efficiente prescinde la constestazione (come sempre pretestuosa, pedante, errata, noiosa, ecc) di Cdimauro riguardo ai G5 e OS X.

Nessuna pretestuosità e pedanteria: queste sono parole da fanboy che non è in grado di accettare la realtà delle cose.

Quanto ai presunti errori, non hai che da farmi vedere dove avrei sbagliato, cortesemente: dire a qualcuno che sbaglia senza fornirne la prova è una cosa che si commenta da sé.

Quanto alla noia, son fatti tuoi.

Sarà interessante, a questo punto, vedere come Apple si comporterà con il passaggio ad Intel. Anche perchè non ho capito se questi vantaggi architetturali degli Intel 64bit siano utilizzabili SOLO in modalità 64 bit o meno e se nel caso sono presenti (ad esempio) nel Yonah che è un processore a 32bit.

Solo col la modalità a 64 bit. Questo vuol dire che se Apple passa prima a x86 (a 32 bit) e poi a x86-64 sarà necessario: cambiare il kernel, cambiare i driver e anche le applicazioni (altrimenti non ha senso il passaggio). Roba non da poco (è la stessa situazione con cui MS s'è trovato con Windows XP x64).

[cdimauro]

Originariamente inviato da bjt2

I vantaggi architetturali, ossia il numero di registri in più, sono presenti SOLO in modalità a 64 bit. Non mi pare che siano state introdotte nuove istruzioni, usabili anche in modalità 32 bit, ma potrei sbagliarmi.

Niente istruzioni: solo il flag NX, se non ricordo male.

[^TiGeRShArK^]

Originariamente inviato da jo.li.

Scusa ma che vuol dire fare girare sempre i g5 a 64bit????

I G5 fanno girare i normali programmi a 32bit alla stessa velocità di quelli scritti a 64bit, tanto che a differenza di altre architetture come dici tu non c'e' nessun vantaggio a fare girare il codice a 64bit se non per avere un indirizzamento maggiore di memoria.

Quindi 32 o 64 bit per i g5 sarebbe la stessa cosa dal punto di vista prestazionale, ecco perché OSX è interamente a 32 bit anche se è possibile comunque fare girare programmi a 64 bit ma senza interfaccia grafica che rimarrebbe a 32bit.

Il passaggio a intel non è semplicemente un problema di processore ma di ottenere un pacchetto completo migliore (chipset) dal punto di vista prezzo/prestazioni e del risparmio energetico, problema molto importante per la Apple non soltanto per il settore dei notebook ma anche per la produzione di macmini e degli iMac.

no le applicazioni a 64 bit girano piu' lente in media sui G5...
a meno di non necessitare di calcoli che usino interi a 64 bit.

EDIT ho visto che ha spiegato tutto correttamente cdimauro...
e il bello è ke ci sono sempre i soliti ke dicono ke spara cazzate...

[jo.li.]

Originariamente inviato da cdimauro

Non sto generalizzando e la scelta di Apple è dovuta alle considerazioni che ho già evidenziato.

Comunque puoi sempre leggerti i documenti che ha pubblicato in merito all'uso di codice a 64 bit e verificare tu stesso, leggendo i pro e i contro, se è come dico io o no.

Nessuna generalizzazione: è la pura e semplice realtà, ed è il motivo per cui Steve ha deciso per il passaggio agli odiati (prima) x86.

Poi ho detto chiaramente, e lo ripeto, che esistono dei contesti in cui i PPC si dimostrano migliori dal punto di vista computazionale. Ma mediamente la situazione è a vantaggio degli x86. Fatevene una ragione.

Guarda che sapere se un tal proc. è più veloce del 10-20% ad eseguire un determinato compito e viceversa a me non interessa per niente, chi si fà le pippe mentali per avere un frames in più nei vari giochi mi fà ridere, poi l'ottimizzazione del codice è un'altro fattore importante nel complicare ancora di più la questione, e torno a ripetere che i powerPc non hanno nulla da invidiare agli x86, anzi.

[jo.li.]

Originariamente inviato da cdimauro

E' così invece. Se non c'è nessuna applicazione a 64 bit che fa uso di memoria oltre i 4GB, quella memoria rimane utilizza dal s.o. soltanto come cache.

Questo non vuol dire che se c'è un'applicazione a 64 bit il s.o. non continuerà a fare lo stesso: è chiaro che dipende tutto dalla quantità di memoria richiesta dall'applicazione.

E' chiaro che se l'utilizzo su di un sistema che ha per es. 8GB di memoria, di meno di 4GB il resto viene utilizzato come cache dal sistema, ma quello che dicevo io era che a prescindere dalle applicazioni a 64bit, io posso lavorare con più applicazioni a 32 bit senza incorrere in problemi di paginazione e quindi rallentamenti per acceder al disco.

[jo.li.]

Originariamente inviato da ^TiGeRShArK^

no le applicazioni a 64 bit girano piu' lente in media sui G5...
a meno di non necessitare di calcoli che usino interi a 64 bit.

EDIT ho visto che ha spiegato tutto correttamente cdimauro...
e il bello è ke ci sono sempre i soliti ke dicono ke spara cazzate...

Ma come ho già scritto se la Apple non ha ritenuto opportuno riscrivere l'OS a 64bit è perché non ha ritenuto opportuno farlo, almeno questo sui G5, perche negli intel la cosa sarà sicuramente diversa.

Infatti come ho detto la differenza prestazionale nei G5 è limitata e come "naturalmente" chissà perché??? tu mi hai fatto notare in determinate situazione usare codice a 64bit potrebbe essere controproducente, ma se la differenza fosse soltanto il 2-3% o meno credi che la cosa sia così importante??

[cdimauro]

Originariamente inviato da jo.li.

Guarda che sapere se un tal proc. è più veloce del 10-20% ad eseguire un determinato compito e viceversa a me non interessa per niente,

A te no, a tanti altri sì. Incluso un certo Steve Jobs...

chi si fà le pippe mentali per avere un frames in più nei vari giochi mi fà ridere,

Indubbiamente, ma stai considerando un caso estremo. Il bisogno di performance non se lo sono inventati i produttori di CPU & affini.

poi l'ottimizzazione del codice è un'altro fattore importante nel complicare ancora di più la questione,

Più esattamente, a cosa ti riferisci?

e torno a ripetere che i powerPc non hanno nulla da invidiare agli x86, anzi.

Sono dei buoni processori e questo nessuno l'ha mai negato, ma torno a ripetere: non sul piano delle prestazioni.